UFOpaedia - User contributions [en]

XcomUtil

2012-04-08T13:12:55Z

BladeFireLight: /* XcomUtil's features */

==What is XcomUtil?==

XcomUtil is an utility written by Scott T. Jones to enhance both UFO Defense and Terror From The Deep. It works with either both the DOS or the CE (Windows) version of each game.
Quoting from Scott T. Jones' [http://xcomutil.scotttjones.com/ page]: "XcomUtil is a game enhancer. It is not really an editor and it is certainly not a cheat program. The original purpose of XcomUtil was to make the game more difficult, because there was a bug in the original game that forced all games to the Beginner difficulty level, regardless of what level you chose."

Scott T. Jones worked on this software for years. On Jan 23 2007 he announced that he had passed development of XComUtil to [[User:BladeFireLight|BladeFireLight]] since his work prevented him from developing it anymore. The latest stable version (9.7) can be downloaded from [http://www.bladefirelight.com/ www.bladefirelight.com].

==XcomUtil's features==

Most features are optional, others are not. Useing XcuSetup you can change what features you want to use at any time:
This list includes items added in 9.7.

Fixed features:
*Fixes the difficulty bug mentioned above.
*Removes copy protection for UFO.
*Recovers MIA solders if you win combat (units under mind control when the last alien dies)
*Sets the soldiers to face different directions at the start inside the craft, giving better initial visibility.
*Changes the placement of the troops inside the Avenger, Lightning, Hammerhead and Leviathan.
*The 2 last features can be modified by changes to the files in XcomUtil\cfg (but be sure of knowing what you are doing)

Optional features:
*Allows for hybrid games, where UFO's maps can be played on TFTD and vice-versa.
*Allows to add [[statstrings]] and [[rank]] in soldier's names, for a quick overview of their abilities.
*Saves soldiers [[equipment]] configuration. [[Known Bugs#XComUtil Inventory Stacking Bug]]
*Allows you to control the order of which troops will exit the craft first/last.
*Has an option for a enhanced set of the original [[weapons]].
*Has an option to make the manufacture and use of laser and plasma weapons more difficult.
*Has an option to make [[research]] more difficult by making it highly dependent on capturing aliens.
*Allows to play only Day Missions or only [[Night Missions]].
*Allows to choose the light level, [[terrain]] and UFO/USO before each [[Battlescape|tactical mission]].
*Allows for world terrain and UFO/USO floorplans/shapes randomization.
*Permits players/modders to use new terrains and other features.
*Adds an AutoCombat feature to automatically resolve a combat.
*Allows for all 5 X-COM ships to carry troops.
*Allows for Skyranger/Triton to carry one [[Craft Armaments]]
*Option to fixe a number of bugs in maps, terrain and routes.
*Includes Vista/Windows 7 Blank Screen Fix.

Command line features:
*Allows to change the aliens and their weapons during tactical missions.
*Allows for changing difficulty levels on a saved game.

For a complete list see the XcomUtil.txt file included with the program.

==How to use XcomUtil==

Warning: this indications are merely for a quick use/explanation of some of its features. For full documentation read the XcomUtil.txt file included with the program. It is always recommended to make a backup copy of the game to restore it to its original configuration.

First, you will need to download XcomUtil from Blade FireLight's site and install it to your UFO/TFTD folder. If you want to change your options or skiped the setup dueing install, run XcuSetup and choose the options you want (there's an explaining list below).
For more advanced options you will need to use the xcomutil command (instructions on that below).
Finally, to load the game with XcomUtil fully working you will need to use the RunXcom command (or run XcomUtil\SteamSetup to configure Steam).

===The XcuSetup configuration program===

Before you can use XcomUtil first run the XcuSetup program (this will run during install). There is a number of optional command-line arguments to XcuSetup.

:XCUSETUP [uninstall] | [hybrid path] [debug] [options file] [skip] [nobackup]

:*"uninstall" : This options is used by itself and restores all backup files and removes any temp, config files or other files created by XCUSETUP and XcomUtil.

:*hybrid path : If you give it the path to the directory of TFTD (or the path to XCOM, if you are install XComUtil for TFTD), XcuSetup will import all the terrain from the other game. This makes it possible to play hybrid games which combine units and terrain from both games. This only needs to be done once.

:*"debug" : This option turns on logging of what options chooses and the file copy results to a log file. It also displays a list of all options chosen before applying the changes.

:*options file : This is a bath to a .BAT file overriding the defaults and skipping the questions. Each time XcuSetup is ran it creates XcomUtil\lastOp.bat file. This can be renamed and customized for this. DO NOT MODIFY XcomUtil\LastOp.bat directly, always copy to a new file.

:*"skip" : This options skips the continue prompts. Used with an options files this allows for silent install. (except on beta versions)

:*"nobackup" : This option will skip the backup IF a backup has already been made. If you have added any map packs or new terrain files you should not use this.

XcuSetup will then prompt you to choose a number of options:
*Do you want to Split the EXE? - The Windows version of XCOM and TFTD don't have separate executable (EXE) files for GEOSCAPE and TACTICAL. Choosing NO will disable most of XcuSetup's options.
*Run Patch Program? - If playing X-Com CE on Vista or Win7 You will need this patch to fix the blank screen on startup.
*Do you want to enable f0dder's loader? - This is in case you are having video problems with the Windows edition.
*Do you want to enable the use of UFO Extender? - Seb67 has created a loader for Windows UFO to enhance the game.
*Do you want to apply the fixes? - A number of fan made fixes to data files can be applied. Either all together or individually selected.
*Do you want to enable Fighter Transports? - This adds space into the two xcom fighter ships to carry a small number of men.
*Do you want to add one Hard Point to the Triton/Skyranger? - This adds 1 gun mount to either the Skyranger or the Triton
*Do you want to use the defensive starting base? - The starting base will have a different configuration better suited for defense
*Do you want to use the improved starting base? - The starting base will have the scientists and engineers will be increased to 50 each. It will also upgrade the Small Radar to a Large Radar (or their TFTD equivalents) and build an Alien Containment
*Do you want fix the Disjointed base bug? - This solves the disjointed base bug by removing the adjoining walls in various maps. This will result in some hallways ending in solid rock. The disjointed base bug is where the walls between base modules on the bottom row and left column are not correctly removed.
*Do you want to use the improved tank armor? -The HWP will have the same stats as the Hovertanks, if Yes is chosen. It also works for Coelacanths/Displacers in TFTD.
*-Do you want to use Improved Pistol/DartGun? - gives auto-fire
*Do you want to use Improved Heavy Laser? - Improve the accuracy of the Heavy Laser.
*Do you want to use Improved High Explosive/Magna-Pack Explosive? - damage increased (200) to the point that they can blow open UFOs' outer walls
*Do you want to use Improved Gauss Weapons? - Double the clip size of Gauss Rifle and Heavy Gauss, plus increase the damage of the Heavy Gauss from 75 to 80.
*Do you want to Remove Gauss Weapon Clips? - Remove the need for clips from Gauss weapons, and increase the damage of the Heavy Gauss from 75 to 80.
* Increase the damage of the Dye Grenade? - This makes it more useful for cover with out waiting 3 turns for the cloud to get big enough.
*Do you want to use the alternate laser Tech? - Lasers now require Elerium to be built (and Alloys for Heavy Lasers), plus it is not possible to build Plasma beam weapons (with the exception of the aircraft Plasma Cannon, which takes ''much'' longer to build, and clips for hand weapons). This alters [[Manufacturing Profitability]] significantly - Laser Cannon and Plasma Cannon are no longer a cash cow to be milked. This makes the strategic and economic game much more challenging.
*Do you want XcomUtil to attempt to fix TFTD Research Bugs? - This options attempts checks for an fixes issues in the TFTD Research after each combat. Research of MC Reader, Sub Construction and Aquaplastics are made available if they should be.
*Do you want to get research help from captured aliens? - This will ''greatly'' increase the research times for all technologies, and you will need to capture aliens to speed up your research and get your technology progression back to anywhere near what you are used to. It would be better stated as "Do you want research to depend largely on capturing aliens?". This is a great feature for those who want the game to be much more challenging both strategically and tactically.
*Do you want to see XcomUtil messages after combat? - This enables the display of messages between the tactical and world views to report AutoCombat results and any research help acquired by capturing aliens.
*Do you want stat strings added to the names of your troops? - To help distinguish them in combat, on equipment screens, and Base screens. Other suboptions will appear if you choose Yes. It is possible to auto-equip your troops, based on their stat strings or other labels.
*Do you want rank indicators added to the names of your troops? - This adds :a through :f after the name, to be used as a rank indicator, where a=rookie/seaman, b=squaddie/able-seaman, etc. This was chosen over traditional rank abbreviations both to save space and to create unique indicators.
*Do you want their number of kills added to the names of your troops? - This adds the number of kills after the rank indicator at the end of the name of your soldier.
*Do you want your troops automatically sorted before combat? - Places the rookies and high reaction soldiers at first to disembark the craft. (Or set up your own, custom sort order.)
*Do you want to automatically re-equip your troops before combat? - Saves the equipment for each soldier at the end of each mission and reequips them on their next mission.
*Do you want to eliminate mind control? - Completely removes Psionics/Molecular Control from the game. Neither Aliens nor X-COM have access to it. When not using Xcomutil.bat X-COM units can still use psionics/M.C.
*Do you want automatic screening for Psi ability? - Optional to always displays all soldiers Psi ability or Just after Psi/MC lab is resaerched.
*Do you want to fight all battles in daylight/darkness? - what it says: makes the game easier/harder.
''(skipping 2 options - dealt with below)''
*Do you want to use the XcomUtil BFG? - XcomUtil can generate the battlefield instead of letting the game do it.
*Do you want to be prompted before every ship attack? - this lets you set the terrain, ship, and type of alien ship before each battle.
*Do you want the world map terrain to be randomized? - This option is only avalible if you dont use BFG. This can make the world map look very weird, but it evenly distributes the occurrences of the various terrains without making them totally random.
*Do you want to use Random Alien Craft Floor Plans? - XcomUtil can randomize the floor plan on alien craft. Options for randomizing floor plans include randomizing once during setup, or if using the BFG before every combat. Using Random shapes or filling in the dead spaces with small rooms to create rectangle exterior shapes.

===The XcomUtil command===

In addition to XcuSetup and RunXcom. Another way to use XcomUtil is by running the xcomutil command to change a saved game. This command allow for specific modifications to the files (XcuSetup makes nearly all general modifications), especially to games saved while on tactical.
If you are going to edit the game through this command remember to make backup files of your saved game directories before using it. You should also read XComUtil's manual (XcomUtil\XcomUstil.txt) concerning each flag, otherwise you might end up your saved games.

====How to use the command====

The syntax for the command is :

''XCOMUTIL path [flags] [WRT]''

''path'' Where your game is located. If xcomutil is on the same folder then you will simply have to specify which saved game you want to be changed

''[flags]'' These are the specific commands. More on those below.

''[WRT]'' To make changes permanent you will need to put WRT at the end, otherwise XcomUtil will simulate only the effects (which is great to practice).

An example of a command would be:

''XCOMUTIL GAME_1 DXC WRT'' - This would eliminate all extra clips carried by the aliens on the first saved game.

====Flags affecting tactical missions====

These flags will change only elements of a saved tactical game. There are other flags that affect also Geoscape, although most of those changes can be made already with XcuSetup. For more information on the flags consult the XcomUtil.txt file.

*''DXC'' - This flag deletes all of the extra plasma clips carried by the aliens to make more room for extra aliens.
*''S2B'' - Changes stun launchers (SL) to blaster launchers (BL). Other similar flags include ''B2S'' (changes BLs to SLs); ''W2H'' which changes alien pistols and rifles to heavy plasmas; ''W2R'' changes alien weapons to rifles; ''W2P'' changes alien weapons to pistols.
*''CHG:old:new'' - This will change objects carried by the aliens from old to new. As an example it is possible to change plasma weapons to lasers or any other object on the inventory.
*''DEL:name'' - Deletes all objects carried by the aliens of the name type.
*''RPL:oldrace:newrace:oldrank:newrank'' - Allows to replace aliens and to change their ranks.
*''typ:#'' - This will add new alien units, if there is space for them. The possible flags are SEC, FLO, SNA, MUT, ETH, CEL, SIL, CHR, CIV or ALL. It is not possible to add large aliens.
*''VIS'' - Makes the entire battlefield visible, including the aliens.
*''WIN'' - Kills all alien units at the end of your turn.
*''ARM'' - Equips all unarmed aliens with a Heavy Plasma
*''SWP'' - Allows you to switch sides with the aliens (Warning: this flag can be very dangerous do your game, read the instructions to further details).

====Flags affecting Geoscape====

These flags make changes into a game saved on Geoscape. The changes aren't permanent and some of them can be used to cheat.

*''ACT:n'' - Sets the X-COM activity on each area to n.
*''MSK'' - Reveals the Psi level of Soldiers/Aquanauts.
*''TEC:xyz'' - Allows for unresearched technologies to be used/built. XYZ can be HUMAN, HYBRID or ALL
*''MNY:n'' - Sets the money to n.
*''FND:n'' - Sets the funding for each country to n times $1000.

====Flags affecting the game executable====

These flags make permanent changes to the game.

*''TNK'' - Adds improved HWP/SWS, with the stats of the Hovertanks/Displacers.
*''FLY'' - Allows Celatids, Silacoids, Engineers and Tentaculats to fly.
*''PSI'' - Gives Psi abilities to all alien Leaders/Commanders. Doesn't work with TFTD.
*''BAS'' - Uses the improved base.

===How To Start The Game Using XComUtil - RunXCom.bat===

After you have changed the game using XcuSetUp or/and xcomutil you must use the RunXCom.bat command.
If you are running the CE version on XP then you may need to install fodder's patch using XcuSetup. If you had already chosen No on that simply run XcuSetup again. For more information on this read the XcomUtil manual where the proper procedure for installing CE is explained.

If your playing X-Com through STEAM. The Installer will give you an option to change STEAM to ruse RunXcom to start the game, or run XcuSetup to change options. If you chose "NO" to configureing STEAM, or you ran "Validate Game Cashe" in STEAM then use XcomUtil\SteamSetup.bat to enable the XcomUtil STEAM menu.

==But I Don't Want Some Features==

This section is for XcomUtil 9.6. Version 9.7 adds more choice as to what changes are made.

Tested on: DOS Ver v1.4

As much as XcomUtil being a game enchancer, some aspects of the program cannot be easily disabled. Once installed via Xcusetup.bat, some features are implemented that may not be welcome (even if you answered 'No' to all questions). Such as, the soldier carrying capacity of the Interceptor and the Firestorm. If you were not wanting these additions, or any other, but want the Difficulty Bug squashed, you must use a different editor (for example: Khor Chin Heong's XCOM2 MultiEditor v0.2) to change values within the geoscape.exe back to originals. As much as this is a pain, it only needs to be done once if you keep a backup of the edited and corrected geoscape.exe.

How To:

Run Xcusetup.bat, when you are asked your first question, just close the program as you would any other windows program. Windows will come up with a message: "Cannot close this program normally, are you sure you want to end this program?" (or something similiar to that wording). Once closed, run XCOM2 MultiEditor. (NOTE: this editor works for Xcom1, even though its written for Xcom2 in mind) and change values to what they are originally. Look inside "Sub Editor" within the editor and change "Craft Weapons" to 0 for the Triton. Once you have edited the values back to originals, save it. Cut geoscape.exe from the currnt game install and move it to a new installation of Xcom1. Just overwrite geoscape.exe with your patched and edited file. Keep it somewhere else as a backup, just in case.

'''Original Ships''':
Remove SHP:CFG from Xcusetup.bat, before running the first time. (There is another flag that can be removed to bypass the base disjoint bug fix, but if that doesn't run then Xcomutil acts like Xcusetup.bat was never run at all.)

'''Making use of the Base Disjoint Bug - restoring the original base map files''':

XCUSetup forces a fix on the base map files when it is run, without prompting you if you want to do this or not. It effectively knocks out all the walls that would otherwise be sealed off when placed along the left and lower most edges of the base map grid.

While most players are content with the crude looking base maps and the complete unrestricted access to and from the various modules, some players may already know how the base disjoint bug works and will want to make use of the sealed off walls to control the flow of alien movement. If this sounds like you, read on.

To restore the old maps, you must make a backup of the xbase*.map files stored in the MAPS\ directory. You can also do this to the ubase*.map files to keep the alien base maps intact as well. Or if you can get access to these files on your installation CD, or a second copy of the game, you can take copies directly from there when you want to restore them.

Run xcusetup as per normal, then overwrite the map files with the backup copies.

==Advanced Statstrings==
Statstrings allow to rename your soldiers. For example, "Anton Miller /wMr" would be a '''w'''eak squaddie of excellent firing accuracy ('''m'''arksmanship) and decent '''r'''eactions. However, like almost everything in XcomUtil, this is fully configurable. Custom sets of statstring definitions can be found [[statstrings|here]].

==Troubleshooting FAQ==

===I have UFO/TFTD CE. How can I use f0dder's patch and XComUtil?===

XComUtil's package includes f0dder's patch. To install it, run XcuSetup and choose Yes on the f0dder's patch query.

===I have chosen No before and now XcuSetup doesn't show the option again (9.6 only)===

Delete the XCom4Win.xcf file from the UFO/TFTD folder. It will now show up again on XcuSetup.

===Is it possible to incorporate alien components (alien food, alien surgery, etc.) into XcomUtil/cfg/xcomutil.rm(x,t) for use in random maps?===

If you know the corrent HEX values then you can add any terrain tile. Items Listed in XcomUtil.txt are just the short list.

===I am using version 9.60, but it locks up when entering combat===

Find the file RunXComW.bat and open it with Notepad. Use the search function to locate every line that starts with the term xcopy, then add /y as a third parameter. For example:

xcopy xcubef missdat >nul

Becomes:

xcopy xcubef missdat /y >nul

Save the edited batch and you'll have no further problems.

XcomUtil 9.7 does not have this issue.

=See Also=

[[Manufacturing_Profitability#XComUtil_manufacturing_profitability|XcomUtil Manufacturing Profitability]]

[[Game Editors]]

[[Making the Game Harder]]

XcomUtil

2012-04-08T13:09:12Z

BladeFireLight: /* What is XcomUtil? */ removed Beta referances

==What is XcomUtil?==

XcomUtil is an utility written by Scott T. Jones to enhance both UFO Defense and Terror From The Deep. It works with either both the DOS or the CE (Windows) version of each game.
Quoting from Scott T. Jones' [http://xcomutil.scotttjones.com/ page]: "XcomUtil is a game enhancer. It is not really an editor and it is certainly not a cheat program. The original purpose of XcomUtil was to make the game more difficult, because there was a bug in the original game that forced all games to the Beginner difficulty level, regardless of what level you chose."

Scott T. Jones worked on this software for years. On Jan 23 2007 he announced that he had passed development of XComUtil to [[User:BladeFireLight|BladeFireLight]] since his work prevented him from developing it anymore. The latest stable version (9.7) can be downloaded from [http://www.bladefirelight.com/ www.bladefirelight.com].

==XcomUtil's features==

Most features are optional, others are not. Useing XcuSetup you can change what features you want to use at any time:
This list includes items in 9.7 currently in beta.

Fixed features:
*Fixes the difficulty bug mentioned above.
*Removes copy protection for UFO.
*Recovers MIA solders if you win combat (units under mind control when the last alien dies)
*Sets the soldiers to face different directions at the start inside the craft, giving better initial visibility.
*Changes the placement of the troops inside the Avenger, Lightning, Hammerhead and Leviathan.
*The 2 last features can be modified by changes to the files in XcomUtil\cfg (but be sure of knowing what you are doing)

Optional features:
*Allows for hybrid games, where UFO's maps can be played on TFTD and vice-versa.
*Allows to add [[statstrings]] and [[rank]] in soldier's names, for a quick overview of their abilities.
*Saves soldiers [[equipment]] configuration. [[Known Bugs#XComUtil Inventory Stacking Bug]]
*Allows you to control the order of which troops will exit the craft first/last.
*Has an option for a enhanced set of the original [[weapons]].
*Has an option to make the manufacture and use of laser and plasma weapons more difficult.
*Has an option to make [[research]] more difficult by making it highly dependent on capturing aliens.
*Allows to play only Day Missions or only [[Night Missions]].
*Allows to choose the light level, [[terrain]] and UFO/USO before each [[Battlescape|tactical mission]].
*Allows for world terrain and UFO/USO floorplans/shapes randomization.
*Permits players/modders to use new terrains and other features.
*Adds an AutoCombat feature to automatically resolve a combat.
*Allows for all 5 X-COM ships to carry troops.
*Allows for Skyranger/Triton to carry one [[Craft Armaments]]
*Option to fixe a number of bugs in maps, terrain and routes.
*Includes Vista/Windows 7 Blank Screen Fix.

Command line features:
*Allows to change the aliens and their weapons during tactical missions.
*Allows for changing difficulty levels on a saved game.

For a complete list see the XcomUtil.txt file included with the program.

==How to use XcomUtil==

Warning: this indications are merely for a quick use/explanation of some of its features. For full documentation read the XcomUtil.txt file included with the program. It is always recommended to make a backup copy of the game to restore it to its original configuration.

First, you will need to download XcomUtil from Blade FireLight's site and install it to your UFO/TFTD folder. If you want to change your options or skiped the setup dueing install, run XcuSetup and choose the options you want (there's an explaining list below).
For more advanced options you will need to use the xcomutil command (instructions on that below).
Finally, to load the game with XcomUtil fully working you will need to use the RunXcom command (or run XcomUtil\SteamSetup to configure Steam).

===The XcuSetup configuration program===

Before you can use XcomUtil first run the XcuSetup program (this will run during install). There is a number of optional command-line arguments to XcuSetup.

:XCUSETUP [uninstall] | [hybrid path] [debug] [options file] [skip] [nobackup]

:*"uninstall" : This options is used by itself and restores all backup files and removes any temp, config files or other files created by XCUSETUP and XcomUtil.

:*hybrid path : If you give it the path to the directory of TFTD (or the path to XCOM, if you are install XComUtil for TFTD), XcuSetup will import all the terrain from the other game. This makes it possible to play hybrid games which combine units and terrain from both games. This only needs to be done once.

:*"debug" : This option turns on logging of what options chooses and the file copy results to a log file. It also displays a list of all options chosen before applying the changes.

:*options file : This is a bath to a .BAT file overriding the defaults and skipping the questions. Each time XcuSetup is ran it creates XcomUtil\lastOp.bat file. This can be renamed and customized for this. DO NOT MODIFY XcomUtil\LastOp.bat directly, always copy to a new file.

:*"skip" : This options skips the continue prompts. Used with an options files this allows for silent install. (except on beta versions)

:*"nobackup" : This option will skip the backup IF a backup has already been made. If you have added any map packs or new terrain files you should not use this.

XcuSetup will then prompt you to choose a number of options:
*Do you want to Split the EXE? - The Windows version of XCOM and TFTD don't have separate executable (EXE) files for GEOSCAPE and TACTICAL. Choosing NO will disable most of XcuSetup's options.
*Run Patch Program? - If playing X-Com CE on Vista or Win7 You will need this patch to fix the blank screen on startup.
*Do you want to enable f0dder's loader? - This is in case you are having video problems with the Windows edition.
*Do you want to enable the use of UFO Extender? - Seb67 has created a loader for Windows UFO to enhance the game.
*Do you want to apply the fixes? - A number of fan made fixes to data files can be applied. Either all together or individually selected.
*Do you want to enable Fighter Transports? - This adds space into the two xcom fighter ships to carry a small number of men.
*Do you want to add one Hard Point to the Triton/Skyranger? - This adds 1 gun mount to either the Skyranger or the Triton
*Do you want to use the defensive starting base? - The starting base will have a different configuration better suited for defense
*Do you want to use the improved starting base? - The starting base will have the scientists and engineers will be increased to 50 each. It will also upgrade the Small Radar to a Large Radar (or their TFTD equivalents) and build an Alien Containment
*Do you want fix the Disjointed base bug? - This solves the disjointed base bug by removing the adjoining walls in various maps. This will result in some hallways ending in solid rock. The disjointed base bug is where the walls between base modules on the bottom row and left column are not correctly removed.
*Do you want to use the improved tank armor? -The HWP will have the same stats as the Hovertanks, if Yes is chosen. It also works for Coelacanths/Displacers in TFTD.
*-Do you want to use Improved Pistol/DartGun? - gives auto-fire
*Do you want to use Improved Heavy Laser? - Improve the accuracy of the Heavy Laser.
*Do you want to use Improved High Explosive/Magna-Pack Explosive? - damage increased (200) to the point that they can blow open UFOs' outer walls
*Do you want to use Improved Gauss Weapons? - Double the clip size of Gauss Rifle and Heavy Gauss, plus increase the damage of the Heavy Gauss from 75 to 80.
*Do you want to Remove Gauss Weapon Clips? - Remove the need for clips from Gauss weapons, and increase the damage of the Heavy Gauss from 75 to 80.
* Increase the damage of the Dye Grenade? - This makes it more useful for cover with out waiting 3 turns for the cloud to get big enough.
*Do you want to use the alternate laser Tech? - Lasers now require Elerium to be built (and Alloys for Heavy Lasers), plus it is not possible to build Plasma beam weapons (with the exception of the aircraft Plasma Cannon, which takes ''much'' longer to build, and clips for hand weapons). This alters [[Manufacturing Profitability]] significantly - Laser Cannon and Plasma Cannon are no longer a cash cow to be milked. This makes the strategic and economic game much more challenging.
*Do you want XcomUtil to attempt to fix TFTD Research Bugs? - This options attempts checks for an fixes issues in the TFTD Research after each combat. Research of MC Reader, Sub Construction and Aquaplastics are made available if they should be.
*Do you want to get research help from captured aliens? - This will ''greatly'' increase the research times for all technologies, and you will need to capture aliens to speed up your research and get your technology progression back to anywhere near what you are used to. It would be better stated as "Do you want research to depend largely on capturing aliens?". This is a great feature for those who want the game to be much more challenging both strategically and tactically.
*Do you want to see XcomUtil messages after combat? - This enables the display of messages between the tactical and world views to report AutoCombat results and any research help acquired by capturing aliens.
*Do you want stat strings added to the names of your troops? - To help distinguish them in combat, on equipment screens, and Base screens. Other suboptions will appear if you choose Yes. It is possible to auto-equip your troops, based on their stat strings or other labels.
*Do you want rank indicators added to the names of your troops? - This adds :a through :f after the name, to be used as a rank indicator, where a=rookie/seaman, b=squaddie/able-seaman, etc. This was chosen over traditional rank abbreviations both to save space and to create unique indicators.
*Do you want their number of kills added to the names of your troops? - This adds the number of kills after the rank indicator at the end of the name of your soldier.
*Do you want your troops automatically sorted before combat? - Places the rookies and high reaction soldiers at first to disembark the craft. (Or set up your own, custom sort order.)
*Do you want to automatically re-equip your troops before combat? - Saves the equipment for each soldier at the end of each mission and reequips them on their next mission.
*Do you want to eliminate mind control? - Completely removes Psionics/Molecular Control from the game. Neither Aliens nor X-COM have access to it. When not using Xcomutil.bat X-COM units can still use psionics/M.C.
*Do you want automatic screening for Psi ability? - Optional to always displays all soldiers Psi ability or Just after Psi/MC lab is resaerched.
*Do you want to fight all battles in daylight/darkness? - what it says: makes the game easier/harder.
''(skipping 2 options - dealt with below)''
*Do you want to use the XcomUtil BFG? - XcomUtil can generate the battlefield instead of letting the game do it.
*Do you want to be prompted before every ship attack? - this lets you set the terrain, ship, and type of alien ship before each battle.
*Do you want the world map terrain to be randomized? - This option is only avalible if you dont use BFG. This can make the world map look very weird, but it evenly distributes the occurrences of the various terrains without making them totally random.
*Do you want to use Random Alien Craft Floor Plans? - XcomUtil can randomize the floor plan on alien craft. Options for randomizing floor plans include randomizing once during setup, or if using the BFG before every combat. Using Random shapes or filling in the dead spaces with small rooms to create rectangle exterior shapes.

===The XcomUtil command===

In addition to XcuSetup and RunXcom. Another way to use XcomUtil is by running the xcomutil command to change a saved game. This command allow for specific modifications to the files (XcuSetup makes nearly all general modifications), especially to games saved while on tactical.
If you are going to edit the game through this command remember to make backup files of your saved game directories before using it. You should also read XComUtil's manual (XcomUtil\XcomUstil.txt) concerning each flag, otherwise you might end up your saved games.

====How to use the command====

The syntax for the command is :

''XCOMUTIL path [flags] [WRT]''

''path'' Where your game is located. If xcomutil is on the same folder then you will simply have to specify which saved game you want to be changed

''[flags]'' These are the specific commands. More on those below.

''[WRT]'' To make changes permanent you will need to put WRT at the end, otherwise XcomUtil will simulate only the effects (which is great to practice).

An example of a command would be:

''XCOMUTIL GAME_1 DXC WRT'' - This would eliminate all extra clips carried by the aliens on the first saved game.

====Flags affecting tactical missions====

These flags will change only elements of a saved tactical game. There are other flags that affect also Geoscape, although most of those changes can be made already with XcuSetup. For more information on the flags consult the XcomUtil.txt file.

*''DXC'' - This flag deletes all of the extra plasma clips carried by the aliens to make more room for extra aliens.
*''S2B'' - Changes stun launchers (SL) to blaster launchers (BL). Other similar flags include ''B2S'' (changes BLs to SLs); ''W2H'' which changes alien pistols and rifles to heavy plasmas; ''W2R'' changes alien weapons to rifles; ''W2P'' changes alien weapons to pistols.
*''CHG:old:new'' - This will change objects carried by the aliens from old to new. As an example it is possible to change plasma weapons to lasers or any other object on the inventory.
*''DEL:name'' - Deletes all objects carried by the aliens of the name type.
*''RPL:oldrace:newrace:oldrank:newrank'' - Allows to replace aliens and to change their ranks.
*''typ:#'' - This will add new alien units, if there is space for them. The possible flags are SEC, FLO, SNA, MUT, ETH, CEL, SIL, CHR, CIV or ALL. It is not possible to add large aliens.
*''VIS'' - Makes the entire battlefield visible, including the aliens.
*''WIN'' - Kills all alien units at the end of your turn.
*''ARM'' - Equips all unarmed aliens with a Heavy Plasma
*''SWP'' - Allows you to switch sides with the aliens (Warning: this flag can be very dangerous do your game, read the instructions to further details).

====Flags affecting Geoscape====

These flags make changes into a game saved on Geoscape. The changes aren't permanent and some of them can be used to cheat.

*''ACT:n'' - Sets the X-COM activity on each area to n.
*''MSK'' - Reveals the Psi level of Soldiers/Aquanauts.
*''TEC:xyz'' - Allows for unresearched technologies to be used/built. XYZ can be HUMAN, HYBRID or ALL
*''MNY:n'' - Sets the money to n.
*''FND:n'' - Sets the funding for each country to n times $1000.

====Flags affecting the game executable====

These flags make permanent changes to the game.

*''TNK'' - Adds improved HWP/SWS, with the stats of the Hovertanks/Displacers.
*''FLY'' - Allows Celatids, Silacoids, Engineers and Tentaculats to fly.
*''PSI'' - Gives Psi abilities to all alien Leaders/Commanders. Doesn't work with TFTD.
*''BAS'' - Uses the improved base.

===How To Start The Game Using XComUtil - RunXCom.bat===

After you have changed the game using XcuSetUp or/and xcomutil you must use the RunXCom.bat command.
If you are running the CE version on XP then you may need to install fodder's patch using XcuSetup. If you had already chosen No on that simply run XcuSetup again. For more information on this read the XcomUtil manual where the proper procedure for installing CE is explained.

If your playing X-Com through STEAM. The Installer will give you an option to change STEAM to ruse RunXcom to start the game, or run XcuSetup to change options. If you chose "NO" to configureing STEAM, or you ran "Validate Game Cashe" in STEAM then use XcomUtil\SteamSetup.bat to enable the XcomUtil STEAM menu.

==But I Don't Want Some Features==

This section is for XcomUtil 9.6. Version 9.7 adds more choice as to what changes are made.

Tested on: DOS Ver v1.4

As much as XcomUtil being a game enchancer, some aspects of the program cannot be easily disabled. Once installed via Xcusetup.bat, some features are implemented that may not be welcome (even if you answered 'No' to all questions). Such as, the soldier carrying capacity of the Interceptor and the Firestorm. If you were not wanting these additions, or any other, but want the Difficulty Bug squashed, you must use a different editor (for example: Khor Chin Heong's XCOM2 MultiEditor v0.2) to change values within the geoscape.exe back to originals. As much as this is a pain, it only needs to be done once if you keep a backup of the edited and corrected geoscape.exe.

How To:

Run Xcusetup.bat, when you are asked your first question, just close the program as you would any other windows program. Windows will come up with a message: "Cannot close this program normally, are you sure you want to end this program?" (or something similiar to that wording). Once closed, run XCOM2 MultiEditor. (NOTE: this editor works for Xcom1, even though its written for Xcom2 in mind) and change values to what they are originally. Look inside "Sub Editor" within the editor and change "Craft Weapons" to 0 for the Triton. Once you have edited the values back to originals, save it. Cut geoscape.exe from the currnt game install and move it to a new installation of Xcom1. Just overwrite geoscape.exe with your patched and edited file. Keep it somewhere else as a backup, just in case.

'''Original Ships''':
Remove SHP:CFG from Xcusetup.bat, before running the first time. (There is another flag that can be removed to bypass the base disjoint bug fix, but if that doesn't run then Xcomutil acts like Xcusetup.bat was never run at all.)

'''Making use of the Base Disjoint Bug - restoring the original base map files''':

XCUSetup forces a fix on the base map files when it is run, without prompting you if you want to do this or not. It effectively knocks out all the walls that would otherwise be sealed off when placed along the left and lower most edges of the base map grid.

While most players are content with the crude looking base maps and the complete unrestricted access to and from the various modules, some players may already know how the base disjoint bug works and will want to make use of the sealed off walls to control the flow of alien movement. If this sounds like you, read on.

To restore the old maps, you must make a backup of the xbase*.map files stored in the MAPS\ directory. You can also do this to the ubase*.map files to keep the alien base maps intact as well. Or if you can get access to these files on your installation CD, or a second copy of the game, you can take copies directly from there when you want to restore them.

Run xcusetup as per normal, then overwrite the map files with the backup copies.

==Advanced Statstrings==
Statstrings allow to rename your soldiers. For example, "Anton Miller /wMr" would be a '''w'''eak squaddie of excellent firing accuracy ('''m'''arksmanship) and decent '''r'''eactions. However, like almost everything in XcomUtil, this is fully configurable. Custom sets of statstring definitions can be found [[statstrings|here]].

==Troubleshooting FAQ==

===I have UFO/TFTD CE. How can I use f0dder's patch and XComUtil?===

XComUtil's package includes f0dder's patch. To install it, run XcuSetup and choose Yes on the f0dder's patch query.

===I have chosen No before and now XcuSetup doesn't show the option again (9.6 only)===

Delete the XCom4Win.xcf file from the UFO/TFTD folder. It will now show up again on XcuSetup.

===Is it possible to incorporate alien components (alien food, alien surgery, etc.) into XcomUtil/cfg/xcomutil.rm(x,t) for use in random maps?===

If you know the corrent HEX values then you can add any terrain tile. Items Listed in XcomUtil.txt are just the short list.

===I am using version 9.60, but it locks up when entering combat===

Find the file RunXComW.bat and open it with Notepad. Use the search function to locate every line that starts with the term xcopy, then add /y as a third parameter. For example:

xcopy xcubef missdat >nul

Becomes:

xcopy xcubef missdat /y >nul

Save the edited batch and you'll have no further problems.

XcomUtil 9.7 does not have this issue.

=See Also=

[[Manufacturing_Profitability#XComUtil_manufacturing_profitability|XcomUtil Manufacturing Profitability]]

[[Game Editors]]

[[Making the Game Harder]]

Talk:XcomUtil

2012-04-08T13:07:38Z

BladeFireLight: /* XcomUtil 9.7 */ No longer Beta

=XcomUtil 9.7=

9.7 is available on www.bladefirelight.com

==Release Notes==

New in this version.

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

Removed from this versions

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

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

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

==Beta Discussion==

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

----

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

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

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

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

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

----

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

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

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

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

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

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

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

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

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

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

=== Categorise Config Options ===

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

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

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

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

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

* Dart Gun

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=== Focused Research Help ===

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

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

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

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

== Features for 9.8+ - New features ==

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

=== Improved Base Comes At Cost ===

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

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

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

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

=== AutoCombat ===

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

==== AutoWithdrawal ====

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

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

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

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

=== Tougher UFOs ===

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

=== Rebalanced Craft Weapons ===

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

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

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

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

==== Fusion Ball Launcher ====

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

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

==== Cost Based Approach ====

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

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

See [[User:Spike#Cost_Based_Rebalancing]]

==== Stat Based Approach ====

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

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

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

See [[User:Spike#Stat_Based_Rebalancing]]

=== Rebalanced Infantry Weapons ===

See [[User:Spike#Balancing_Infantry_Weapons]]

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

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

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

=== Rebalanced X-COM craft ===

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

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

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

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

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

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

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

=== SWP switch expansion ===

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

A few ideas off the top of my head:

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

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

==See Also==

[[Wish List]]

= Completed Wish List Items =

=== BFG Default To Unchanged ===

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

= MISC =

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

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

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

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

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

= Read The Fine Manual =

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

Talk:XcomUtil

2012-04-08T13:06:25Z

BladeFireLight: /* XcomUtil 9.7 Beta */

=XcomUtil 9.7=

9.7 Beta is available on www.bladefirelight.com

==Release Notes==

New in this version.

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

Removed from this versions

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

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

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

==Beta Discussion==

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

----

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

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

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

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

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

----

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

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

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

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

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

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

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

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

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

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

=== Categorise Config Options ===

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

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

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

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

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

* Dart Gun

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=== Focused Research Help ===

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

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

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

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

== Features for 9.8+ - New features ==

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

=== Improved Base Comes At Cost ===

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

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

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

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

=== AutoCombat ===

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

==== AutoWithdrawal ====

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

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

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

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

=== Tougher UFOs ===

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

=== Rebalanced Craft Weapons ===

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

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

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

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

==== Fusion Ball Launcher ====

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

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

==== Cost Based Approach ====

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

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

See [[User:Spike#Cost_Based_Rebalancing]]

==== Stat Based Approach ====

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

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

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

See [[User:Spike#Stat_Based_Rebalancing]]

=== Rebalanced Infantry Weapons ===

See [[User:Spike#Balancing_Infantry_Weapons]]

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

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

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

=== Rebalanced X-COM craft ===

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

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

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

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

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

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

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

=== SWP switch expansion ===

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

A few ideas off the top of my head:

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

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

==See Also==

[[Wish List]]

= Completed Wish List Items =

=== BFG Default To Unchanged ===

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

= MISC =

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

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

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

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

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

= Read The Fine Manual =

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

Talk:Battlescape Map Generation

2012-04-01T17:07:32Z

BladeFireLight: /* KABOOM!! */ the blast will kill all aliens

==Urban Roads==

I've observed a 45-50% chance of an east/west road appearing, and a 75% chance of a north/south. Both appearing at once occured 20% of the time. Only done 110 trials at the present time however.

- [[User:Bomb Bloke|Bomb Bloke]] 03:55, 10 February 2008 (PST)

----

I'm pretty sure I encountered road-less terror missions before. It's been a while since I ran random terror missions though. BTW: the max number of 20x20 modules which can happen on a Cydonian base map is 8 (including the brain room). In an alien base, it's 4 (including the command center). In both instances, the game has to create 2 green staging rooms so that your soldiers have a place to start. Therefore, the min number of small 10x10 modules (neglecting the 2 green rooms) in the Cydonian base is 2 and in an alien base it's 7. Of course, this assumes the game's map generation engine is purely random.

- [[User:Zombie|Zombie]] 22:45, 13 February 2008 (PST)

----

Can't remember ever seeing a terror map without a road... Are you certain?

What I plan to do is create a special logger and run a few thousand samples through it. That'll get the percentages that much more clear.

I'll be doing the same regarding the odds of any other module turning up in a given space. I suspect the limits as to how many large modules can appear are, as you say, solely based on how many can actually fit; but I'd like to have it nailed down for certain. :)

- [[User:Bomb Bloke|Bomb Bloke]] 23:41, 13 February 2008 (PST)

----

Like I said, I'm not 100% certain on seeing road-less terror missions, but I'm pretty sure. If the map generation engine is completely random, it guarantees the possibility. Technically, there is a 6.67% (1 of 15) chance of spawining a road in a N/S or E/W configuration and the same chance of a dual roadway. It's possible that because the roads come first in the map area, the game might be more inclined to to include them. Then again, if the game engine spawns a road section somewhere, it might have to re-work the whole map so that the road goes across. In either case, the probabilities of a N/S or E/W road configuration should be identical so perhaps more trials are needed to gain a better understanding. --[[User:Zombie|Zombie]] 00:42, 14 February 2008 (PST)

----

Finally got around to pulling in the figures.

*Total number with WE roads on their own: 456 ( 23.59027 %, or 31.46998 % of single road maps)
*Total number with NS roads on their own: 993 ( 51.37093 %, or 68.53002 % of single road maps)
*Total number with WE roads: 940 ( 48.62907 %)
*Total number with NS roads: 1477 ( 76.40973 %)
*Total number with both roads: 484 ( 25.0388 %)
*Total number with no roads: 0 ( 0 %)
*Total number with a single road: 1449 ( 74.9612 %)
*Total trials: 1933

- [[User:Bomb Bloke|Bomb Bloke]] 22:07, 17 March 2009 (EDT)

==Map Sizes==

XcomUtil may generate oddly shaped maps?

- BB

----

No, but the engine should accept rectangular maps (at least TFTD does, in the case of the ships). BladeFireLight once designed a Battlefield Generator that was supposed to allow you to create your own maps but i never quite figured it out.

- [[User:Hobbes|Hobbes]] 13:52, 13 February 2008 (PST))

----

So XcomUtil didn't generate those 60x60x2 alien bases?

UFO does support rectangular maps, and even maps more then four units high. My [http://www.strategycore.co.uk/forums/?showtopic=598&st=80#entry70168 throwing logger] generates them to spec, but the maps aren't intended for playing on.

There were also some odd issues where adding extra levels would cause all sorts of rendering artefacts... Can't quite remember how high you had to push things for that to happen.

- [[User:Bomb Bloke|Bomb Bloke]] 17:36, 13 February 2008 (PST)

----

I'm not sure about the 6x6x2 alien bases anymore, might just be my memory playing tricks on me.~

- [[User:Hobbes|Hobbes]] 12:34, 18 February 2008 (PST)

----

I guess you'll have to trust me on this one, but base assault mission are generated by code starting at 0x0044D030 ; there you can see:

.text:0044D042 mov eax, 5
.text:0044D047 add esp, 0Ch
.text:0044D04A mov pGeodata.map_xsize_10, ax
.text:0044D050 mov pGeodata.map_ysize_10, ax
.text:0044D056 mov pGeodata.map_zsize, 2
.text:0044D05F mov pGeodata.terrain_type, 4
.text:0044D068 mov pGeodata.craftsToDraw, 0
.text:0044D06F mov word ptr missionDescriptor, 3 ; 3 -> base offense

which means (if you're not fluent in x86 ;) ) that the alien assaults maps are hard coded to 5x5x2 size.

Similarly for base defense, you'll find:
.text:0044CD6B mov eax, 2
.text:0044CD70 mov ebx, 6
.text:0044CD75 mov pGeodata.map_zsize, ax
.text:0044CD7B mov word ptr missionDescriptor, ax ; 2 -> base defense
.text:0044CD81 add esp, 0Ch
.text:0044CD84 mov pGeodata.map_xsize_10, bx
.text:0044CD8B mov pGeodata.map_ysize_10, bx
.text:0044CD92 mov pGeodata.terrain_type, 3
.text:0044CD9B mov pGeodata.craftsToDraw, 0

which translates into 6x6x2 map size. [[User:Seb76|Seb76]] 14:12, 18 February 2008 (PST)

==Units VS PSUs==

Arrow, please discuss here before you edit this stuff... hmm... I'm going to look for an editor, and see what happens if I hack Mutons to have 250 Health and 250 armor in all directions. If my suspicions are correct, the UPS explosion will STILL kill them... anyone know which editor can edit Muton stats and UPS explosion damage? ... I haven't seen any editors which can do that, so far... [[User:Jasonred|Jasonred]] 12:45, 17 March 2009 (EDT)

:I admit I was a bit hasty in editing; I'm fairly low on sleep. I would ask you recall to do the same on some other pages. :) IIRC, from Zombie's The UFO power source explosion actually exceeds a Blaster Bomb in power. What I think happens is that the game might respawn some aliens after the explosion in the event they're all killed by the blast, as a failsafe. If no aliens are present, the battle would never begin because the aliens would never pass the "Any units alive?" check before the beginning of Turn 1. And I have seen wounded aliens near Power Source explosions on occasion. So it is possible. [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:05, 17 March 2009 (EDT)

: I bet the Mutons survive, as I see plenty of merely damaged aliens from power plant explosions (CE Edition). -- [[User:Zaimoni|Zaimoni]], 14:21 17 Mar 2009 (CDT)

:: ... Ok... I need to either get an editor or bring in Mind-Probes to confirm this... [[User:Jasonred|Jasonred]] 18:22, 17 March 2009 (EDT)

Ah, but there's always some aliens OUTSIDE the spaceship, right? Is it hard-coded always, or is it just very very very likely that there will be aliens outside the ship? ... hmmm... but, as I've said... the UPS explosion behaves very strangely. The inconsistant blast pattern, among other things. If you tried to SIMULATE a UPS explosion by editting Heavy Explosives, and set them off right in the center of a Medium Scout, you would get the same blast pattern every single time. A crashed Medium Scout can have anything ranging from the floor ceiling and walls being intact to a hole in the ceiling to near total annihilation with even the outer hull shredded. ... Heck, you can usually recover an intact UFO navigation from a crashed medium scout. Try firing off a Blaster Bomb in the middle of one, and see what happens...

I definitely agree with your failsafe theory... every combat MUST start with live aliens. But I think that is in ADDITION to any weird behaviour exhibited by the UPS kaboom.

Just checked... UPS blows with strength 215, but has a random modifier too... they already know that UPS boom is weird vs terrain. Let's see how weird it is vs units...

: A Medium Scout where no aliens spawn outside is rather likely to start with zero aliens. This is most common on Beginner (have seen twice in ??? missions). Saving the game is impractical as the battle ends before XCOM starts its first turn. -- [[User:Zaimoni|Zaimoni]], 14:12 17 Mar 2009 (CDT)

:: Eh... really? So you CAN start a mission with zero aliens? Interesting... what version of the game are you playing, BTW?
:: Eh... this gives me a thought for yet another crackpot theory... which is about the spawning of units for the higher difficulty levels... I tend to find quite a number of aliens inside the UFO to be much greater on Superhuman... maybe the "extra" aliens from superhuman were spawned after the UPS explosion?
:: Eh... come to think of it... if it ended so quick, how do you know the map had zero aliens? Maybe it was tactical.exe crashing and made you think the mission succeeded, but it was just the prior mission results?
[[User:Jasonred|Jasonred]] 18:22, 17 March 2009 (EDT)

::: As mentioned above: CE edition (XCOMUtil'd, as the graphics need patching to display at all; however, the only binary executable code patching XCOMUtil does is to remove the Difficulty Bug). The forked tactical.exe did not crash; the start of the turn is displayed properly, I get a brief glimpse of the BattleScape, and then the Mission Over sequence. No reaction time to speak of. -- [[User:Zaimoni|Zaimoni]], 18:10 17 Mar 2009 (CDT)

:: If the mission results says success and no aliens killed, no aliens captured, that's a pretty good hint the exe didn't crash. Your previous mission presumably had kills. No survivors happens, from time to time. [[User:Knan|Knan]] 19:18, 17 March 2009 (EDT)

: It's not uncommon for a crash to kill all units in TFTD, however in that case you get a message stating that's exactly what happened. I cannot remember it happening in UFO, though I've had aliens non-fatally injured by the UPS explosion. Also seen them knocked out from it, but that could be due to subsequent exposure to smoke (never done a proper check into the matter).

: Remember that units under alien control never sustain fatal wounds, so you won't notice an alien was "just winged" by the blast unless you mind control/probe it. Less health means a unit will go down to smoke faster, too.

: XCU does not edit the CE game executable to remove the difficulty bug. That version of the game doesn't have it in the first place. f0dder's loader is what fixes the graphics (that edits the binary executable code, but only the copy you're running in RAM, not the original file).

: - [[User:Bomb Bloke|Bomb Bloke]] 00:29, 18 March 2009 (EDT)

I'm not really sure when aliens are spawned on a map. My assumption is that they are placed there after the map is generated but before the Power Source(s) has/have exploded ''(this is correct - BB)''. Because of the high spawn priorities for aliens inside the Medium Scout, you would think there would be a high probability that the aliens which do spawn would all be killed. This is far more likely to happen on Beginner than on the higher difficulty settings because less aliens will be present and the probability of them spawning inside the craft high. When you get to Superhuman, there are usually a lot more aliens than spawn points inside the craft and this results in more showing up around the landscape. But this type of auto-win mission is still hard to come by. The reason is two-fold. First, just because a spawn point has a priority of 10, it doesn't mean that point will automatically get filled before another one with a priority of 1. It's a weighted probability, so in this example, there would be a 10/11 (90.91%) chance the alien will go in the 10 priority while there is a 1/11 (9.09%) chance it will spawn in the 1 priority. Secondly (and this is the kicker), the landscape plays a huge role in where aliens will get placed. For example, on the farm landscape, there are a few high-priority spawn points within the buildings which dilutes the probability of aliens all going within the craft. In the same manner, a landscape may have a lot of low priority spawn points which lowers the probability too.

As for how much damage a unit will take from a UFO PS explosion, I don't know. I'm only up to gathering numbers on the amount of recoverables. But it shouldn't be too hard to bash together a testing scenario. I think the one problem I had before was that the damage for the explosion was so high that it forced me to edit soldier armor to compensate (even with 255 health). More armor would skew the results more. I suppose the easiest way would be to edit the blast strength of the PS explosion to a small (but constant) level to avoid the armor problems. --[[User:Zombie|Zombie]] 00:56, 18 March 2009 (EDT)

: Just to add my experience, I've had the auto-win scenario happen to me with the medium scout a few times before after painstakingly arming my troops to an exact configuration. You tend to remember something like that! I've had it happen in both the dos version (untainted) and CE (XComutil split executable). I suppose it was one of those odd occasions where all aliens just happened to spawn inside the UFO. -[[User:NKF|NKF]] 02:02, 18 March 2009 (EDT)

:: This is all VERY interesting to me... learnt a lot. Hmmm... Explosions do a minimum of 50% damage to units, right? So, how can a sectoid/floater survive 50% of a 180 damage explosion? ... intruiging... OH YEAH, I remember the TFTD no survivors thing! Those were hilarious... One more thing... am I going senile things, or is it possible for Navigation to be intact when the UPS blows up? ... maybe I am confusing the large scout results? ... hmmm.... [[User:Jasonred|Jasonred]] 03:36, 18 March 2009 (EDT)

:::On occasion, the Navigation will survive a power source explosion in a Medium Scout. However, this is not a particularly reliable means of acquiring UFO Navigations. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:36, 18 March 2009 (EDT)

:: Yeah, that's what I thought... however, doesn't a UPS explode with minimum strength 180? Cause it looks like the Console Navigations only have 40 armor, and they're not actually that far away from the blast, I'm surprised that they can survive at all? Anyhow, heh, I find that I have many more Navigations than Power Sources... but X-com craft either need 1N1P, or 1N,2P.My fleet of Avengers means that my required ratio is close to 2 Power Source to 1 Navigation. [[User:Jasonred|Jasonred]] 06:01, 18 March 2009 (EDT)

At least from my tests on the UFO Crash Recovery [[Talk:UFO_Crash_Recovery|Talk Page]] navigations never survive a crash where the power source explodes. How can a Sectoid survive? Well, if it spawns between the chair and the wall, the chair will absorb some of the blast strength. Also, at that distance, the explosion goes to facing armor, not under armor which may be just enough to keep it alive. --[[User:Zombie|Zombie]] 11:16, 18 March 2009 (EDT)

:How much HEB does the chair have? It's not listed on the explosions page. [[User:Jasonred|Jasonred]] 11:38, 18 March 2009 (EDT)

Chairs have 20 HEB. So that means the min damage on the tile beyond that is 40. Sectoids have a max health rating of 30 and front armor of 4. That's still 6 points short of surviving though. Don't really know what's going on there. --[[User:Zombie|Zombie]] 22:30, 18 March 2009 (EDT)

: Any chance the minimum blast strength varies from craft to craft? - [[User:Bomb Bloke|Bomb Bloke]] 23:16, 18 March 2009 (EDT)

:: OOH... that's an interesting thought! Yes, I have noticed that the number of survivors does seem to correlate to the destruction level... Hmmm hmmm hmmm... well, maybe someone can perform the happy fun test where they blow up aliens using UPS modules, over and over and over, lol...
:::The explosion power is hard coded and does not change with craft type, damage taken during dogfight or whatever other things like time of the day or planet alignment... [[User:Seb76|Seb76]] 14:19, 19 March 2009 (EDT)

== KABOOM!! ==

The game does actually feature vertical damage from explosions, and not only for UPS. I guess the reason it's believed otherwise is that the flying armor gives good protection against ground explosions. The UPS explosion being up to 250 in explosive power can destroy roof tiles, as well as a modified blaster bomb would. And I can assure you that UPS explosions use the same routine as standard explosions ;-) [[User:Seb76|Seb76]] 15:11, 17 March 2009 (EDT)

: Other than the fact that UPS does 215 +/- 35 damage to terrain? hmm... Wait, methinks me gets that part... sort of... basically, the initial strength of the explosion is randomly determined, then it henceforth behaves like a normal explosion? ... How much damage is applied to alien units nearby then? Do they get hit for the full damage or something? ... Sigh... I need to wait until my current game reaches the point where I have a full developed Psi Corps.

: As for vertical damage from explosions, er... SORT OF. Explosions do vertical damage, but only to floor/roof tiles. Units and objects appear to be untouched. Not only flying armor, even Floaters and Ethereals will be completely untouched by an explosion occuring underneath them. I have been wondering about that, actually...

:[[User:Jasonred|Jasonred]] 18:22, 17 March 2009 (EDT)

Just thought I would point out. You can have all aliens killed during the blast, you get a message that all aliens died and tactical ends. --[[User:BladeFireLight|BladeFireLight]] 13:07, 1 April 2012 (EDT)

Talk:XcomUtil

2010-07-12T01:07:23Z

BladeFireLight: /* Build 442 */ Yes they are Features

=XcomUtil 9.7 Beta=

9.7 Beta is available on www.bladefirelight.com

==Release Notes==

This is a Beta, so backup your files before using. And check back often for newer builds.

New in this version.

*Major overhall of the installer (XcuSetup) and the inclusion of 16/32bit exe's to support both DOSBox and Windows Vista/7 x64.
*New subfolders added to hold supporting files making the install cleaner
*New XcuSetup command line arguments were added to XcuSetup allowing for silent install and uninstallation.
*New XcuSetup option for debugging the install (XcuSetup debug) creating XcomUtil\debug.txt.
*New command line argument "nobackup" skips backup only if it has been ran atleast once.
*XcuSetup can now have minimal impact on the game.
**Almost all options default to NO (Only Split Windows EXE set to Yes).
**Almost all changes are now prompted for (skyranger guns, interceptor as transport, Disjointed Base Bug, etc...).
***Items still done by default:
***Copy protection questions set to 0000000 for UFO 1.0-1.3 and X-Com 1.0
***Difficulty bug fixed in UFO 1.0-1.4 and X-Com 1.0-1.4
***Unique names for all maps in TFTD, Used for Hybrid Games
***Placement of X-Com Units on the Battlefield based on XcomUtil.cfg
***MIA Recovery on Won Combat (Units under mind\MC control when last controling alien killed are returned to X-Com control)
*XcomUtil.cfg is now pieced together and overwritten by XcuSetup (see XcomUtil\XcomUtil.txt for how to make permanent changes).
*All game files are restored to the pre-XcomUtil state each time XcuSetup is ran. Any modifications by other utilities will have to be re-applied.
*Vista/Win7 patch now an option for XcuSetup.
**This will fix the blank screen issue.
**Updated to support the split EXE.
**Will set X-Com to use CPU 0.
*XcuSetup attempts to fix UAC issues by resetting folder permissions.
*A number of community made fixes are included and selectable with XcuSetup.
*Support for the DOS/Window STEAM Install.
**Installer will detect STEAM and change steam launcher to start the XcomUtil Steam Menu (can be re-installed with XcomUtil\SteamSetup.bat
*Out of the box support for UFO Extender. XcuSetup will detect it and ask if you want RunXcom to use it.
*XcuSetup can be run from windows and RunXcom run from DosBox
*Hybrid Colors updated based on BombBloke's pallets.
*EQL flag allowed any turn.
*Add Xcom UFO Italian Support.
*Auto Combat will not run on second half of two part using first parts saved data.
*Auto Combat will no longer run if combat was won.
*MIA Recovery on won combat only.
*MIA Recovery no longer recovering units that bleed to death.
*Auto equip no longer triggers on second part of 2 stage missions.
*Combine clips skiped if between stages of 2-3 part missions.
*Updated f0dders ReadMe per his request. (XcomUtil\bugfix-readme.txt)
*Add-on support added. see XcomUtil\XcomUtil.txt and XcomUtil\Addon\Example.txt
*Prompted Terrain in BattleField Generator allows to abort or use of current setting.
*Beta versions include
**XcomUtil\XcomUtil.log includes lots of debug info
**XcomUtil\Debug.txt created by default (Release will need "debug" command argument)

Removed from this versions

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

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

===Build 435===

Original Sound Effects from UFO were re-sampled to work with 1.4 and CE.

*Add Category to option headers.
*Improve randomness by using current time instead of game date/time in srand()
*Added Option to keep Current terrain/UFO to BFG.
*Original UFO 1.2 Sounds for Geoscape and Tactical added as an option for UFO 1.4 and CE.
*Force Split EXE on STEAM. Fixes issues with setup failing.
*Reset Laser/Gauss craft weapons stats to be default.
*Example addon now uses different flag extension to avoid deletion by XcuSetup
*fix issue with Lab Screen on DosBox always screening

===Build 442===

*Add Batch file for Java Terrain Editor as an example for thoes that want to use it.
*Fix BFG placement of units in Alien Base Terrain.
*Autocombat: All units with health <= fatal wounds dies before autocombat calculates win threshold.
*Autocombat: Fixed MIA units on WIN.

--[[User:BladeFireLight|BladeFireLight]] 18:16, 26 March 2010 (EDT)

==Beta Discussion==

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

----

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

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

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

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

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

----

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

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

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

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

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

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

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

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

=== Categorise Config Options ===

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

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

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

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

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

* Dart Gun

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=== Focused Research Help ===

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

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

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

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

== Features for 9.8+ - New features ==

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

=== Improved Base Comes At Cost ===

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

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

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

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

=== AutoCombat ===

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

==== AutoWithdrawal ====

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

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

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

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

=== Tougher UFOs ===

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

=== Rebalanced Craft Weapons ===

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

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

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

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

==== Fusion Ball Launcher ====

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

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

==== Cost Based Approach ====

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

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

See [[User:Spike#Cost_Based_Rebalancing]]

==== Stat Based Approach ====

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

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

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

See [[User:Spike#Stat_Based_Rebalancing]]

=== Rebalanced Infantry Weapons ===

See [[User:Spike#Balancing_Infantry_Weapons]]

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

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

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

=== Rebalanced X-COM craft ===

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

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

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

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

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

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

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

=== SWP switch expansion ===

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

A few ideas off the top of my head:

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

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

==See Also==

[[Wish List]]

= Completed Wish List Items =

=== BFG Default To Unchanged ===

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

= MISC =

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

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

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

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

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

Talk:XcomUtil

2010-03-26T22:24:47Z

BladeFireLight: /* Fixed Bugs */

=XcomUtil 9.7 Beta=

9.7 Beta is available on www.bladefirelight.com

==Release Notes==

This is a Beta, so backup your files before using. And check back often for newer builds.

New in this version.

*Major overhall of the installer (XcuSetup) and the inclusion of 16/32bit exe's to support both DOSBox and Windows Vista/7 x64.
*New subfolders added to hold supporting files making the install cleaner
*New XcuSetup command line arguments were added to XcuSetup allowing for silent install and uninstallation.
*New XcuSetup option for debugging the install (XcuSetup debug) creating XcomUtil\debug.txt.
*New command line argument "nobackup" skips backup only if it has been ran atleast once.
*XcuSetup can now have minimal impact on the game.
**Almost all options default to NO (Only Split Windows EXE set to Yes).
**Almost all changes are now prompted for (skyranger guns, interceptor as transport, Disjointed Base Bug, etc...).
***Items still done by default:
***Copy protection questions set to 0000000 for UFO 1.0-1.3 and X-Com 1.0
***Difficulty bug fixed in UFO 1.0-1.4 and X-Com 1.0-1.4
***Unique names for all maps in TFTD, Used for Hybrid Games
***Placement of X-Com Units on the Battlefield based on XcomUtil.cfg
***MIA Recovery on Won Combat (Units under mind\MC control when last controling alien killed are returned to X-Com control)
*XcomUtil.cfg is now pieced together and overwritten by XcuSetup (see XcomUtil\XcomUtil.txt for how to make permanent changes).
*All game files are restored to the pre-XcomUtil state each time XcuSetup is ran. Any modifications by other utilities will have to be re-applied.
*Vista/Win7 patch now an option for XcuSetup.
**This will fix the blank screen issue.
**Updated to support the split EXE.
**Will set X-Com to use CPU 0.
*XcuSetup attempts to fix UAC issues by resetting folder permissions.
*A number of community made fixes are included and selectable with XcuSetup.
*Support for the DOS/Window STEAM Install.
**Installer will detect STEAM and change steam launcher to start the XcomUtil Steam Menu (can be re-installed with XcomUtil\SteamSetup.bat
*Out of the box support for UFO Extender. XcuSetup will detect it and ask if you want RunXcom to use it.
*XcuSetup can be run from windows and RunXcom run from DosBox
*Hybrid Colors updated based on BombBloke's pallets.
*EQL flag allowed any turn.
*Add Xcom UFO Italian Support.
*Auto Combat will not run on second half of two part using first parts saved data.
*Auto Combat will no longer run if combat was won.
*MIA Recovery on won combat only.
*MIA Recovery no longer recovering units that bleed to death.
*Auto equip no longer triggers on second part of 2 stage missions.
*Combine clips skiped if between stages of 2-3 part missions.
*Updated f0dders ReadMe per his request. (XcomUtil\bugfix-readme.txt)
*Add-on support added. see XcomUtil\XcomUtil.txt and XcomUtil\Addon\Example.txt
*Prompted Terrain in BattleField Generator allows to abort or use of current setting.
*Beta versions include
**XcomUtil\XcomUtil.log includes lots of debug info
**XcomUtil\Debug.txt created by default (Release will need "debug" command argument)

Removed from this versions

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

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

===Build 435===

Original Sound Effects from UFO were re-sampled to work with 1.4 and CE.

*Add Category to option headers.
*Improve randomness by using current time instead of game date/time in srand()
*Added Option to keep Current terrain/UFO to BFG.
*Original UFO 1.2 Sounds for Geoscape and Tactical added as an option for UFO 1.4 and CE.
*Force Split EXE on STEAM. Fixes issues with setup failing.
*Reset Laser/Gauss craft weapons stats to be default.
*Example addon now uses different flag extension to avoid deletion by XcuSetup
*fix issue with Lab Screen on DosBox always screening

===Build 442===

*Add Batch file for Java Terrain Editor as an example for thoes that want to use it.
*Fix BFG placement of units in Alien Base Terrain.
*Autocombat: All units with health <= fatal wounds dies before autocombat calculates win threshold.
*Autocombat: Fixed MIA units on WIN.

--[[User:BladeFireLight|BladeFireLight]] 18:16, 26 March 2010 (EDT)

==Beta Discussion==

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

----

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

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

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

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

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

----

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

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

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

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

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

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

=== Categorise Config Options ===

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

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

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

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

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

* Dart Gun

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=== Focused Research Help ===

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

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

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

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

== Features for 9.8+ - New features ==

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

=== Improved Base Comes At Cost ===

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

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

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

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

=== AutoCombat ===

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

==== AutoWithdrawal ====

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

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

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

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

=== Tougher UFOs ===

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

=== Rebalanced Craft Weapons ===

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

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

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

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

==== Fusion Ball Launcher ====

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

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

==== Cost Based Approach ====

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

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

See [[User:Spike#Cost_Based_Rebalancing]]

==== Stat Based Approach ====

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

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

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

See [[User:Spike#Stat_Based_Rebalancing]]

=== Rebalanced Infantry Weapons ===

See [[User:Spike#Balancing_Infantry_Weapons]]

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

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

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

==See Also==

[[Wish List]]

= Completed Wish List Items =

=== BFG Default To Unchanged ===

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

= MISC =

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

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

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

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

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

Talk:XcomUtil

2010-03-26T22:19:30Z

BladeFireLight: /* Open Bugs */

=XcomUtil 9.7 Beta=

9.7 Beta is available on www.bladefirelight.com

==Release Notes==

This is a Beta, so backup your files before using. And check back often for newer builds.

New in this version.

*Major overhall of the installer (XcuSetup) and the inclusion of 16/32bit exe's to support both DOSBox and Windows Vista/7 x64.
*New subfolders added to hold supporting files making the install cleaner
*New XcuSetup command line arguments were added to XcuSetup allowing for silent install and uninstallation.
*New XcuSetup option for debugging the install (XcuSetup debug) creating XcomUtil\debug.txt.
*New command line argument "nobackup" skips backup only if it has been ran atleast once.
*XcuSetup can now have minimal impact on the game.
**Almost all options default to NO (Only Split Windows EXE set to Yes).
**Almost all changes are now prompted for (skyranger guns, interceptor as transport, Disjointed Base Bug, etc...).
***Items still done by default:
***Copy protection questions set to 0000000 for UFO 1.0-1.3 and X-Com 1.0
***Difficulty bug fixed in UFO 1.0-1.4 and X-Com 1.0-1.4
***Unique names for all maps in TFTD, Used for Hybrid Games
***Placement of X-Com Units on the Battlefield based on XcomUtil.cfg
***MIA Recovery on Won Combat (Units under mind\MC control when last controling alien killed are returned to X-Com control)
*XcomUtil.cfg is now pieced together and overwritten by XcuSetup (see XcomUtil\XcomUtil.txt for how to make permanent changes).
*All game files are restored to the pre-XcomUtil state each time XcuSetup is ran. Any modifications by other utilities will have to be re-applied.
*Vista/Win7 patch now an option for XcuSetup.
**This will fix the blank screen issue.
**Updated to support the split EXE.
**Will set X-Com to use CPU 0.
*XcuSetup attempts to fix UAC issues by resetting folder permissions.
*A number of community made fixes are included and selectable with XcuSetup.
*Support for the DOS/Window STEAM Install.
**Installer will detect STEAM and change steam launcher to start the XcomUtil Steam Menu (can be re-installed with XcomUtil\SteamSetup.bat
*Out of the box support for UFO Extender. XcuSetup will detect it and ask if you want RunXcom to use it.
*XcuSetup can be run from windows and RunXcom run from DosBox
*Hybrid Colors updated based on BombBloke's pallets.
*EQL flag allowed any turn.
*Add Xcom UFO Italian Support.
*Auto Combat will not run on second half of two part using first parts saved data.
*Auto Combat will no longer run if combat was won.
*MIA Recovery on won combat only.
*MIA Recovery no longer recovering units that bleed to death.
*Auto equip no longer triggers on second part of 2 stage missions.
*Combine clips skiped if between stages of 2-3 part missions.
*Updated f0dders ReadMe per his request. (XcomUtil\bugfix-readme.txt)
*Add-on support added. see XcomUtil\XcomUtil.txt and XcomUtil\Addon\Example.txt
*Prompted Terrain in BattleField Generator allows to abort or use of current setting.
*Beta versions include
**XcomUtil\XcomUtil.log includes lots of debug info
**XcomUtil\Debug.txt created by default (Release will need "debug" command argument)

Removed from this versions

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

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

===Build 435===

Original Sound Effects from UFO were re-sampled to work with 1.4 and CE.

*Add Category to option headers.
*Improve randomness by using current time instead of game date/time in srand()
*Added Option to keep Current terrain/UFO to BFG.
*Original UFO 1.2 Sounds for Geoscape and Tactical added as an option for UFO 1.4 and CE.
*Force Split EXE on STEAM. Fixes issues with setup failing.
*Reset Laser/Gauss craft weapons stats to be default.
*Example addon now uses different flag extension to avoid deletion by XcuSetup
*fix issue with Lab Screen on DosBox always screening

===Build 442===

*Add Batch file for Java Terrain Editor as an example for thoes that want to use it.
*Fix BFG placement of units in Alien Base Terrain.
*Autocombat: All units with health <= fatal wounds dies before autocombat calculates win threshold.
*Autocombat: Fixed MIA units on WIN.

--[[User:BladeFireLight|BladeFireLight]] 18:16, 26 March 2010 (EDT)

==Beta Discussion==

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

----

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

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

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

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

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

----

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

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

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

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

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

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

=== Categorise Config Options ===

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

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

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

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

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

* Dart Gun

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=== Focused Research Help ===

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

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

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

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

== Features for 9.8+ - New features ==

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

=== Improved Base Comes At Cost ===

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

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

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

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

=== AutoCombat ===

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

==== AutoWithdrawal ====

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

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

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

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

=== Tougher UFOs ===

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

=== Rebalanced Craft Weapons ===

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

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

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

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

==== Fusion Ball Launcher ====

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

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

==== Cost Based Approach ====

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

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

See [[User:Spike#Cost_Based_Rebalancing]]

==== Stat Based Approach ====

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

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

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

See [[User:Spike#Stat_Based_Rebalancing]]

=== Rebalanced Infantry Weapons ===

See [[User:Spike#Balancing_Infantry_Weapons]]

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

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

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

==See Also==

[[Wish List]]

= Completed Wish List Items =

=== BFG Default To Unchanged ===

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

= MISC =

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

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

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

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

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

Talk:XcomUtil

2010-03-26T22:16:26Z

BladeFireLight: /* Build 442 */

=XcomUtil 9.7 Beta=

9.7 Beta is available on www.bladefirelight.com

==Release Notes==

This is a Beta, so backup your files before using. And check back often for newer builds.

New in this version.

*Major overhall of the installer (XcuSetup) and the inclusion of 16/32bit exe's to support both DOSBox and Windows Vista/7 x64.
*New subfolders added to hold supporting files making the install cleaner
*New XcuSetup command line arguments were added to XcuSetup allowing for silent install and uninstallation.
*New XcuSetup option for debugging the install (XcuSetup debug) creating XcomUtil\debug.txt.
*New command line argument "nobackup" skips backup only if it has been ran atleast once.
*XcuSetup can now have minimal impact on the game.
**Almost all options default to NO (Only Split Windows EXE set to Yes).
**Almost all changes are now prompted for (skyranger guns, interceptor as transport, Disjointed Base Bug, etc...).
***Items still done by default:
***Copy protection questions set to 0000000 for UFO 1.0-1.3 and X-Com 1.0
***Difficulty bug fixed in UFO 1.0-1.4 and X-Com 1.0-1.4
***Unique names for all maps in TFTD, Used for Hybrid Games
***Placement of X-Com Units on the Battlefield based on XcomUtil.cfg
***MIA Recovery on Won Combat (Units under mind\MC control when last controling alien killed are returned to X-Com control)
*XcomUtil.cfg is now pieced together and overwritten by XcuSetup (see XcomUtil\XcomUtil.txt for how to make permanent changes).
*All game files are restored to the pre-XcomUtil state each time XcuSetup is ran. Any modifications by other utilities will have to be re-applied.
*Vista/Win7 patch now an option for XcuSetup.
**This will fix the blank screen issue.
**Updated to support the split EXE.
**Will set X-Com to use CPU 0.
*XcuSetup attempts to fix UAC issues by resetting folder permissions.
*A number of community made fixes are included and selectable with XcuSetup.
*Support for the DOS/Window STEAM Install.
**Installer will detect STEAM and change steam launcher to start the XcomUtil Steam Menu (can be re-installed with XcomUtil\SteamSetup.bat
*Out of the box support for UFO Extender. XcuSetup will detect it and ask if you want RunXcom to use it.
*XcuSetup can be run from windows and RunXcom run from DosBox
*Hybrid Colors updated based on BombBloke's pallets.
*EQL flag allowed any turn.
*Add Xcom UFO Italian Support.
*Auto Combat will not run on second half of two part using first parts saved data.
*Auto Combat will no longer run if combat was won.
*MIA Recovery on won combat only.
*MIA Recovery no longer recovering units that bleed to death.
*Auto equip no longer triggers on second part of 2 stage missions.
*Combine clips skiped if between stages of 2-3 part missions.
*Updated f0dders ReadMe per his request. (XcomUtil\bugfix-readme.txt)
*Add-on support added. see XcomUtil\XcomUtil.txt and XcomUtil\Addon\Example.txt
*Prompted Terrain in BattleField Generator allows to abort or use of current setting.
*Beta versions include
**XcomUtil\XcomUtil.log includes lots of debug info
**XcomUtil\Debug.txt created by default (Release will need "debug" command argument)

Removed from this versions

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

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

===Build 435===

Original Sound Effects from UFO were re-sampled to work with 1.4 and CE.

*Add Category to option headers.
*Improve randomness by using current time instead of game date/time in srand()
*Added Option to keep Current terrain/UFO to BFG.
*Original UFO 1.2 Sounds for Geoscape and Tactical added as an option for UFO 1.4 and CE.
*Force Split EXE on STEAM. Fixes issues with setup failing.
*Reset Laser/Gauss craft weapons stats to be default.
*Example addon now uses different flag extension to avoid deletion by XcuSetup
*fix issue with Lab Screen on DosBox always screening

===Build 442===

*Add Batch file for Java Terrain Editor as an example for thoes that want to use it.
*Fix BFG placement of units in Alien Base Terrain.
*Autocombat: All units with health <= fatal wounds dies before autocombat calculates win threshold.
*Autocombat: Fixed MIA units on WIN.

--[[User:BladeFireLight|BladeFireLight]] 18:16, 26 March 2010 (EDT)

==Beta Discussion==

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

----

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

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

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

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

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

----

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

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

----

I have a strange issue. I succeed in an AutoCombat terror mission (117%) but the mission is resolved partially as if I had actually aborted the mission - all Civilians die, even though I could see 3-4 alive, my 13 soldiers outside the Skyranger go MIA, even the one who was killed by AutoCombat, and only my sergeant standing in the Skyranger makes it back. The problem is repeatable. On one occasion the sergeant was killed randomly by AutoCombat, meaning that the Skyranger flew back by itself, empty. Obviously this should never happen.

I've uploaded the [[Media:MIAoverload.zip|AutoCombat game save file]]. Incidentally this shows how to 'game' the current AutoCombat rules: Take maximum soldiers, no tanks. You give everyone a Rocket Launcher, they only need 1 Lg Rocket in it. Until you get Heavy Lasers, then replace the Rocket Launchers with them. Next replace with Heavy Plasmas. This approach always gives you maximum damage per soldier, and thus maximum chance of getting the +15 bonus for the W:3- rule. [[User:Spike|Spike]] 19:02, 15 March 2010 (EDT)

:: Hmmm. Scott's MIA recovery raised an army of undead from those that died of fatal wounds. Mine only effects mind controlled units. The issue is telling who is dead and who is left behind.

Units from your saved game looked like this(on by Autocombat).

Shuji Okabe: Left behind (Health > 0)
[[UNITPOS.DAT|UnitPos]][0x0A] 1.0.0.0.0.0.0.0 (bit 2 == 0 Unit on the ground[dead or unconscious])
[[UNITREF.DAT|UnitRef]][0x78] 0.0.0.0.0.0.1.0 (bit 1 == 0 Unit Alive)
Yoko Fujimoto: On Craft (Health > 0)
UnitPos[0x0A] 1.1.0.0.0.0.0.0 (bit 2 == 1 Unit Standing [Active])
UnitRef[0x78] 0.0.0.1.0.0.0.0 (bit 1 == 0 Unit Alive)

From Bomb Blokes undead army MIA Test save (won by killing aliens).

Spencer Bryant: Lived (Health > 0)
[[UNITPOS.DAT|UnitPos]][0x0A] 0.1.0.0.0.1.0.0 (bit 2 == 1 Unit Standing [Active])
[[UNITREF.DAT|UnitRef]][0x78] 0.1.0.0.0.0.0.1 (bit 1 == 0 Unit Alive)
Oscar Thompson: Bleed to death (Health > 0)
UnitPos[0x0A] 0.0.0.0.0.1.0.0 (bit 2 == 0 Unit on the ground[dead or unconscious])
UnitRef[0x78] 0.1.0.0.0.0.0.1 (bit 1 == 0 Unit Alive)
Virgil Hudson: Killed by Aliens (Health == 0)
UnitPos[0x0A] 0.0.0.0.0.1.0.0 (bit 2 == 0 Unit on the ground[dead or unconscious])
UnitRef[0x78] 1.1.0.0.0.0.0.1 (bit 1 == 1 Unit Dead)

So right now I'm at a loss of how to detect tell the difference between thoes that are left behind and thoes that are dead.

:There must be something odd about my save game that takes 13 live soldiers and makes them all MIA on an abort. I wonder if it is something to do with the one guy who is still on the transport. I'm sure I've never seen an MIA after an AutoCombat victory, or defeat, before. Of course, after a victory, no one should be MIA. In a defeat, in theory AutoCombat could (but doesn't?) allocate some soldiers as MIAs. For the bleeding to death problem, perhaps you could check whether Health <= Fatal Wounds. In the normal game this might be an ambiguous borderline case? Treat it unambiguously - kill any soldiers matching that condition. In XComUtil after-combat messages, perhaps emit the message "So-and-so died from his/her wounds aboard the transport".
:But I guess the problem is not what XComUtil does, but how to "communicate" back to the game engine that the soldiers are alive and well and not MIA? Surely the game's logic must be '''first''' to determine if the battle was aborted, and only then to decide who was left behind on the battlefield vs who died vs who was on the transport and got home? Surely Scott's logic must intercept this abort flag, and ''then un-set it''?.
:By the way, in the listing above I'm not sure whether the least significant bit is at the left or the right? [[User:Spike|Spike]] 20:31, 16 March 2010 (EDT)
:: I'm guessing it's a bitfield not a number, so LSB/MSB doesn't exist. [[User:Cesium|Cesium]] 21:27, 16 March 2010 (EDT)
::: Yes it's a bit field. I linked to the wiki page with the description. The game engine doesn't need to tell why some one got removed from the game. Tatical calculates the score. --[[User:BladeFireLight|BladeFireLight]] 21:38, 16 March 2010 (EDT)

:::: Thanks for clarifying. I had checked the links, read the bits your way, then had doubts as the description seems the other way round, ie Bit 1 at the end. So, do all 13 of my guys have this "on the ground" flag set? Very weird as none were stunned or dead. They were in smoke with minor stun damage is all. And moving the Sgt off the transport gains nothing, I just get 14 MIAs instead of 13. The wacky thing is the screen says Aliens Defeated and gives me loot - even when the transport is lost. [[User:Spike|Spike]] 22:36, 16 March 2010 (EDT)
:: Ok I have a solution I'm working on. Turns out those that bleed to death are being counted by Autocombat as being in play. Autocombat is not instantaneous, so Everyone with health <= wounds get health = 0 then all units with Health != 0 are marked as not dead.
::: Good to have a solution to the bleeding to death issue. Does that shed any light on how 14 non-wounded, non-bleeding, healthy, XCom controlled soldiers suddenly turn MIA at the end of a mission that is an XCom victory? Or is that a different issue?
::: By the way I checked my savegame, and if I move all the soldiers back to the transport prior to Abort Mission / AutoCombat, there are no MIAs any more after AutoCombat. So it sounds again like the situation is being handled like part victory (all aliens are dead, UFO Navigation loot) and part Abort. [[User:Spike|Spike]] 19:46, 17 March 2010 (EDT)
:::: They are both related.
::::* When you bleed to death your health never reaches 0. you are left alive with ~1-5 hit points, but marked as on the ground and tactical ups the KIA Score.
::::* When you are not in the craft on abort. Tactical marks you as on the ground and increases the MIA score.
::::* Geoscape looks at: If Health = 0, or if unit on the gorund (dead, unconscious, left behind) the units is removed from the game.
:::: To fix this I could not just mark everyone on the ground as standing (active) or the ones that already bleed to death are raised from the dead. So I check if Fatal wounds >= Health and then kill the unit by marking health to 0. then I can take the remainder of those that are not on the craft and mark them as active so Geoscape keeps them. I get the added bonus of not having bleed to death units calculated in autocombat as a + to X-Com's score, and autocombat would take at least one round so units one turn from death would die anyway. This is done as part of autocombat and not the standard MIA function that runs on every combat, as I dont want to kill off units that are truly alive. Yes they would probably die on the trip home. but I assume that the skyranger has a non man-portable trauma kit. --[[User:BladeFireLight|BladeFireLight]] 03:21, 18 March 2010 (EDT)

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

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

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

=== Categorise Config Options ===

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

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

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

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

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

* Dart Gun

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=== Focused Research Help ===

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

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

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

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

== Features for 9.8+ - New features ==

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

=== Improved Base Comes At Cost ===

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

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

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

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

=== AutoCombat ===

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

==== AutoWithdrawal ====

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

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

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

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

=== Tougher UFOs ===

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

=== Rebalanced Craft Weapons ===

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

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

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

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

==== Fusion Ball Launcher ====

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

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

==== Cost Based Approach ====

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

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

See [[User:Spike#Cost_Based_Rebalancing]]

==== Stat Based Approach ====

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

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

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

See [[User:Spike#Stat_Based_Rebalancing]]

=== Rebalanced Infantry Weapons ===

See [[User:Spike#Balancing_Infantry_Weapons]]

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

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

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

==See Also==

[[Wish List]]

= Completed Wish List Items =

=== BFG Default To Unchanged ===

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

= MISC =

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

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

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

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

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

Talk:XcomUtil

2010-03-26T22:16:11Z

BladeFireLight: /* Build 442 */

=XcomUtil 9.7 Beta=

9.7 Beta is available on www.bladefirelight.com

==Release Notes==

This is a Beta, so backup your files before using. And check back often for newer builds.

New in this version.

*Major overhall of the installer (XcuSetup) and the inclusion of 16/32bit exe's to support both DOSBox and Windows Vista/7 x64.
*New subfolders added to hold supporting files making the install cleaner
*New XcuSetup command line arguments were added to XcuSetup allowing for silent install and uninstallation.
*New XcuSetup option for debugging the install (XcuSetup debug) creating XcomUtil\debug.txt.
*New command line argument "nobackup" skips backup only if it has been ran atleast once.
*XcuSetup can now have minimal impact on the game.
**Almost all options default to NO (Only Split Windows EXE set to Yes).
**Almost all changes are now prompted for (skyranger guns, interceptor as transport, Disjointed Base Bug, etc...).
***Items still done by default:
***Copy protection questions set to 0000000 for UFO 1.0-1.3 and X-Com 1.0
***Difficulty bug fixed in UFO 1.0-1.4 and X-Com 1.0-1.4
***Unique names for all maps in TFTD, Used for Hybrid Games
***Placement of X-Com Units on the Battlefield based on XcomUtil.cfg
***MIA Recovery on Won Combat (Units under mind\MC control when last controling alien killed are returned to X-Com control)
*XcomUtil.cfg is now pieced together and overwritten by XcuSetup (see XcomUtil\XcomUtil.txt for how to make permanent changes).
*All game files are restored to the pre-XcomUtil state each time XcuSetup is ran. Any modifications by other utilities will have to be re-applied.
*Vista/Win7 patch now an option for XcuSetup.
**This will fix the blank screen issue.
**Updated to support the split EXE.
**Will set X-Com to use CPU 0.
*XcuSetup attempts to fix UAC issues by resetting folder permissions.
*A number of community made fixes are included and selectable with XcuSetup.
*Support for the DOS/Window STEAM Install.
**Installer will detect STEAM and change steam launcher to start the XcomUtil Steam Menu (can be re-installed with XcomUtil\SteamSetup.bat
*Out of the box support for UFO Extender. XcuSetup will detect it and ask if you want RunXcom to use it.
*XcuSetup can be run from windows and RunXcom run from DosBox
*Hybrid Colors updated based on BombBloke's pallets.
*EQL flag allowed any turn.
*Add Xcom UFO Italian Support.
*Auto Combat will not run on second half of two part using first parts saved data.
*Auto Combat will no longer run if combat was won.
*MIA Recovery on won combat only.
*MIA Recovery no longer recovering units that bleed to death.
*Auto equip no longer triggers on second part of 2 stage missions.
*Combine clips skiped if between stages of 2-3 part missions.
*Updated f0dders ReadMe per his request. (XcomUtil\bugfix-readme.txt)
*Add-on support added. see XcomUtil\XcomUtil.txt and XcomUtil\Addon\Example.txt
*Prompted Terrain in BattleField Generator allows to abort or use of current setting.
*Beta versions include
**XcomUtil\XcomUtil.log includes lots of debug info
**XcomUtil\Debug.txt created by default (Release will need "debug" command argument)

Removed from this versions

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

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

===Build 435===

Original Sound Effects from UFO were re-sampled to work with 1.4 and CE.

*Add Category to option headers.
*Improve randomness by using current time instead of game date/time in srand()
*Added Option to keep Current terrain/UFO to BFG.
*Original UFO 1.2 Sounds for Geoscape and Tactical added as an option for UFO 1.4 and CE.
*Force Split EXE on STEAM. Fixes issues with setup failing.
*Reset Laser/Gauss craft weapons stats to be default.
*Example addon now uses different flag extension to avoid deletion by XcuSetup
*fix issue with Lab Screen on DosBox always screening

===Build 442===

*Add Batch file for Java Terrain Editor as an example for thoes that want to use it.
*Fix BFG placement of units in Alien Base Terrain.
*Autocombat: All units with health <= fatal wounds dies before autocombat calculates win threshold.
*Autocombat: Fixed MIA units on WIN.

--[[User:BladeFireLight|BladeFireLight]] 18:16, 26 March 2010 (EDT)

==Beta Discussion==

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

----

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

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

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

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

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

----

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

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

----

I have a strange issue. I succeed in an AutoCombat terror mission (117%) but the mission is resolved partially as if I had actually aborted the mission - all Civilians die, even though I could see 3-4 alive, my 13 soldiers outside the Skyranger go MIA, even the one who was killed by AutoCombat, and only my sergeant standing in the Skyranger makes it back. The problem is repeatable. On one occasion the sergeant was killed randomly by AutoCombat, meaning that the Skyranger flew back by itself, empty. Obviously this should never happen.

I've uploaded the [[Media:MIAoverload.zip|AutoCombat game save file]]. Incidentally this shows how to 'game' the current AutoCombat rules: Take maximum soldiers, no tanks. You give everyone a Rocket Launcher, they only need 1 Lg Rocket in it. Until you get Heavy Lasers, then replace the Rocket Launchers with them. Next replace with Heavy Plasmas. This approach always gives you maximum damage per soldier, and thus maximum chance of getting the +15 bonus for the W:3- rule. [[User:Spike|Spike]] 19:02, 15 March 2010 (EDT)

:: Hmmm. Scott's MIA recovery raised an army of undead from those that died of fatal wounds. Mine only effects mind controlled units. The issue is telling who is dead and who is left behind.

Units from your saved game looked like this(on by Autocombat).

Shuji Okabe: Left behind (Health > 0)
[[UNITPOS.DAT|UnitPos]][0x0A] 1.0.0.0.0.0.0.0 (bit 2 == 0 Unit on the ground[dead or unconscious])
[[UNITREF.DAT|UnitRef]][0x78] 0.0.0.0.0.0.1.0 (bit 1 == 0 Unit Alive)
Yoko Fujimoto: On Craft (Health > 0)
UnitPos[0x0A] 1.1.0.0.0.0.0.0 (bit 2 == 1 Unit Standing [Active])
UnitRef[0x78] 0.0.0.1.0.0.0.0 (bit 1 == 0 Unit Alive)

From Bomb Blokes undead army MIA Test save (won by killing aliens).

Spencer Bryant: Lived (Health > 0)
[[UNITPOS.DAT|UnitPos]][0x0A] 0.1.0.0.0.1.0.0 (bit 2 == 1 Unit Standing [Active])
[[UNITREF.DAT|UnitRef]][0x78] 0.1.0.0.0.0.0.1 (bit 1 == 0 Unit Alive)
Oscar Thompson: Bleed to death (Health > 0)
UnitPos[0x0A] 0.0.0.0.0.1.0.0 (bit 2 == 0 Unit on the ground[dead or unconscious])
UnitRef[0x78] 0.1.0.0.0.0.0.1 (bit 1 == 0 Unit Alive)
Virgil Hudson: Killed by Aliens (Health == 0)
UnitPos[0x0A] 0.0.0.0.0.1.0.0 (bit 2 == 0 Unit on the ground[dead or unconscious])
UnitRef[0x78] 1.1.0.0.0.0.0.1 (bit 1 == 1 Unit Dead)

So right now I'm at a loss of how to detect tell the difference between thoes that are left behind and thoes that are dead.

:There must be something odd about my save game that takes 13 live soldiers and makes them all MIA on an abort. I wonder if it is something to do with the one guy who is still on the transport. I'm sure I've never seen an MIA after an AutoCombat victory, or defeat, before. Of course, after a victory, no one should be MIA. In a defeat, in theory AutoCombat could (but doesn't?) allocate some soldiers as MIAs. For the bleeding to death problem, perhaps you could check whether Health <= Fatal Wounds. In the normal game this might be an ambiguous borderline case? Treat it unambiguously - kill any soldiers matching that condition. In XComUtil after-combat messages, perhaps emit the message "So-and-so died from his/her wounds aboard the transport".
:But I guess the problem is not what XComUtil does, but how to "communicate" back to the game engine that the soldiers are alive and well and not MIA? Surely the game's logic must be '''first''' to determine if the battle was aborted, and only then to decide who was left behind on the battlefield vs who died vs who was on the transport and got home? Surely Scott's logic must intercept this abort flag, and ''then un-set it''?.
:By the way, in the listing above I'm not sure whether the least significant bit is at the left or the right? [[User:Spike|Spike]] 20:31, 16 March 2010 (EDT)
:: I'm guessing it's a bitfield not a number, so LSB/MSB doesn't exist. [[User:Cesium|Cesium]] 21:27, 16 March 2010 (EDT)
::: Yes it's a bit field. I linked to the wiki page with the description. The game engine doesn't need to tell why some one got removed from the game. Tatical calculates the score. --[[User:BladeFireLight|BladeFireLight]] 21:38, 16 March 2010 (EDT)

:::: Thanks for clarifying. I had checked the links, read the bits your way, then had doubts as the description seems the other way round, ie Bit 1 at the end. So, do all 13 of my guys have this "on the ground" flag set? Very weird as none were stunned or dead. They were in smoke with minor stun damage is all. And moving the Sgt off the transport gains nothing, I just get 14 MIAs instead of 13. The wacky thing is the screen says Aliens Defeated and gives me loot - even when the transport is lost. [[User:Spike|Spike]] 22:36, 16 March 2010 (EDT)
:: Ok I have a solution I'm working on. Turns out those that bleed to death are being counted by Autocombat as being in play. Autocombat is not instantaneous, so Everyone with health <= wounds get health = 0 then all units with Health != 0 are marked as not dead.
::: Good to have a solution to the bleeding to death issue. Does that shed any light on how 14 non-wounded, non-bleeding, healthy, XCom controlled soldiers suddenly turn MIA at the end of a mission that is an XCom victory? Or is that a different issue?
::: By the way I checked my savegame, and if I move all the soldiers back to the transport prior to Abort Mission / AutoCombat, there are no MIAs any more after AutoCombat. So it sounds again like the situation is being handled like part victory (all aliens are dead, UFO Navigation loot) and part Abort. [[User:Spike|Spike]] 19:46, 17 March 2010 (EDT)
:::: They are both related.
::::* When you bleed to death your health never reaches 0. you are left alive with ~1-5 hit points, but marked as on the ground and tactical ups the KIA Score.
::::* When you are not in the craft on abort. Tactical marks you as on the ground and increases the MIA score.
::::* Geoscape looks at: If Health = 0, or if unit on the gorund (dead, unconscious, left behind) the units is removed from the game.
:::: To fix this I could not just mark everyone on the ground as standing (active) or the ones that already bleed to death are raised from the dead. So I check if Fatal wounds >= Health and then kill the unit by marking health to 0. then I can take the remainder of those that are not on the craft and mark them as active so Geoscape keeps them. I get the added bonus of not having bleed to death units calculated in autocombat as a + to X-Com's score, and autocombat would take at least one round so units one turn from death would die anyway. This is done as part of autocombat and not the standard MIA function that runs on every combat, as I dont want to kill off units that are truly alive. Yes they would probably die on the trip home. but I assume that the skyranger has a non man-portable trauma kit. --[[User:BladeFireLight|BladeFireLight]] 03:21, 18 March 2010 (EDT)

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

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

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

=== Categorise Config Options ===

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

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

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

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

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

* Dart Gun

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=== Focused Research Help ===

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

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

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

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

== Features for 9.8+ - New features ==

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

=== Improved Base Comes At Cost ===

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

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

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

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

=== AutoCombat ===

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

==== AutoWithdrawal ====

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

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

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

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

=== Tougher UFOs ===

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

=== Rebalanced Craft Weapons ===

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

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

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

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

==== Fusion Ball Launcher ====

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

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

==== Cost Based Approach ====

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

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

See [[User:Spike#Cost_Based_Rebalancing]]

==== Stat Based Approach ====

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

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

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

See [[User:Spike#Stat_Based_Rebalancing]]

=== Rebalanced Infantry Weapons ===

See [[User:Spike#Balancing_Infantry_Weapons]]

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

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

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

==See Also==

[[Wish List]]

= Completed Wish List Items =

=== BFG Default To Unchanged ===

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

= MISC =

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

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

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

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

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

The Mysteries of X-COM

2010-03-22T21:37:21Z

BladeFireLight: /* How deep were X-COM bases located on the seas? */

Discussion page for some less clear aspects of the series

==General issues==

==='''How fast can alien craft travel in space?'''===

Some alien missions (repeated attacks on X-COM bases, for instance) come daily. This seems to imply that alien craft are able to travel the distance from Mars to Earth in a matter of hours.

: Or maybe, as you suggest in your novels, they have a staging area near Earth, such as the dark side of the Moon. [[User:Spike|Spike]] 15:36, 25 February 2009 (CST)

::Really fast. Consider that they don't need to push aside atmosphere, as well as the fact that momentum is conserved in space, so they can achieve very high speeds with gravity slingshots. (Mars DOES have 2 moons, recall.) Also note that they may be operating a bit closer to home(the far side of the moon, perhaps?) it's simply that the command staff are at Cydonia. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

Good article in last month's Scientific American pointing out we only rely on gravity slingshots because we still use chemical rockets with pathetic delta-V. Once 2nd and 3rd generation plasma engines come on line (1st gen are in flight now) the gravity slingshot will become an irrelevance. No doubt UFO drives are at least as good as our (future) 3rd gen plasma drives, probably way better since they warp space.

(Reminds me of the old Guild Navigator joke - I just warped space from Ix, and boy is my mind tired. Oh well, you had to be there)

[[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

==='''What happens to the crashed UFO craft and its crew?'''===

Downed alien craft disappear after a few days have passed. No explanation is given to this whatsoever, so what really happens to them?

Possible answers:
* The UFO and its occupants are recovered by other humans.
* The Aliens manage to repair the craft and fly back to space. (unlikely, in the event that the power plant blew up and they have no Elerium)
* The Aliens self-destruct the craft and kill themselves in the process, ensuring their remains will not be recovered by humans.
* The UFO Powerplant eventually suffers a meltdown and explodes, eliminating any vestiges of alien presence.
* The Aliens blow up the UFO and disappear into the countryside.
* Most likely answer, IMHO: The local government/ funding nations give X-COM a limited time window to launch any operation, similiar to what you see in covert ops movies: "Complete the mission within 36 hours, or we initiate Carpet Bombing of the area". This is very likely considering that each nation actually has jurisdiction, and X-com is operating each military op with permission and cooperation by local authorities. [[User:Jasonred|Jasonred]] 13:42, 25 February 2009 (CST)
*Similiarly, I assume that nations which have signed a pact with the aliens launch a rescue operation and assist their alien friends. [[User:Jasonred|Jasonred]] 13:42, 25 February 2009 (CST)
: In the UFO TV show, it's stated that alien craft and bodies degrade quickly in Earth's atmosphere, disappearing completely in hours or a few days. [[User:Spike|Spike]] 15:36, 25 February 2009 (CST)
:: If that was the case, then one of the gases present in the atmosphere would be very toxic to the aliens. They would be restricted on their activities outside their craft, not to mention they would have to terraform the planet to be able to live here. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)

:: As Zombie said, doesn't Alien Containment support this idea? [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

::Those are excellent suggestions. One of the X-COM books detailed that aliens throw up a force field around crashed UFOs to give them time to repair the craft. This would also explain the limited size of the Battlescape (the area of the force field...the field was thrown up before the crash, thus why the craft wasn't always centered in it) as well as why the Battlescape is devoid of human life(the aliens took care of that up front.) Similarly, large scale bombing works as well, as does the local government going in to clean it up themselves. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)
:::If there's a force field around the craft what is it supposed to repel? The atmosphere? Because humans have no problem entering the field and operating inside it. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)
::::Of course they do! Have you ever noticed how dumb your units can be? That's because the aliens can't live with too much nitrogen, so they turn some of it in their force field to oxygen, and excessive amounts of oxygen make you act weird. After a while, their power source runs out and the nitrogen returns, dissolving them into E-115. (What did you think it was made of?) AT least, that's what seemes logical to me, ad is a combination of many postulates here. 21:36, 18 March 2010 (EDT)
:::::That would require that the aliens' biochemistry and the alien alloys used in the power sources reacted with nitrogen, which is a mostly inert gas on normal temperature and pressure and a . It's kinda of weird that the aliens didn't bothered with fixing that vulnerability with their craft and bodies during millions of years (what happens if the force field malfunctions while capturing cattle? ooops!) but ok. The increase in the amount of oxygen would probably also turn any kind of fire into large explosions throughtout the force field. [[User:Hobbes|Hobbes]] 21:24, 19 March 2010 (EDT)
::The force field was intended to keep humans out so the aliens were undisturbed. The first major hurdle X-COM had was figuring out a way to bypass those fields so they COULD get troops and aircraft inside. [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:54, 26 February 2009 (CST)

===How do the aliens carry their equipment?===
Like human soldiers, aliens can carry weapons and equipment in locations like legs, belt, shoulders and backpack, regardless of the fact that some of their races even lack those anatomical features.

:Potentially a sticky gel-like area on the limb. Though really, since we were never intended to access alien inventories and the AI does all inventory management internally, this may simply be something that was never considered. Speaking from a slightly different standard, most aliens do not carry excessive amounts of gear; often their equipment would be able to fit in both hands. Also recall that Floaters and Ethereals have capes and robes(which may have inside pockets, or the Floaters could store them in the anti-grav/life support unit or inside surgically created body cavities during the installation, while Ethereals could support their excess gear with telekinesis), Mutons have armor(which may have external straps or adhesive areas), and Snakemen have an armor plate(which could have straps, adhesive, inside pockets, or even a backpack.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

:We already know the answer to this one - they cheat! ;) [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

===Are X-COM transport craft piloted?===

:Almost certainly, since a remotely-piloted craft could be returned to base when the mission was aborted or failed. It's entirely possible that all X-COM soldiers are qualified pilots of the appropriate craft, since it would make no sense for X-COM to waste space on the plane for a noncombatant, or to have a single-point of failure on the mission like that. (The aliens could screw over the entire op by killing the pilot). It also explains why the craft is lost when the mission fails or is aborted with no one inside(lacking a pilot, the aliens are able to easily destroy it.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

:: On the other hand, even a tank/hovertank is capable of getting the craft back to base. Perhaps there is an autopilot function. X-com craft are also infamous for choosing strange and bizarre intercept paths, based on latitude lines... almost as if they followed some a few simple lines of code from 1993 programming (bit of 4th wall breakage there...) -[[User:Jasonred|Jasonred]]

:Of course, given the tanks seem to be remotely piloted from an X-COM base, its possible that the tank being in the craft allows the Tank pilot to reroute into the control systems for the dropship and take it over. Limiting this to having the tank inside is a rather good idea. [[User:Arrow Quivershaft|Arrow Quivershaft]] 12:07, 27 February 2009 (CST)

:I recall that the various cutscenes in the PSX version had a pilot, most notably in the "Mission Failure" scene, where it shows the pilot being killed. --[[User:Mabmoro|Mabmoro]] 16:06, 13 March 2009 (EDT)

===What sort of physical process is used to increase human stats over time?===

The increases in some stats are easy explained by experience gained on missions (firing abiility, reactions, etc.). However, in the cases of physical stats (TUs, stamina, strength) the increase must be augmented by an artificial process, since it isn't easily explainable that humans can significantly increase body mass/speed/endurance just by physical activity/exercise.

:Lifting weights will increase strength. Running and cardio exercise will increase endurance, and performing the same task multiple times will allow you to perform it faster. I see no reason natural increase doesn't work. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:33, 26 February 2009 (CST)
::I assume that it is possible to a human to use those methods to double its physical condition, but that being the case why are X-COM recruits so... undeveloped? Maybe this is a more intriguing aspect. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)

What I don't get is that when someone gets blasted that they gain a lot of extra health. For crying out loud, the aliens are throwing around plasma and ridicoulously HUGE explosions. Shouldn't they be suffering from third-degree burns? I would expect them to at least have a major sore spot where they got hit. [[User:Tsunamiatunzen1|Tsunamiatunzen1]] September 24

:There's been arguments over whether the soldiers in X-COM are the Green Berets or equivalents of their various militaries, just average soldiers that volunteered for the job, or if the Council of Funding Nations is corrupt and is using this as an excuse to foist off their most useless soldiers onto the X-COM project. If the latter, it would easily explain their rather poor early stats. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)

::Maybe the stat increases relate to the troops getting more comfortable performing all operations - lifting, running, combat actions - when the aliens no longer scare the cr*p out of them so much. [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

:: I know what you mean... if this were Jagged Alliance, it'd be like trying to hire Mike and getting Gumpy instead... ouch! ... IMHO, it looks as if the COFN is being funny about this. Clearly, the troops assigned to X-com have had extensive weapons training... each and every one of them can use just about any standard weapon, including Rocket Launchers, incindieries, auto Cannons, etc. However, NONE of them have any combat experience, coming to you as fresh rookies. And their stats look as if they were selected based on a pot luck basis rather than screening among the elite troops... [[User:Jasonred]]

:Health isn't gained from getting shot. But as for the "ludicrously low stats" issue, maybe they're being selected on some other basis, or there's a real shortage of volunteers. [[User:Magic9mushroom|Magic9mushroom]] 04:56, 25 September 2009 (EDT)

==Enemy Unknown/UFO Defence issues==
==='''Why isn't Earth overrun by Snakeman/Chryssalids?'''===

According to the UFOPaedia, Snakemen's "Reproduction is asexual, with each snakeman carrying up to fifty eggs inside its body at any one time" adding the ominious conclusion: "Left to its own devices this species would be a severe threat to life on earth."
Moreover, this species is usually accompanied by the Chryssalids, which have a capacity to reproduce themselves very quickly using humans. So, any survivors of crash sites or terror attacks could start reproducing themselves hidden, resulting in large areas being overrun by those aliens later on.

Possible answers:
* Both races have a self-destruct mechanism incorporated into their psysiology to prevent this.
* The entire area is purged by large scale bombing. [[User:Jasonred|Jasonred]] 13:42, 25 February 2009 (CST)

::One thing suggested in fan data was that Snakemen have air tablets in their stomach...which may be different from earth's atmosphere, which would limit their lifespan in earth's atmosphere, also making egg-laying pointless, since the offspring wouldn't be able to breathe or survive. It has also been suggested that Chryssalids have a very rapid metabolism. Though Chryssalids are likely just as, if not more useful, as a threat or a bargaining tool. When attempting to get a nation to capitulate to their demands, the aliens could threaten to employ Chryssalids en masse, or offer to remove a mass infestation in exchange for the government's cooperation. Or even further, it's possible that Chryssalids are under Ethereal control and maintaining the control link at that distance is taxing, thus eliminating mass use of the creatures. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

Two words: [[Alien Containment]]. That answers everything except for the UFOPaedia articles for the aliens themselves which contradict it. --[[User:Zombie|Zombie]] 00:42, 26 February 2009 (CST)
: For captured aliens, yes. But what survivors of uninvestigated crash sites? [[User:Hobbes|Hobbes]]

::Zombie is commenting that based on the need for an Alien Containment unit, the aliens cannot survive in earth's atmosphere for extended periods, needing special atmospheric blends and/or nutrient pools which earth is unable to provide naturally, thus limiting their operations outside of the craft. (If the aliens won the war, it's likely this would be one of the first things that they would 'correct'.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:54, 26 February 2009 (CST)

===What is the propose of the 'disco balls' found inside some UFOs?===

:Given that they explode, they could be storage reservoirs for coolant for the computers or other systems. They could also be circuit breakers or electrical junction boxes, or even a component of the UFO's particle beam they use to fry X-COM Interception craft. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

Here again, two words: [[Alien Entertainment]]. Even though the spheres are not set to Alien Entertainment in the MCD files, they are almost certainly related to the process somehow. --[[User:Zombie|Zombie]] 00:42, 26 February 2009 (CST)

:Maybe they are for having discos? [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

:Presumably [[Alien Entertainment]] is psionic in some way, maybe they're Psi-Emitters or something? -[[User:magic9mushroom|magic9mushroom]]

===Who buys those alien bodies/equipment from X-COM?===

:Equipment likely goes to the funding nations or the international black market. No rebel group is going to ask too many questions about being offered guns that can [[Heavy Plasma|slice through the hull of an MBT]] or [[Alien Grenade|grenades that can level a building]] or [[Blaster Launcher|man-portable guided missiles]]; it'd just be cash-and-carry. Similarly, scientists would likely be interested in looking at much of this stuff for their own research. This would also explain the lack of market forces; the funding nations could have a set price for each item, or if X-COM is selling them under the table to rebels and rogue scientists, they can set the price and refuse to budge. The money on corpses could also be an "Alien Bounty" paid by the Funding Nations, as a reward for each alien that X-COM can prove they killed. Or it could be bought by other groups...rumor has it that some fast food restaurants have processes that can make ANY meat, no matter the source, look and taste the same, and a Muton would make a LOT of McBurgers. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)
From the USO (Kasey Chang): XARQUID SUSHI.

===How did the aliens got to Mars?===

There are no indications that UFOs are capable of faster than light speed. So how did they get to Mars in the first place?

:The UFOs are mission craft, used for the legwork. The fighters; we never see the carriers. Given the aliens have been proven to be interstellar, they either Clone-A-Crew as needed when coming the long way to keep the UFOs crewed, or its far more likely that the aliens did have or still do have larger "Carrier" ships, which are capable of FTL travel, that were/are further out in the Solar System that store and dispatch UFOs to mission locations. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:33, 26 February 2009 (CST)

:: One word: TFTD. The entire city of T'leth was put into cryogenic suspended animation? Or look at X-com Interceptor. X-com and the aliens show the ability to enter hyperspace or whatever it is.
::: T'Leth is another mystery of its own. More to that later on :) [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)
::... there are no indications that the UFOs are INcapable of FTL... I don't think you would want to perform FTL travel within Earth's planetary atmosphere!
::: There are no indications that they are capable as well. And X-COM scientists don't seem to detect any FTL capabilities in UFOs during their research. And after the war the Elerium stocks dwindled, and it would make sense to perform some sort of interstellar missions to detect and harvest Elerium, however none are mentioned. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)
:::: Unless you count the events of X-com Interceptor? [[User:Jasonred]] [[User:Jasonred|Jasonred]] 21:15, 26 February 2009 (CST)
::::: I am refering to the events between Enemy Unknown and TFTD. There is clearly a big distinction between the alien craft on EU and those of Interceptor. [[User:Hobbes|Hobbes]] 09:38, 27 February 2009 (CST)
::::: Enemy Unknown is set in 1999, TFTD in 2040, Interceptor in 2067... looks entirely plausible that they DID begin research into space exploration immediately after the events of Enemy Unknown. These things take time you know. Remember that the universe is a huge place, and Earth had rather limited Elerium Reserves by the end of EU. It takes... what, 30 Elerium just to fly an Avenger halfway across Earth? They could hardly afford to fly around randomly in space HOPING to come across elerium, they had to figure out detections methods, then scan the galaxy sector by sector, possibly partially using non-Elerium based propulsion at times... I can't remember if it's canon or fanfic, but I remember reading that all Elerium on Earth was reserved for space exploration.
As for FTL, Earth does get it for sure sometime between 1999 and 2067. And I'm pretty certain the technology is Elerium based. It's not a huge logic jump to assume that the aliens have access to FTL Elerium based tech.
Though I'm a bit puzzled why all T'leth technology is based on Zrbrite, when the aliens uniformly use Elerium, all the way from Earth to Cydonia to the far reaches of space. -[[User:Jasonred|Jasonred]]

:It takes 12 Elerium to fuel an Avenger, though how much 1 Elerium is is an ongoing debate. As for Elerium, it was reserved for propulsion research when the funding nations divvied up X-COM's resources, and then they blew it all without learning anything more than the original X-COM scientists. And yes, Earth clearly gets FTL after TFTD but before Interceptor. The reason Elerium is not used in TFTD is because Elerium becomes inert and useless upon contact with seawater. Similarly, seawater aggressively corrodes Alien Alloys and eventually completely dissolves them. Zrbite functions similar to Elerium, being gold mixed with alien bio-material. Unfortunately, Zrbite only works when supported by a massive energy grid created by T'leth and becomes inert upon its destruction. [[User:Arrow Quivershaft|Arrow Quivershaft]] 12:07, 27 February 2009 (CST)

OK... take the UNIT of elerium out of the equation... let's say that Earth had 5000 units of elerium, so 6 units get's an Avenger halfway around the world, and 12 units is sufficient to reach Mars. Hardly enough fuel reserves for intergalactic travel then.
2065 On October the 27th, the probe 'Tombstone 1' returns reports to Earth. It's data show that the globular star cluster where it rests, one hundred light-years from Earth, contains many life-supporting planets. Many of the planet's within the probe's scanning range also apparently possess great mineral wealth, including trace veins of elerium-115.
Hmm... So, mankind discovers FTL technology on their own in those 65 years? ah... come to think of it, if they've got non-Elerium based space travel and FTL, and more powerful weapons too, what's the big deal about Elerium in the Frontier? Does mankind even need it anymore?
As for T'leth, it is meant to be over 65 million years old, and CRASHLANDED on Earth due to a solar flare. Was the Ultimate Alien a prophet, thus chose to base T'leth on aqua plastics and Zrbite when T'lth was first constructed? Or did T'leth crash land, followed by frenzied activity where the entire city was replaced part by part, the alien alloys swapped for Aqua Plastics?
...
Actually, come to think of it, it's obviously a massive plothole due to limited timeframe, no point in discussing too deeply. Sigh... [[User:Jasonred|Jasonred]] 13:50, 27 February 2009 (CST)

:It's implied that despite the loss of ability to use the alien technology from the First and Second alien wars, simply being able to see and examine their designs catapulted earth's technology forward at least a few decades...which really is entirely reasonable. Much of the technology can be replicated on earth, and the principles and designs can be reapplied.

:As for the deal with Elerium, its needed to power stronger weapons and is also wonderful for power generation; its efficiency in power generation is what allows Mega Primus to even exist.

:And was there anywhere that specifically said that T'Leth was made of Aqua Plastics? I don't recall. Yes, the rest of their subs are made of aqua plastics, but I'm wondering if something the size of a medium city might perhaps be made of something a bit more durable. PS: Thanks for signing your post! :D [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:17, 27 February 2009 (CST)

It's not a plothole at all. There is no Elerium on Earth, whereas the aliens can manufacture Zrbite on Earth, since there's gold here. Therefore it's obvious why they used Zrbite. Also, there's the fact that it was an Aquatoid colony mission, intended to produce an "aquatic paradise", so using Aqua Plastics instead of Alien Alloys is perfectly justified. [[User:magic9mushroom]]

... I think Alien Alloys alone would catapult earth's technology forward a decade, and there's no reason humanity can't use those anymore, just not in water. According to timeline, some space pirates manage to make the decommisioned Avengers run on non-Elerium fuel... a large technological step.
By the time of Interceptor, Elerium weapons aren't that powerful. Good point about power generation though.
I would assume that T'leth SHOULD have been constructed out of Alien Alloys, since it was originially an interplanetary vessel? Generally, everything in EU was made of Alien Alloys, everything in TFTD was made out of Aqua plastics. Both of which seemed plenty durable.

::Have you noticed that the UFOs fly however their mission parameters tell them to? The UFOs pretty much IGNORE interceptions by X-com craft... if their mission tells them to make 3 passes, speed up, slow down, speed up... they will follow that pattern exactly, whether X-com craft are firing on them or not.

::Question: How long does it take the Avenger to reach Mars from Earth? [[User:Jasonred]] [[User:Jasonred|Jasonred]] 19:12, 26 February 2009 (CST)
:::No longer than a week, in my opinion. Probably less than 2 days. Since canonically, the design of the Avenger had the Cydonia mission in mind, it would be capable of very high interplanetary speeds. (You could choose to burn 40% of the Elerium in one blast to get to high speed. Or you could burn even more and refuel while it's landed...or it could be a mission with no guaranteed escape for the crew. The lives of the many over those of the few and all that, especially since the war hinges on the mission.) In addition, you can fit a full complement of soldiers on board with no real excess room for supplies, and the longer it takes to get to Mars, the greater the chance the aliens will spot it coming for them and mount a serious defense. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:20, 26 February 2009 (CST)
:::If you'd burn that much fuel to accelerate the craft then you'd have to use as much again to decelerate it and attain a planetary orbit, otherwise you'll simply overshoot the planet and head towards outer space. This is also another aspect to take into account when thinking about the speed of UFOs. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)

::: UFO drives are non-Newtonian so those sort of rocket equations don't necessarily apply. I think filling up a car with gas is a closer analogy. [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

::: Well, they could put a mini mind shield on the Avenger, shoot down a UFO roughly their size, and then fly to Cydonia when the UFO they shot down was supposed to return based on the instructions found by the hyper-wave decoder. Basically taking the place of the UFO. Shouldn't be too hard since the UFO's are pretty common by the time you research Cydonia or Bust. [[User:Tsunamiatunzen1|Tsunamiatunzen1]] 14 February 2010 (MST)

::That would leave 20% of the fuel to take off the Avenger and land it. Not really that unreasonable. While they're landed, they could potentially refuel the Avenger, or the mission might have been planned as a 1-way trip from the get-go. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)

===What happened to Mars and the alien civilization there?===

According to the Brain, Mars was blooming with life had a alien civilization millions of years ago. However, Mars nowadays is a barren world and the alien civilization seems reduced to the area on Cydonia.

:That may well have been before Mars lost the majority of its atmosphere due to its weak magnetic field. As the atmosphere dissipated, the aliens left or died off. It's also possible that the aliens, shown in the game over to have little respect for planets other than as sites for slaves and resources, they strip-mined the planet dry(and the rust from the machines created the red coloring), and then seeded Earth so that the slave workforce would grow for future extraction of Earth's resources. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:33, 26 February 2009 (CST)

===Where are the human-alien hybrids referred to on the UFOPaedia?===

:For the ones on earth, probably in hiding or in laboratories for research. For the ones the aliens have, potentially improving the Sectoid gene pool or being used as food or menial tasks. Cloning is alot easier than making genetic hybrids and there's nothing that says their first-generation experiments would be suitable for combat. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:33, 26 February 2009 (CST)

:: They are babies at the time of X-com, and few in number. Their aren't even that many of them by the time of X-com Apocalypse. [[User:Jasonred]] [[User:Jasonred|Jasonred]] 19:12, 26 February 2009 (CST)

:Not to mention the ones in X-COM: Apocalypse are less-than-fit for battle before extensive training. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)

===Why did the aliens only activate T'Leth after they were defeated?===

On TFTD T'Leth is shown as an entity/city of major power that is capable of conducting a war on its own. But the aliens leave it dormant although they could have used it to speed the process of taking control of Earth.

:Perhaps the Enemy Unknown aliens are legitimately scared of the TFTD aliens and are unsure how long they could trust them. Evil is not monolithic; the TFTD aliens may be more interested in themselves than the alien empire, so they were kept as an ace-in-the-hole. This is the same reason (canonically) that SKYNET did not originally send the T-1000 to assassinate Sarah Connor; SKYNET was scared of what the T-1000 could do and had only a bare minimum of control over it, so it only used it as an option when it had nothing left to lose. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)

T'Leth is in fact so powerful that all it has to do is surface, in order for X-com to be considered to have lost the war.
In fact, looking at the timelines, it takes 40 years for T'leth to wake up from it's slumber... that's one good reason not to use it. By the time it activated, the war would already be over. [[User:Jasonred]]

Because the whole purpose of the Enemy Unknown aliens was to rescue the TFTD aliens from T'leth, and there was no way of seeing whether the T'leth-based invasion in TFTD would even work - from their perspective it's possible that getting T'leth to bootstrap itself could have caused a catastrophe (they don't know whether or how badly it's damaged). Presumably the aliens planned to mount a proper rescue operation after locking down Earth and readying it for the aquatic paradise that was the entire point of the T'leth expedition in the first place. [[User:magic9mushroom]]

T'Leth was a coleny ship sent by the Sectoid/Aquatoid's millions of years earlier. This is why the Aquatoids use electronics to augment there control over other creatures, while there progeny are genetically modified to gain the same control. In TFTD it's implied that the T'Leth had been partialy active for a long time. Thawing out aliens in small groups but never going in full production. UFO aliens may have not intended to start the full awakening cycle until they had a chance to prepare the planet.
OR, given the Ultimate Alien was aquatoid in origin by his looks and there was no other races from the first game involved. And the fact that Sectoid/Aqutoid's are not the top of the food chain with the Ethereal and Brain being more powerful it's possible the brain had decided that the Ultimate Alien was a threat to it's power. It was not until it's death that they tried send the signal. --[[User:BladeFireLight|BladeFireLight]] 17:19, 22 March 2010 (EDT)

===Why did the aliens use limited force during the First Alien War?===

Imagine Independence Day or War of the Worlds: UFO above the major Earth cities destroying the national leadership and any resistance. Or simply announce to Earth that they are now a part of their empire and resistence is futile. Instead, they go 1 mission each day, allowing humans to capture their craft, research their technology, discover their intentions and mount a successful defense. Don't the aliens watch sci-fi movies to see how it should be done?

:Perhaps they don't have the standing forces to do so, and are in the process of building up the forces needed to do so. Perhaps they don't want to wipe out the entire power structure too fast; they want to leave some pieces in place for when they rebuild. Perhaps they're too condescending to think that humanity ever really has a chance; they've probably conquered thousands of other planets without anyone ever successfully resisting them. Perhaps they consider the X-COM project to be a rearguard action that, while a valiant effort and a credible threat, is ultimately doomed to failure because they simply cannot win in the end, which is why they undermine it. Indeed, the reason you need to launch the Cydonia mission in order to win is because X-COM simply cannot stop the aliens in a ground war; the aliens have an effectively infinite supply line and standing forces(though nothing says they're all waiting to swamp the earth), and the only way to win is to kill the command staff(which the aliens believe X-COM will not be able to do, lacking both knowledge of where the Brain is and any practical means to get there.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)
::The most plausible explanation seems to be the one employed in the Worldwar series, by Harry Turtledove, but that does not seem to mesh with what the Brain says about having been on Mars for a while, since then they could watch the Earthlings perpetually. Of course, what it says is probably a bunch of lies. Thinking about what it says for too long also raises the question of why the aliens attacked when they did, of course... [[User:Vizzydix1|Vizzydix1]] 21:52, 18 March 2010 (EDT)

The aliens are completely lacking in weapons of mass destruction. When you get right down to it, their aircraft are very fast, manuevarable and durable, but they have rotten firepower. Even the battleship is unable to bring down an Interceptor in 1 shot.
The terror missions and X-com Base Defences prove that the Aliens are unable to simply launch orbital bombardments... in fact, they appear to have no Air to Land weapons whatsoever...
When you get right down to it, the aliens are pretty stupid. Also, their scientists seem inferior to Earth's. Seems to me that they only had the advantage of Elerium deposits and thus elerium based research.
X-COM was unable to win in an all-out war with the aliens, but remember that X-com is a small little covert group with several dozen soldiers and a handful of aircraft. Can you imagine the result if the aliens had caused a joint war effort by the UN? You would have Lockheed factories converted to Avenger production, several platoons of soldiers outfitted with Flying Suits, Lasers, Heavy Plasma, thousands upon thousands of Laser Tanks...
I would say that keeping the fight to covert action on both sides was actually beneficial to the aliens, really. [[User:Jasonred]]
* Nope, the aliens could just invoke John's Law and blow up the planet with a kamikaze battleship at .9c. Even failing that, the alien battlefleet could come in numbers sufficent to blot out the sun.--[[User:(name here)|(name here)]] 14:39, 8 November 2009 (EST)

==TFTD issues==
===What was the relationship between the aliens from the 1st and 2nd wars?===

Quoting from the UFOPaedia regarding Alien Origins: 'Deep in the oceans there lie ancient
sites used by the Aliens to contact their stellar cousins.' This also has some implications regarding the issue of why T'Leth was only activated when the Sectoids were defeated.

*Gill Men are coopted Terran creatures, Aquatoids are a differently-modified Sectoid breed, Lobstermen are machine soldiers that are manufactured, Tasoths are clone soldiers that are grown.

Aquatoids are the ancestors of the Sectoied's. The colony ship was sent out slowing than light hundreds of millions of years ago. Sectoids are a more genetically advanced race. The rest of UFO aliens were picked up after that point. The Brain and Ethereals probably conquered the Sectoids and dont regard them highly. While the Aquotoids that were thawd over the years created, conquered (gill man) or Manufactured the rest of the allies over time. I picture the Tasoth as probably something they brought with them and have been working on. Since most of the Aquatoids come from suspended animation they have not tinkered with geans much. Instead modifying and using electronics (MC Chip) to control. --[[User:BladeFireLight|BladeFireLight]] 17:28, 22 March 2010 (EDT)

===What kind of materials were 'synomium' and 'adamantium'?===

The first one is mentioned on the name of the alien communication devices and the second one appears at the end when T'Leth is destroyed: 'he twisting hugeness of T'leth begins to rupture.
Flames and smoke spew from its gleaming spires and adamantium halls.'

:Synomium is probably a special material used in the comm. devices, like Stargate's naquadah (universal stuff), naquadria (unstable power source), trinium (hull material) and neutronium (superdense metal). Adamantium is a legendary material in ancient literature that is said to be indestructible, similarly to mithril.--[[User:Amitakartok|amitakartok]] 10:55, 3 November 2009 (EST)

===How deep were X-COM bases located on the seas?===

*Floating bases would be easier to build, repair and supply. However they would have to be tethered to the ocean bed or possess some sort of propulsion to prevent them from drifing with the ocean currents. But it would also allow for easy redeployment of the base.
*Submersible bases could allow for better sonar detection. Same problems regarding ocean currents would apply. In case of hull breaches entire modules would be quickly flooded and any crew present would be crushed by water pressure or drown. Base could be built and then submerged (requires depth control)
*Seabed bases would be the hardest to build and supply. Several other factors could limit their deployment, such as instable areas (underwater volcanos, prone to seaquakes, rock avalanches, etc.) and depths.
*Given that the Alien Retaliation missions in TFTD are called "Floating Base Attack", I'd say floating. Also remember that your starting sonar can't see Very Deep, which rules out seabed bases. [[User:magic9mushroom]]
** Floating doesn't always happen on the surface. The surface has to deal with large waves ad bobbing up and down, submerged only has the currents it could be stabilized easier. --[[User:BladeFireLight|BladeFireLight]] 11:57, 14 January 2010 (EST)
* I was recently researching how far you have to be down to not be effected by surface conditions. You have to be submerged 1/2 of a waves lenght (measured crest to crest) Best I can find is that the average wave is 150 yards accross. To not be effected by the waves you have to be 75 Yards below. This is way below the depth needed to not be effected by the bends when surfaceing. I figure they are probably right at the limit of what can be safe for quick surfacing and well anchored to avoid getting [http://www.youtube.com/watch?v=LwKXfc_a4Ag tossed in a storm]. --[[User:BladeFireLight|BladeFireLight]] 17:37, 22 March 2010 (EDT)
[[Category: Fiction]]

The Mysteries of X-COM

2010-03-22T21:28:15Z

BladeFireLight: /* What was the relationship between the aliens from the 1st and 2nd wars? */

The Mysteries of X-COM

2010-03-22T21:20:40Z

BladeFireLight: /* Why did the aliens only activate T'Leth after they were defeated? */

Discussion page for some less clear aspects of the series

==General issues==

==='''How fast can alien craft travel in space?'''===

Some alien missions (repeated attacks on X-COM bases, for instance) come daily. This seems to imply that alien craft are able to travel the distance from Mars to Earth in a matter of hours.

: Or maybe, as you suggest in your novels, they have a staging area near Earth, such as the dark side of the Moon. [[User:Spike|Spike]] 15:36, 25 February 2009 (CST)

::Really fast. Consider that they don't need to push aside atmosphere, as well as the fact that momentum is conserved in space, so they can achieve very high speeds with gravity slingshots. (Mars DOES have 2 moons, recall.) Also note that they may be operating a bit closer to home(the far side of the moon, perhaps?) it's simply that the command staff are at Cydonia. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

Good article in last month's Scientific American pointing out we only rely on gravity slingshots because we still use chemical rockets with pathetic delta-V. Once 2nd and 3rd generation plasma engines come on line (1st gen are in flight now) the gravity slingshot will become an irrelevance. No doubt UFO drives are at least as good as our (future) 3rd gen plasma drives, probably way better since they warp space.

(Reminds me of the old Guild Navigator joke - I just warped space from Ix, and boy is my mind tired. Oh well, you had to be there)

[[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

==='''What happens to the crashed UFO craft and its crew?'''===

Downed alien craft disappear after a few days have passed. No explanation is given to this whatsoever, so what really happens to them?

Possible answers:
* The UFO and its occupants are recovered by other humans.
* The Aliens manage to repair the craft and fly back to space. (unlikely, in the event that the power plant blew up and they have no Elerium)
* The Aliens self-destruct the craft and kill themselves in the process, ensuring their remains will not be recovered by humans.
* The UFO Powerplant eventually suffers a meltdown and explodes, eliminating any vestiges of alien presence.
* The Aliens blow up the UFO and disappear into the countryside.
* Most likely answer, IMHO: The local government/ funding nations give X-COM a limited time window to launch any operation, similiar to what you see in covert ops movies: "Complete the mission within 36 hours, or we initiate Carpet Bombing of the area". This is very likely considering that each nation actually has jurisdiction, and X-com is operating each military op with permission and cooperation by local authorities. [[User:Jasonred|Jasonred]] 13:42, 25 February 2009 (CST)
*Similiarly, I assume that nations which have signed a pact with the aliens launch a rescue operation and assist their alien friends. [[User:Jasonred|Jasonred]] 13:42, 25 February 2009 (CST)
: In the UFO TV show, it's stated that alien craft and bodies degrade quickly in Earth's atmosphere, disappearing completely in hours or a few days. [[User:Spike|Spike]] 15:36, 25 February 2009 (CST)
:: If that was the case, then one of the gases present in the atmosphere would be very toxic to the aliens. They would be restricted on their activities outside their craft, not to mention they would have to terraform the planet to be able to live here. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)

:: As Zombie said, doesn't Alien Containment support this idea? [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

::Those are excellent suggestions. One of the X-COM books detailed that aliens throw up a force field around crashed UFOs to give them time to repair the craft. This would also explain the limited size of the Battlescape (the area of the force field...the field was thrown up before the crash, thus why the craft wasn't always centered in it) as well as why the Battlescape is devoid of human life(the aliens took care of that up front.) Similarly, large scale bombing works as well, as does the local government going in to clean it up themselves. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)
:::If there's a force field around the craft what is it supposed to repel? The atmosphere? Because humans have no problem entering the field and operating inside it. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)
::::Of course they do! Have you ever noticed how dumb your units can be? That's because the aliens can't live with too much nitrogen, so they turn some of it in their force field to oxygen, and excessive amounts of oxygen make you act weird. After a while, their power source runs out and the nitrogen returns, dissolving them into E-115. (What did you think it was made of?) AT least, that's what seemes logical to me, ad is a combination of many postulates here. 21:36, 18 March 2010 (EDT)
:::::That would require that the aliens' biochemistry and the alien alloys used in the power sources reacted with nitrogen, which is a mostly inert gas on normal temperature and pressure and a . It's kinda of weird that the aliens didn't bothered with fixing that vulnerability with their craft and bodies during millions of years (what happens if the force field malfunctions while capturing cattle? ooops!) but ok. The increase in the amount of oxygen would probably also turn any kind of fire into large explosions throughtout the force field. [[User:Hobbes|Hobbes]] 21:24, 19 March 2010 (EDT)
::The force field was intended to keep humans out so the aliens were undisturbed. The first major hurdle X-COM had was figuring out a way to bypass those fields so they COULD get troops and aircraft inside. [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:54, 26 February 2009 (CST)

===How do the aliens carry their equipment?===
Like human soldiers, aliens can carry weapons and equipment in locations like legs, belt, shoulders and backpack, regardless of the fact that some of their races even lack those anatomical features.

:Potentially a sticky gel-like area on the limb. Though really, since we were never intended to access alien inventories and the AI does all inventory management internally, this may simply be something that was never considered. Speaking from a slightly different standard, most aliens do not carry excessive amounts of gear; often their equipment would be able to fit in both hands. Also recall that Floaters and Ethereals have capes and robes(which may have inside pockets, or the Floaters could store them in the anti-grav/life support unit or inside surgically created body cavities during the installation, while Ethereals could support their excess gear with telekinesis), Mutons have armor(which may have external straps or adhesive areas), and Snakemen have an armor plate(which could have straps, adhesive, inside pockets, or even a backpack.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

:We already know the answer to this one - they cheat! ;) [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

===Are X-COM transport craft piloted?===

:Almost certainly, since a remotely-piloted craft could be returned to base when the mission was aborted or failed. It's entirely possible that all X-COM soldiers are qualified pilots of the appropriate craft, since it would make no sense for X-COM to waste space on the plane for a noncombatant, or to have a single-point of failure on the mission like that. (The aliens could screw over the entire op by killing the pilot). It also explains why the craft is lost when the mission fails or is aborted with no one inside(lacking a pilot, the aliens are able to easily destroy it.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

:: On the other hand, even a tank/hovertank is capable of getting the craft back to base. Perhaps there is an autopilot function. X-com craft are also infamous for choosing strange and bizarre intercept paths, based on latitude lines... almost as if they followed some a few simple lines of code from 1993 programming (bit of 4th wall breakage there...) -[[User:Jasonred|Jasonred]]

:Of course, given the tanks seem to be remotely piloted from an X-COM base, its possible that the tank being in the craft allows the Tank pilot to reroute into the control systems for the dropship and take it over. Limiting this to having the tank inside is a rather good idea. [[User:Arrow Quivershaft|Arrow Quivershaft]] 12:07, 27 February 2009 (CST)

:I recall that the various cutscenes in the PSX version had a pilot, most notably in the "Mission Failure" scene, where it shows the pilot being killed. --[[User:Mabmoro|Mabmoro]] 16:06, 13 March 2009 (EDT)

===What sort of physical process is used to increase human stats over time?===

The increases in some stats are easy explained by experience gained on missions (firing abiility, reactions, etc.). However, in the cases of physical stats (TUs, stamina, strength) the increase must be augmented by an artificial process, since it isn't easily explainable that humans can significantly increase body mass/speed/endurance just by physical activity/exercise.

:Lifting weights will increase strength. Running and cardio exercise will increase endurance, and performing the same task multiple times will allow you to perform it faster. I see no reason natural increase doesn't work. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:33, 26 February 2009 (CST)
::I assume that it is possible to a human to use those methods to double its physical condition, but that being the case why are X-COM recruits so... undeveloped? Maybe this is a more intriguing aspect. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)

What I don't get is that when someone gets blasted that they gain a lot of extra health. For crying out loud, the aliens are throwing around plasma and ridicoulously HUGE explosions. Shouldn't they be suffering from third-degree burns? I would expect them to at least have a major sore spot where they got hit. [[User:Tsunamiatunzen1|Tsunamiatunzen1]] September 24

:There's been arguments over whether the soldiers in X-COM are the Green Berets or equivalents of their various militaries, just average soldiers that volunteered for the job, or if the Council of Funding Nations is corrupt and is using this as an excuse to foist off their most useless soldiers onto the X-COM project. If the latter, it would easily explain their rather poor early stats. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)

::Maybe the stat increases relate to the troops getting more comfortable performing all operations - lifting, running, combat actions - when the aliens no longer scare the cr*p out of them so much. [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

:: I know what you mean... if this were Jagged Alliance, it'd be like trying to hire Mike and getting Gumpy instead... ouch! ... IMHO, it looks as if the COFN is being funny about this. Clearly, the troops assigned to X-com have had extensive weapons training... each and every one of them can use just about any standard weapon, including Rocket Launchers, incindieries, auto Cannons, etc. However, NONE of them have any combat experience, coming to you as fresh rookies. And their stats look as if they were selected based on a pot luck basis rather than screening among the elite troops... [[User:Jasonred]]

:Health isn't gained from getting shot. But as for the "ludicrously low stats" issue, maybe they're being selected on some other basis, or there's a real shortage of volunteers. [[User:Magic9mushroom|Magic9mushroom]] 04:56, 25 September 2009 (EDT)

==Enemy Unknown/UFO Defence issues==
==='''Why isn't Earth overrun by Snakeman/Chryssalids?'''===

According to the UFOPaedia, Snakemen's "Reproduction is asexual, with each snakeman carrying up to fifty eggs inside its body at any one time" adding the ominious conclusion: "Left to its own devices this species would be a severe threat to life on earth."
Moreover, this species is usually accompanied by the Chryssalids, which have a capacity to reproduce themselves very quickly using humans. So, any survivors of crash sites or terror attacks could start reproducing themselves hidden, resulting in large areas being overrun by those aliens later on.

Possible answers:
* Both races have a self-destruct mechanism incorporated into their psysiology to prevent this.
* The entire area is purged by large scale bombing. [[User:Jasonred|Jasonred]] 13:42, 25 February 2009 (CST)

::One thing suggested in fan data was that Snakemen have air tablets in their stomach...which may be different from earth's atmosphere, which would limit their lifespan in earth's atmosphere, also making egg-laying pointless, since the offspring wouldn't be able to breathe or survive. It has also been suggested that Chryssalids have a very rapid metabolism. Though Chryssalids are likely just as, if not more useful, as a threat or a bargaining tool. When attempting to get a nation to capitulate to their demands, the aliens could threaten to employ Chryssalids en masse, or offer to remove a mass infestation in exchange for the government's cooperation. Or even further, it's possible that Chryssalids are under Ethereal control and maintaining the control link at that distance is taxing, thus eliminating mass use of the creatures. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

Two words: [[Alien Containment]]. That answers everything except for the UFOPaedia articles for the aliens themselves which contradict it. --[[User:Zombie|Zombie]] 00:42, 26 February 2009 (CST)
: For captured aliens, yes. But what survivors of uninvestigated crash sites? [[User:Hobbes|Hobbes]]

::Zombie is commenting that based on the need for an Alien Containment unit, the aliens cannot survive in earth's atmosphere for extended periods, needing special atmospheric blends and/or nutrient pools which earth is unable to provide naturally, thus limiting their operations outside of the craft. (If the aliens won the war, it's likely this would be one of the first things that they would 'correct'.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:54, 26 February 2009 (CST)

===What is the propose of the 'disco balls' found inside some UFOs?===

:Given that they explode, they could be storage reservoirs for coolant for the computers or other systems. They could also be circuit breakers or electrical junction boxes, or even a component of the UFO's particle beam they use to fry X-COM Interception craft. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

Here again, two words: [[Alien Entertainment]]. Even though the spheres are not set to Alien Entertainment in the MCD files, they are almost certainly related to the process somehow. --[[User:Zombie|Zombie]] 00:42, 26 February 2009 (CST)

:Maybe they are for having discos? [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

:Presumably [[Alien Entertainment]] is psionic in some way, maybe they're Psi-Emitters or something? -[[User:magic9mushroom|magic9mushroom]]

===Who buys those alien bodies/equipment from X-COM?===

:Equipment likely goes to the funding nations or the international black market. No rebel group is going to ask too many questions about being offered guns that can [[Heavy Plasma|slice through the hull of an MBT]] or [[Alien Grenade|grenades that can level a building]] or [[Blaster Launcher|man-portable guided missiles]]; it'd just be cash-and-carry. Similarly, scientists would likely be interested in looking at much of this stuff for their own research. This would also explain the lack of market forces; the funding nations could have a set price for each item, or if X-COM is selling them under the table to rebels and rogue scientists, they can set the price and refuse to budge. The money on corpses could also be an "Alien Bounty" paid by the Funding Nations, as a reward for each alien that X-COM can prove they killed. Or it could be bought by other groups...rumor has it that some fast food restaurants have processes that can make ANY meat, no matter the source, look and taste the same, and a Muton would make a LOT of McBurgers. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)
From the USO (Kasey Chang): XARQUID SUSHI.

===How did the aliens got to Mars?===

There are no indications that UFOs are capable of faster than light speed. So how did they get to Mars in the first place?

:The UFOs are mission craft, used for the legwork. The fighters; we never see the carriers. Given the aliens have been proven to be interstellar, they either Clone-A-Crew as needed when coming the long way to keep the UFOs crewed, or its far more likely that the aliens did have or still do have larger "Carrier" ships, which are capable of FTL travel, that were/are further out in the Solar System that store and dispatch UFOs to mission locations. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:33, 26 February 2009 (CST)

:: One word: TFTD. The entire city of T'leth was put into cryogenic suspended animation? Or look at X-com Interceptor. X-com and the aliens show the ability to enter hyperspace or whatever it is.
::: T'Leth is another mystery of its own. More to that later on :) [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)
::... there are no indications that the UFOs are INcapable of FTL... I don't think you would want to perform FTL travel within Earth's planetary atmosphere!
::: There are no indications that they are capable as well. And X-COM scientists don't seem to detect any FTL capabilities in UFOs during their research. And after the war the Elerium stocks dwindled, and it would make sense to perform some sort of interstellar missions to detect and harvest Elerium, however none are mentioned. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)
:::: Unless you count the events of X-com Interceptor? [[User:Jasonred]] [[User:Jasonred|Jasonred]] 21:15, 26 February 2009 (CST)
::::: I am refering to the events between Enemy Unknown and TFTD. There is clearly a big distinction between the alien craft on EU and those of Interceptor. [[User:Hobbes|Hobbes]] 09:38, 27 February 2009 (CST)
::::: Enemy Unknown is set in 1999, TFTD in 2040, Interceptor in 2067... looks entirely plausible that they DID begin research into space exploration immediately after the events of Enemy Unknown. These things take time you know. Remember that the universe is a huge place, and Earth had rather limited Elerium Reserves by the end of EU. It takes... what, 30 Elerium just to fly an Avenger halfway across Earth? They could hardly afford to fly around randomly in space HOPING to come across elerium, they had to figure out detections methods, then scan the galaxy sector by sector, possibly partially using non-Elerium based propulsion at times... I can't remember if it's canon or fanfic, but I remember reading that all Elerium on Earth was reserved for space exploration.
As for FTL, Earth does get it for sure sometime between 1999 and 2067. And I'm pretty certain the technology is Elerium based. It's not a huge logic jump to assume that the aliens have access to FTL Elerium based tech.
Though I'm a bit puzzled why all T'leth technology is based on Zrbrite, when the aliens uniformly use Elerium, all the way from Earth to Cydonia to the far reaches of space. -[[User:Jasonred|Jasonred]]

:It takes 12 Elerium to fuel an Avenger, though how much 1 Elerium is is an ongoing debate. As for Elerium, it was reserved for propulsion research when the funding nations divvied up X-COM's resources, and then they blew it all without learning anything more than the original X-COM scientists. And yes, Earth clearly gets FTL after TFTD but before Interceptor. The reason Elerium is not used in TFTD is because Elerium becomes inert and useless upon contact with seawater. Similarly, seawater aggressively corrodes Alien Alloys and eventually completely dissolves them. Zrbite functions similar to Elerium, being gold mixed with alien bio-material. Unfortunately, Zrbite only works when supported by a massive energy grid created by T'leth and becomes inert upon its destruction. [[User:Arrow Quivershaft|Arrow Quivershaft]] 12:07, 27 February 2009 (CST)

OK... take the UNIT of elerium out of the equation... let's say that Earth had 5000 units of elerium, so 6 units get's an Avenger halfway around the world, and 12 units is sufficient to reach Mars. Hardly enough fuel reserves for intergalactic travel then.
2065 On October the 27th, the probe 'Tombstone 1' returns reports to Earth. It's data show that the globular star cluster where it rests, one hundred light-years from Earth, contains many life-supporting planets. Many of the planet's within the probe's scanning range also apparently possess great mineral wealth, including trace veins of elerium-115.
Hmm... So, mankind discovers FTL technology on their own in those 65 years? ah... come to think of it, if they've got non-Elerium based space travel and FTL, and more powerful weapons too, what's the big deal about Elerium in the Frontier? Does mankind even need it anymore?
As for T'leth, it is meant to be over 65 million years old, and CRASHLANDED on Earth due to a solar flare. Was the Ultimate Alien a prophet, thus chose to base T'leth on aqua plastics and Zrbite when T'lth was first constructed? Or did T'leth crash land, followed by frenzied activity where the entire city was replaced part by part, the alien alloys swapped for Aqua Plastics?
...
Actually, come to think of it, it's obviously a massive plothole due to limited timeframe, no point in discussing too deeply. Sigh... [[User:Jasonred|Jasonred]] 13:50, 27 February 2009 (CST)

:It's implied that despite the loss of ability to use the alien technology from the First and Second alien wars, simply being able to see and examine their designs catapulted earth's technology forward at least a few decades...which really is entirely reasonable. Much of the technology can be replicated on earth, and the principles and designs can be reapplied.

:As for the deal with Elerium, its needed to power stronger weapons and is also wonderful for power generation; its efficiency in power generation is what allows Mega Primus to even exist.

:And was there anywhere that specifically said that T'Leth was made of Aqua Plastics? I don't recall. Yes, the rest of their subs are made of aqua plastics, but I'm wondering if something the size of a medium city might perhaps be made of something a bit more durable. PS: Thanks for signing your post! :D [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:17, 27 February 2009 (CST)

It's not a plothole at all. There is no Elerium on Earth, whereas the aliens can manufacture Zrbite on Earth, since there's gold here. Therefore it's obvious why they used Zrbite. Also, there's the fact that it was an Aquatoid colony mission, intended to produce an "aquatic paradise", so using Aqua Plastics instead of Alien Alloys is perfectly justified. [[User:magic9mushroom]]

... I think Alien Alloys alone would catapult earth's technology forward a decade, and there's no reason humanity can't use those anymore, just not in water. According to timeline, some space pirates manage to make the decommisioned Avengers run on non-Elerium fuel... a large technological step.
By the time of Interceptor, Elerium weapons aren't that powerful. Good point about power generation though.
I would assume that T'leth SHOULD have been constructed out of Alien Alloys, since it was originially an interplanetary vessel? Generally, everything in EU was made of Alien Alloys, everything in TFTD was made out of Aqua plastics. Both of which seemed plenty durable.

::Have you noticed that the UFOs fly however their mission parameters tell them to? The UFOs pretty much IGNORE interceptions by X-com craft... if their mission tells them to make 3 passes, speed up, slow down, speed up... they will follow that pattern exactly, whether X-com craft are firing on them or not.

::Question: How long does it take the Avenger to reach Mars from Earth? [[User:Jasonred]] [[User:Jasonred|Jasonred]] 19:12, 26 February 2009 (CST)
:::No longer than a week, in my opinion. Probably less than 2 days. Since canonically, the design of the Avenger had the Cydonia mission in mind, it would be capable of very high interplanetary speeds. (You could choose to burn 40% of the Elerium in one blast to get to high speed. Or you could burn even more and refuel while it's landed...or it could be a mission with no guaranteed escape for the crew. The lives of the many over those of the few and all that, especially since the war hinges on the mission.) In addition, you can fit a full complement of soldiers on board with no real excess room for supplies, and the longer it takes to get to Mars, the greater the chance the aliens will spot it coming for them and mount a serious defense. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:20, 26 February 2009 (CST)
:::If you'd burn that much fuel to accelerate the craft then you'd have to use as much again to decelerate it and attain a planetary orbit, otherwise you'll simply overshoot the planet and head towards outer space. This is also another aspect to take into account when thinking about the speed of UFOs. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)

::: UFO drives are non-Newtonian so those sort of rocket equations don't necessarily apply. I think filling up a car with gas is a closer analogy. [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

::: Well, they could put a mini mind shield on the Avenger, shoot down a UFO roughly their size, and then fly to Cydonia when the UFO they shot down was supposed to return based on the instructions found by the hyper-wave decoder. Basically taking the place of the UFO. Shouldn't be too hard since the UFO's are pretty common by the time you research Cydonia or Bust. [[User:Tsunamiatunzen1|Tsunamiatunzen1]] 14 February 2010 (MST)

::That would leave 20% of the fuel to take off the Avenger and land it. Not really that unreasonable. While they're landed, they could potentially refuel the Avenger, or the mission might have been planned as a 1-way trip from the get-go. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)

===What happened to Mars and the alien civilization there?===

According to the Brain, Mars was blooming with life had a alien civilization millions of years ago. However, Mars nowadays is a barren world and the alien civilization seems reduced to the area on Cydonia.

:That may well have been before Mars lost the majority of its atmosphere due to its weak magnetic field. As the atmosphere dissipated, the aliens left or died off. It's also possible that the aliens, shown in the game over to have little respect for planets other than as sites for slaves and resources, they strip-mined the planet dry(and the rust from the machines created the red coloring), and then seeded Earth so that the slave workforce would grow for future extraction of Earth's resources. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:33, 26 February 2009 (CST)

===Where are the human-alien hybrids referred to on the UFOPaedia?===

:For the ones on earth, probably in hiding or in laboratories for research. For the ones the aliens have, potentially improving the Sectoid gene pool or being used as food or menial tasks. Cloning is alot easier than making genetic hybrids and there's nothing that says their first-generation experiments would be suitable for combat. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:33, 26 February 2009 (CST)

:: They are babies at the time of X-com, and few in number. Their aren't even that many of them by the time of X-com Apocalypse. [[User:Jasonred]] [[User:Jasonred|Jasonred]] 19:12, 26 February 2009 (CST)

:Not to mention the ones in X-COM: Apocalypse are less-than-fit for battle before extensive training. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)

===Why did the aliens only activate T'Leth after they were defeated?===

On TFTD T'Leth is shown as an entity/city of major power that is capable of conducting a war on its own. But the aliens leave it dormant although they could have used it to speed the process of taking control of Earth.

:Perhaps the Enemy Unknown aliens are legitimately scared of the TFTD aliens and are unsure how long they could trust them. Evil is not monolithic; the TFTD aliens may be more interested in themselves than the alien empire, so they were kept as an ace-in-the-hole. This is the same reason (canonically) that SKYNET did not originally send the T-1000 to assassinate Sarah Connor; SKYNET was scared of what the T-1000 could do and had only a bare minimum of control over it, so it only used it as an option when it had nothing left to lose. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)

T'Leth is in fact so powerful that all it has to do is surface, in order for X-com to be considered to have lost the war.
In fact, looking at the timelines, it takes 40 years for T'leth to wake up from it's slumber... that's one good reason not to use it. By the time it activated, the war would already be over. [[User:Jasonred]]

Because the whole purpose of the Enemy Unknown aliens was to rescue the TFTD aliens from T'leth, and there was no way of seeing whether the T'leth-based invasion in TFTD would even work - from their perspective it's possible that getting T'leth to bootstrap itself could have caused a catastrophe (they don't know whether or how badly it's damaged). Presumably the aliens planned to mount a proper rescue operation after locking down Earth and readying it for the aquatic paradise that was the entire point of the T'leth expedition in the first place. [[User:magic9mushroom]]

T'Leth was a coleny ship sent by the Sectoid/Aquatoid's millions of years earlier. This is why the Aquatoids use electronics to augment there control over other creatures, while there progeny are genetically modified to gain the same control. In TFTD it's implied that the T'Leth had been partialy active for a long time. Thawing out aliens in small groups but never going in full production. UFO aliens may have not intended to start the full awakening cycle until they had a chance to prepare the planet.
OR, given the Ultimate Alien was aquatoid in origin by his looks and there was no other races from the first game involved. And the fact that Sectoid/Aqutoid's are not the top of the food chain with the Ethereal and Brain being more powerful it's possible the brain had decided that the Ultimate Alien was a threat to it's power. It was not until it's death that they tried send the signal. --[[User:BladeFireLight|BladeFireLight]] 17:19, 22 March 2010 (EDT)

===Why did the aliens use limited force during the First Alien War?===

Imagine Independence Day or War of the Worlds: UFO above the major Earth cities destroying the national leadership and any resistance. Or simply announce to Earth that they are now a part of their empire and resistence is futile. Instead, they go 1 mission each day, allowing humans to capture their craft, research their technology, discover their intentions and mount a successful defense. Don't the aliens watch sci-fi movies to see how it should be done?

:Perhaps they don't have the standing forces to do so, and are in the process of building up the forces needed to do so. Perhaps they don't want to wipe out the entire power structure too fast; they want to leave some pieces in place for when they rebuild. Perhaps they're too condescending to think that humanity ever really has a chance; they've probably conquered thousands of other planets without anyone ever successfully resisting them. Perhaps they consider the X-COM project to be a rearguard action that, while a valiant effort and a credible threat, is ultimately doomed to failure because they simply cannot win in the end, which is why they undermine it. Indeed, the reason you need to launch the Cydonia mission in order to win is because X-COM simply cannot stop the aliens in a ground war; the aliens have an effectively infinite supply line and standing forces(though nothing says they're all waiting to swamp the earth), and the only way to win is to kill the command staff(which the aliens believe X-COM will not be able to do, lacking both knowledge of where the Brain is and any practical means to get there.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)
::The most plausible explanation seems to be the one employed in the Worldwar series, by Harry Turtledove, but that does not seem to mesh with what the Brain says about having been on Mars for a while, since then they could watch the Earthlings perpetually. Of course, what it says is probably a bunch of lies. Thinking about what it says for too long also raises the question of why the aliens attacked when they did, of course... [[User:Vizzydix1|Vizzydix1]] 21:52, 18 March 2010 (EDT)

The aliens are completely lacking in weapons of mass destruction. When you get right down to it, their aircraft are very fast, manuevarable and durable, but they have rotten firepower. Even the battleship is unable to bring down an Interceptor in 1 shot.
The terror missions and X-com Base Defences prove that the Aliens are unable to simply launch orbital bombardments... in fact, they appear to have no Air to Land weapons whatsoever...
When you get right down to it, the aliens are pretty stupid. Also, their scientists seem inferior to Earth's. Seems to me that they only had the advantage of Elerium deposits and thus elerium based research.
X-COM was unable to win in an all-out war with the aliens, but remember that X-com is a small little covert group with several dozen soldiers and a handful of aircraft. Can you imagine the result if the aliens had caused a joint war effort by the UN? You would have Lockheed factories converted to Avenger production, several platoons of soldiers outfitted with Flying Suits, Lasers, Heavy Plasma, thousands upon thousands of Laser Tanks...
I would say that keeping the fight to covert action on both sides was actually beneficial to the aliens, really. [[User:Jasonred]]
* Nope, the aliens could just invoke John's Law and blow up the planet with a kamikaze battleship at .9c. Even failing that, the alien battlefleet could come in numbers sufficent to blot out the sun.--[[User:(name here)|(name here)]] 14:39, 8 November 2009 (EST)

==TFTD issues==
===What was the relationship between the aliens from the 1st and 2nd wars?===

Quoting from the UFOPaedia regarding Alien Origins: 'Deep in the oceans there lie ancient
sites used by the Aliens to contact their stellar cousins.' This also has some implications regarding the issue of why T'Leth was only activated when the Sectoids were defeated.

*Gill Men are coopted Terran creatures, Aquatoids are a differently-modified Sectoid breed, Lobstermen are machine soldiers that are manufactured, Tasoths are clone soldiers that are grown.

===What kind of materials were 'synomium' and 'adamantium'?===

The first one is mentioned on the name of the alien communication devices and the second one appears at the end when T'Leth is destroyed: 'he twisting hugeness of T'leth begins to rupture.
Flames and smoke spew from its gleaming spires and adamantium halls.'

:Synomium is probably a special material used in the comm. devices, like Stargate's naquadah (universal stuff), naquadria (unstable power source), trinium (hull material) and neutronium (superdense metal). Adamantium is a legendary material in ancient literature that is said to be indestructible, similarly to mithril.--[[User:Amitakartok|amitakartok]] 10:55, 3 November 2009 (EST)

===How deep were X-COM bases located on the seas?===

*Floating bases would be easier to build, repair and supply. However they would have to be tethered to the ocean bed or possess some sort of propulsion to prevent them from drifing with the ocean currents. But it would also allow for easy redeployment of the base.
*Submersible bases could allow for better sonar detection. Same problems regarding ocean currents would apply. In case of hull breaches entire modules would be quickly flooded and any crew present would be crushed by water pressure or drown. Base could be built and then submerged (requires depth control)
*Seabed bases would be the hardest to build and supply. Several other factors could limit their deployment, such as instable areas (underwater volcanos, prone to seaquakes, rock avalanches, etc.) and depths.
*Given that the Alien Retaliation missions in TFTD are called "Floating Base Attack", I'd say floating. Also remember that your starting sonar can't see Very Deep, which rules out seabed bases. [[User:magic9mushroom]]
** Floating doesn't always happen on the surface. The surface has to deal with large waves ad bobbing up and down, submerged only has the currents it could be stabilized easier. --[[User:BladeFireLight|BladeFireLight]] 11:57, 14 January 2010 (EST)
[[Category: Fiction]]

The Mysteries of X-COM

2010-03-22T21:19:36Z

BladeFireLight: /* Why did the aliens only activate T'Leth after they were defeated? */

Discussion page for some less clear aspects of the series

==General issues==

==='''How fast can alien craft travel in space?'''===

Some alien missions (repeated attacks on X-COM bases, for instance) come daily. This seems to imply that alien craft are able to travel the distance from Mars to Earth in a matter of hours.

: Or maybe, as you suggest in your novels, they have a staging area near Earth, such as the dark side of the Moon. [[User:Spike|Spike]] 15:36, 25 February 2009 (CST)

::Really fast. Consider that they don't need to push aside atmosphere, as well as the fact that momentum is conserved in space, so they can achieve very high speeds with gravity slingshots. (Mars DOES have 2 moons, recall.) Also note that they may be operating a bit closer to home(the far side of the moon, perhaps?) it's simply that the command staff are at Cydonia. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

Good article in last month's Scientific American pointing out we only rely on gravity slingshots because we still use chemical rockets with pathetic delta-V. Once 2nd and 3rd generation plasma engines come on line (1st gen are in flight now) the gravity slingshot will become an irrelevance. No doubt UFO drives are at least as good as our (future) 3rd gen plasma drives, probably way better since they warp space.

(Reminds me of the old Guild Navigator joke - I just warped space from Ix, and boy is my mind tired. Oh well, you had to be there)

[[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

==='''What happens to the crashed UFO craft and its crew?'''===

Downed alien craft disappear after a few days have passed. No explanation is given to this whatsoever, so what really happens to them?

Possible answers:
* The UFO and its occupants are recovered by other humans.
* The Aliens manage to repair the craft and fly back to space. (unlikely, in the event that the power plant blew up and they have no Elerium)
* The Aliens self-destruct the craft and kill themselves in the process, ensuring their remains will not be recovered by humans.
* The UFO Powerplant eventually suffers a meltdown and explodes, eliminating any vestiges of alien presence.
* The Aliens blow up the UFO and disappear into the countryside.
* Most likely answer, IMHO: The local government/ funding nations give X-COM a limited time window to launch any operation, similiar to what you see in covert ops movies: "Complete the mission within 36 hours, or we initiate Carpet Bombing of the area". This is very likely considering that each nation actually has jurisdiction, and X-com is operating each military op with permission and cooperation by local authorities. [[User:Jasonred|Jasonred]] 13:42, 25 February 2009 (CST)
*Similiarly, I assume that nations which have signed a pact with the aliens launch a rescue operation and assist their alien friends. [[User:Jasonred|Jasonred]] 13:42, 25 February 2009 (CST)
: In the UFO TV show, it's stated that alien craft and bodies degrade quickly in Earth's atmosphere, disappearing completely in hours or a few days. [[User:Spike|Spike]] 15:36, 25 February 2009 (CST)
:: If that was the case, then one of the gases present in the atmosphere would be very toxic to the aliens. They would be restricted on their activities outside their craft, not to mention they would have to terraform the planet to be able to live here. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)

:: As Zombie said, doesn't Alien Containment support this idea? [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

::Those are excellent suggestions. One of the X-COM books detailed that aliens throw up a force field around crashed UFOs to give them time to repair the craft. This would also explain the limited size of the Battlescape (the area of the force field...the field was thrown up before the crash, thus why the craft wasn't always centered in it) as well as why the Battlescape is devoid of human life(the aliens took care of that up front.) Similarly, large scale bombing works as well, as does the local government going in to clean it up themselves. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)
:::If there's a force field around the craft what is it supposed to repel? The atmosphere? Because humans have no problem entering the field and operating inside it. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)
::::Of course they do! Have you ever noticed how dumb your units can be? That's because the aliens can't live with too much nitrogen, so they turn some of it in their force field to oxygen, and excessive amounts of oxygen make you act weird. After a while, their power source runs out and the nitrogen returns, dissolving them into E-115. (What did you think it was made of?) AT least, that's what seemes logical to me, ad is a combination of many postulates here. 21:36, 18 March 2010 (EDT)
:::::That would require that the aliens' biochemistry and the alien alloys used in the power sources reacted with nitrogen, which is a mostly inert gas on normal temperature and pressure and a . It's kinda of weird that the aliens didn't bothered with fixing that vulnerability with their craft and bodies during millions of years (what happens if the force field malfunctions while capturing cattle? ooops!) but ok. The increase in the amount of oxygen would probably also turn any kind of fire into large explosions throughtout the force field. [[User:Hobbes|Hobbes]] 21:24, 19 March 2010 (EDT)
::The force field was intended to keep humans out so the aliens were undisturbed. The first major hurdle X-COM had was figuring out a way to bypass those fields so they COULD get troops and aircraft inside. [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:54, 26 February 2009 (CST)

===How do the aliens carry their equipment?===
Like human soldiers, aliens can carry weapons and equipment in locations like legs, belt, shoulders and backpack, regardless of the fact that some of their races even lack those anatomical features.

:Potentially a sticky gel-like area on the limb. Though really, since we were never intended to access alien inventories and the AI does all inventory management internally, this may simply be something that was never considered. Speaking from a slightly different standard, most aliens do not carry excessive amounts of gear; often their equipment would be able to fit in both hands. Also recall that Floaters and Ethereals have capes and robes(which may have inside pockets, or the Floaters could store them in the anti-grav/life support unit or inside surgically created body cavities during the installation, while Ethereals could support their excess gear with telekinesis), Mutons have armor(which may have external straps or adhesive areas), and Snakemen have an armor plate(which could have straps, adhesive, inside pockets, or even a backpack.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

:We already know the answer to this one - they cheat! ;) [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

===Are X-COM transport craft piloted?===

:Almost certainly, since a remotely-piloted craft could be returned to base when the mission was aborted or failed. It's entirely possible that all X-COM soldiers are qualified pilots of the appropriate craft, since it would make no sense for X-COM to waste space on the plane for a noncombatant, or to have a single-point of failure on the mission like that. (The aliens could screw over the entire op by killing the pilot). It also explains why the craft is lost when the mission fails or is aborted with no one inside(lacking a pilot, the aliens are able to easily destroy it.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

:: On the other hand, even a tank/hovertank is capable of getting the craft back to base. Perhaps there is an autopilot function. X-com craft are also infamous for choosing strange and bizarre intercept paths, based on latitude lines... almost as if they followed some a few simple lines of code from 1993 programming (bit of 4th wall breakage there...) -[[User:Jasonred|Jasonred]]

:Of course, given the tanks seem to be remotely piloted from an X-COM base, its possible that the tank being in the craft allows the Tank pilot to reroute into the control systems for the dropship and take it over. Limiting this to having the tank inside is a rather good idea. [[User:Arrow Quivershaft|Arrow Quivershaft]] 12:07, 27 February 2009 (CST)

:I recall that the various cutscenes in the PSX version had a pilot, most notably in the "Mission Failure" scene, where it shows the pilot being killed. --[[User:Mabmoro|Mabmoro]] 16:06, 13 March 2009 (EDT)

===What sort of physical process is used to increase human stats over time?===

The increases in some stats are easy explained by experience gained on missions (firing abiility, reactions, etc.). However, in the cases of physical stats (TUs, stamina, strength) the increase must be augmented by an artificial process, since it isn't easily explainable that humans can significantly increase body mass/speed/endurance just by physical activity/exercise.

:Lifting weights will increase strength. Running and cardio exercise will increase endurance, and performing the same task multiple times will allow you to perform it faster. I see no reason natural increase doesn't work. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:33, 26 February 2009 (CST)
::I assume that it is possible to a human to use those methods to double its physical condition, but that being the case why are X-COM recruits so... undeveloped? Maybe this is a more intriguing aspect. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)

What I don't get is that when someone gets blasted that they gain a lot of extra health. For crying out loud, the aliens are throwing around plasma and ridicoulously HUGE explosions. Shouldn't they be suffering from third-degree burns? I would expect them to at least have a major sore spot where they got hit. [[User:Tsunamiatunzen1|Tsunamiatunzen1]] September 24

:There's been arguments over whether the soldiers in X-COM are the Green Berets or equivalents of their various militaries, just average soldiers that volunteered for the job, or if the Council of Funding Nations is corrupt and is using this as an excuse to foist off their most useless soldiers onto the X-COM project. If the latter, it would easily explain their rather poor early stats. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)

::Maybe the stat increases relate to the troops getting more comfortable performing all operations - lifting, running, combat actions - when the aliens no longer scare the cr*p out of them so much. [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

:: I know what you mean... if this were Jagged Alliance, it'd be like trying to hire Mike and getting Gumpy instead... ouch! ... IMHO, it looks as if the COFN is being funny about this. Clearly, the troops assigned to X-com have had extensive weapons training... each and every one of them can use just about any standard weapon, including Rocket Launchers, incindieries, auto Cannons, etc. However, NONE of them have any combat experience, coming to you as fresh rookies. And their stats look as if they were selected based on a pot luck basis rather than screening among the elite troops... [[User:Jasonred]]

:Health isn't gained from getting shot. But as for the "ludicrously low stats" issue, maybe they're being selected on some other basis, or there's a real shortage of volunteers. [[User:Magic9mushroom|Magic9mushroom]] 04:56, 25 September 2009 (EDT)

==Enemy Unknown/UFO Defence issues==
==='''Why isn't Earth overrun by Snakeman/Chryssalids?'''===

According to the UFOPaedia, Snakemen's "Reproduction is asexual, with each snakeman carrying up to fifty eggs inside its body at any one time" adding the ominious conclusion: "Left to its own devices this species would be a severe threat to life on earth."
Moreover, this species is usually accompanied by the Chryssalids, which have a capacity to reproduce themselves very quickly using humans. So, any survivors of crash sites or terror attacks could start reproducing themselves hidden, resulting in large areas being overrun by those aliens later on.

Possible answers:
* Both races have a self-destruct mechanism incorporated into their psysiology to prevent this.
* The entire area is purged by large scale bombing. [[User:Jasonred|Jasonred]] 13:42, 25 February 2009 (CST)

::One thing suggested in fan data was that Snakemen have air tablets in their stomach...which may be different from earth's atmosphere, which would limit their lifespan in earth's atmosphere, also making egg-laying pointless, since the offspring wouldn't be able to breathe or survive. It has also been suggested that Chryssalids have a very rapid metabolism. Though Chryssalids are likely just as, if not more useful, as a threat or a bargaining tool. When attempting to get a nation to capitulate to their demands, the aliens could threaten to employ Chryssalids en masse, or offer to remove a mass infestation in exchange for the government's cooperation. Or even further, it's possible that Chryssalids are under Ethereal control and maintaining the control link at that distance is taxing, thus eliminating mass use of the creatures. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

Two words: [[Alien Containment]]. That answers everything except for the UFOPaedia articles for the aliens themselves which contradict it. --[[User:Zombie|Zombie]] 00:42, 26 February 2009 (CST)
: For captured aliens, yes. But what survivors of uninvestigated crash sites? [[User:Hobbes|Hobbes]]

::Zombie is commenting that based on the need for an Alien Containment unit, the aliens cannot survive in earth's atmosphere for extended periods, needing special atmospheric blends and/or nutrient pools which earth is unable to provide naturally, thus limiting their operations outside of the craft. (If the aliens won the war, it's likely this would be one of the first things that they would 'correct'.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 20:54, 26 February 2009 (CST)

===What is the propose of the 'disco balls' found inside some UFOs?===

:Given that they explode, they could be storage reservoirs for coolant for the computers or other systems. They could also be circuit breakers or electrical junction boxes, or even a component of the UFO's particle beam they use to fry X-COM Interception craft. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)

Here again, two words: [[Alien Entertainment]]. Even though the spheres are not set to Alien Entertainment in the MCD files, they are almost certainly related to the process somehow. --[[User:Zombie|Zombie]] 00:42, 26 February 2009 (CST)

:Maybe they are for having discos? [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

:Presumably [[Alien Entertainment]] is psionic in some way, maybe they're Psi-Emitters or something? -[[User:magic9mushroom|magic9mushroom]]

===Who buys those alien bodies/equipment from X-COM?===

:Equipment likely goes to the funding nations or the international black market. No rebel group is going to ask too many questions about being offered guns that can [[Heavy Plasma|slice through the hull of an MBT]] or [[Alien Grenade|grenades that can level a building]] or [[Blaster Launcher|man-portable guided missiles]]; it'd just be cash-and-carry. Similarly, scientists would likely be interested in looking at much of this stuff for their own research. This would also explain the lack of market forces; the funding nations could have a set price for each item, or if X-COM is selling them under the table to rebels and rogue scientists, they can set the price and refuse to budge. The money on corpses could also be an "Alien Bounty" paid by the Funding Nations, as a reward for each alien that X-COM can prove they killed. Or it could be bought by other groups...rumor has it that some fast food restaurants have processes that can make ANY meat, no matter the source, look and taste the same, and a Muton would make a LOT of McBurgers. [[User:Arrow Quivershaft|Arrow Quivershaft]] 00:19, 26 February 2009 (CST)
From the USO (Kasey Chang): XARQUID SUSHI.

===How did the aliens got to Mars?===

There are no indications that UFOs are capable of faster than light speed. So how did they get to Mars in the first place?

:The UFOs are mission craft, used for the legwork. The fighters; we never see the carriers. Given the aliens have been proven to be interstellar, they either Clone-A-Crew as needed when coming the long way to keep the UFOs crewed, or its far more likely that the aliens did have or still do have larger "Carrier" ships, which are capable of FTL travel, that were/are further out in the Solar System that store and dispatch UFOs to mission locations. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:33, 26 February 2009 (CST)

:: One word: TFTD. The entire city of T'leth was put into cryogenic suspended animation? Or look at X-com Interceptor. X-com and the aliens show the ability to enter hyperspace or whatever it is.
::: T'Leth is another mystery of its own. More to that later on :) [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)
::... there are no indications that the UFOs are INcapable of FTL... I don't think you would want to perform FTL travel within Earth's planetary atmosphere!
::: There are no indications that they are capable as well. And X-COM scientists don't seem to detect any FTL capabilities in UFOs during their research. And after the war the Elerium stocks dwindled, and it would make sense to perform some sort of interstellar missions to detect and harvest Elerium, however none are mentioned. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)
:::: Unless you count the events of X-com Interceptor? [[User:Jasonred]] [[User:Jasonred|Jasonred]] 21:15, 26 February 2009 (CST)
::::: I am refering to the events between Enemy Unknown and TFTD. There is clearly a big distinction between the alien craft on EU and those of Interceptor. [[User:Hobbes|Hobbes]] 09:38, 27 February 2009 (CST)
::::: Enemy Unknown is set in 1999, TFTD in 2040, Interceptor in 2067... looks entirely plausible that they DID begin research into space exploration immediately after the events of Enemy Unknown. These things take time you know. Remember that the universe is a huge place, and Earth had rather limited Elerium Reserves by the end of EU. It takes... what, 30 Elerium just to fly an Avenger halfway across Earth? They could hardly afford to fly around randomly in space HOPING to come across elerium, they had to figure out detections methods, then scan the galaxy sector by sector, possibly partially using non-Elerium based propulsion at times... I can't remember if it's canon or fanfic, but I remember reading that all Elerium on Earth was reserved for space exploration.
As for FTL, Earth does get it for sure sometime between 1999 and 2067. And I'm pretty certain the technology is Elerium based. It's not a huge logic jump to assume that the aliens have access to FTL Elerium based tech.
Though I'm a bit puzzled why all T'leth technology is based on Zrbrite, when the aliens uniformly use Elerium, all the way from Earth to Cydonia to the far reaches of space. -[[User:Jasonred|Jasonred]]

:It takes 12 Elerium to fuel an Avenger, though how much 1 Elerium is is an ongoing debate. As for Elerium, it was reserved for propulsion research when the funding nations divvied up X-COM's resources, and then they blew it all without learning anything more than the original X-COM scientists. And yes, Earth clearly gets FTL after TFTD but before Interceptor. The reason Elerium is not used in TFTD is because Elerium becomes inert and useless upon contact with seawater. Similarly, seawater aggressively corrodes Alien Alloys and eventually completely dissolves them. Zrbite functions similar to Elerium, being gold mixed with alien bio-material. Unfortunately, Zrbite only works when supported by a massive energy grid created by T'leth and becomes inert upon its destruction. [[User:Arrow Quivershaft|Arrow Quivershaft]] 12:07, 27 February 2009 (CST)

OK... take the UNIT of elerium out of the equation... let's say that Earth had 5000 units of elerium, so 6 units get's an Avenger halfway around the world, and 12 units is sufficient to reach Mars. Hardly enough fuel reserves for intergalactic travel then.
2065 On October the 27th, the probe 'Tombstone 1' returns reports to Earth. It's data show that the globular star cluster where it rests, one hundred light-years from Earth, contains many life-supporting planets. Many of the planet's within the probe's scanning range also apparently possess great mineral wealth, including trace veins of elerium-115.
Hmm... So, mankind discovers FTL technology on their own in those 65 years? ah... come to think of it, if they've got non-Elerium based space travel and FTL, and more powerful weapons too, what's the big deal about Elerium in the Frontier? Does mankind even need it anymore?
As for T'leth, it is meant to be over 65 million years old, and CRASHLANDED on Earth due to a solar flare. Was the Ultimate Alien a prophet, thus chose to base T'leth on aqua plastics and Zrbite when T'lth was first constructed? Or did T'leth crash land, followed by frenzied activity where the entire city was replaced part by part, the alien alloys swapped for Aqua Plastics?
...
Actually, come to think of it, it's obviously a massive plothole due to limited timeframe, no point in discussing too deeply. Sigh... [[User:Jasonred|Jasonred]] 13:50, 27 February 2009 (CST)

:It's implied that despite the loss of ability to use the alien technology from the First and Second alien wars, simply being able to see and examine their designs catapulted earth's technology forward at least a few decades...which really is entirely reasonable. Much of the technology can be replicated on earth, and the principles and designs can be reapplied.

:As for the deal with Elerium, its needed to power stronger weapons and is also wonderful for power generation; its efficiency in power generation is what allows Mega Primus to even exist.

:And was there anywhere that specifically said that T'Leth was made of Aqua Plastics? I don't recall. Yes, the rest of their subs are made of aqua plastics, but I'm wondering if something the size of a medium city might perhaps be made of something a bit more durable. PS: Thanks for signing your post! :D [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:17, 27 February 2009 (CST)

It's not a plothole at all. There is no Elerium on Earth, whereas the aliens can manufacture Zrbite on Earth, since there's gold here. Therefore it's obvious why they used Zrbite. Also, there's the fact that it was an Aquatoid colony mission, intended to produce an "aquatic paradise", so using Aqua Plastics instead of Alien Alloys is perfectly justified. [[User:magic9mushroom]]

... I think Alien Alloys alone would catapult earth's technology forward a decade, and there's no reason humanity can't use those anymore, just not in water. According to timeline, some space pirates manage to make the decommisioned Avengers run on non-Elerium fuel... a large technological step.
By the time of Interceptor, Elerium weapons aren't that powerful. Good point about power generation though.
I would assume that T'leth SHOULD have been constructed out of Alien Alloys, since it was originially an interplanetary vessel? Generally, everything in EU was made of Alien Alloys, everything in TFTD was made out of Aqua plastics. Both of which seemed plenty durable.

::Have you noticed that the UFOs fly however their mission parameters tell them to? The UFOs pretty much IGNORE interceptions by X-com craft... if their mission tells them to make 3 passes, speed up, slow down, speed up... they will follow that pattern exactly, whether X-com craft are firing on them or not.

::Question: How long does it take the Avenger to reach Mars from Earth? [[User:Jasonred]] [[User:Jasonred|Jasonred]] 19:12, 26 February 2009 (CST)
:::No longer than a week, in my opinion. Probably less than 2 days. Since canonically, the design of the Avenger had the Cydonia mission in mind, it would be capable of very high interplanetary speeds. (You could choose to burn 40% of the Elerium in one blast to get to high speed. Or you could burn even more and refuel while it's landed...or it could be a mission with no guaranteed escape for the crew. The lives of the many over those of the few and all that, especially since the war hinges on the mission.) In addition, you can fit a full complement of soldiers on board with no real excess room for supplies, and the longer it takes to get to Mars, the greater the chance the aliens will spot it coming for them and mount a serious defense. [[User:Arrow Quivershaft|Arrow Quivershaft]] 19:20, 26 February 2009 (CST)
:::If you'd burn that much fuel to accelerate the craft then you'd have to use as much again to decelerate it and attain a planetary orbit, otherwise you'll simply overshoot the planet and head towards outer space. This is also another aspect to take into account when thinking about the speed of UFOs. [[User:Hobbes|Hobbes]] 20:32, 26 February 2009 (CST)

::: UFO drives are non-Newtonian so those sort of rocket equations don't necessarily apply. I think filling up a car with gas is a closer analogy. [[User:Spike|Spike]] 13:24, 27 February 2009 (CST)

::: Well, they could put a mini mind shield on the Avenger, shoot down a UFO roughly their size, and then fly to Cydonia when the UFO they shot down was supposed to return based on the instructions found by the hyper-wave decoder. Basically taking the place of the UFO. Shouldn't be too hard since the UFO's are pretty common by the time you research Cydonia or Bust. [[User:Tsunamiatunzen1|Tsunamiatunzen1]] 14 February 2010 (MST)

::That would leave 20% of the fuel to take off the Avenger and land it. Not really that unreasonable. While they're landed, they could potentially refuel the Avenger, or the mission might have been planned as a 1-way trip from the get-go. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)

===What happened to Mars and the alien civilization there?===

According to the Brain, Mars was blooming with life had a alien civilization millions of years ago. However, Mars nowadays is a barren world and the alien civilization seems reduced to the area on Cydonia.

:That may well have been before Mars lost the majority of its atmosphere due to its weak magnetic field. As the atmosphere dissipated, the aliens left or died off. It's also possible that the aliens, shown in the game over to have little respect for planets other than as sites for slaves and resources, they strip-mined the planet dry(and the rust from the machines created the red coloring), and then seeded Earth so that the slave workforce would grow for future extraction of Earth's resources. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:33, 26 February 2009 (CST)

===Where are the human-alien hybrids referred to on the UFOPaedia?===

:For the ones on earth, probably in hiding or in laboratories for research. For the ones the aliens have, potentially improving the Sectoid gene pool or being used as food or menial tasks. Cloning is alot easier than making genetic hybrids and there's nothing that says their first-generation experiments would be suitable for combat. [[User:Arrow Quivershaft|Arrow Quivershaft]] 18:33, 26 February 2009 (CST)

:: They are babies at the time of X-com, and few in number. Their aren't even that many of them by the time of X-com Apocalypse. [[User:Jasonred]] [[User:Jasonred|Jasonred]] 19:12, 26 February 2009 (CST)

:Not to mention the ones in X-COM: Apocalypse are less-than-fit for battle before extensive training. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)

===Why did the aliens only activate T'Leth after they were defeated?===

On TFTD T'Leth is shown as an entity/city of major power that is capable of conducting a war on its own. But the aliens leave it dormant although they could have used it to speed the process of taking control of Earth.

:Perhaps the Enemy Unknown aliens are legitimately scared of the TFTD aliens and are unsure how long they could trust them. Evil is not monolithic; the TFTD aliens may be more interested in themselves than the alien empire, so they were kept as an ace-in-the-hole. This is the same reason (canonically) that SKYNET did not originally send the T-1000 to assassinate Sarah Connor; SKYNET was scared of what the T-1000 could do and had only a bare minimum of control over it, so it only used it as an option when it had nothing left to lose. [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)

T'Leth is in fact so powerful that all it has to do is surface, in order for X-com to be considered to have lost the war.
In fact, looking at the timelines, it takes 40 years for T'leth to wake up from it's slumber... that's one good reason not to use it. By the time it activated, the war would already be over. [[User:Jasonred]]

Because the whole purpose of the Enemy Unknown aliens was to rescue the TFTD aliens from T'leth, and there was no way of seeing whether the T'leth-based invasion in TFTD would even work - from their perspective it's possible that getting T'leth to bootstrap itself could have caused a catastrophe (they don't know whether or how badly it's damaged). Presumably the aliens planned to mount a proper rescue operation after locking down Earth and readying it for the aquatic paradise that was the entire point of the T'leth expedition in the first place. [[User:magic9mushroom]]

T'Leth was a coleny shop send by the aliens millions of years earlyer. This is why the Aquatoids use electronics to augment there control over other creaturs, while there progeny are geneticly modified to gain the same control. In TFTD it's implied that the T'Leth had been partialy active for a long time. Thawing out alines in small groups but never going in full production. UFO aliens may have not intended to start the full awakening cycle untill they had a chance to prepair the planet.
OR, given the Ultimate Alien was aquatoid in origin by his looks and there was no other races from the first game involved. And the fact that Sectoid/Aqutoid's are not the top of the food chain with the Ethereal and Brain being more powerful it's possible the brain had decided that the Ultimate Alien was a threat to it's power. It was not until it's death that they tried send the signal. --[[User:BladeFireLight|BladeFireLight]] 17:19, 22 March 2010 (EDT)

===Why did the aliens use limited force during the First Alien War?===

Imagine Independence Day or War of the Worlds: UFO above the major Earth cities destroying the national leadership and any resistance. Or simply announce to Earth that they are now a part of their empire and resistence is futile. Instead, they go 1 mission each day, allowing humans to capture their craft, research their technology, discover their intentions and mount a successful defense. Don't the aliens watch sci-fi movies to see how it should be done?

:Perhaps they don't have the standing forces to do so, and are in the process of building up the forces needed to do so. Perhaps they don't want to wipe out the entire power structure too fast; they want to leave some pieces in place for when they rebuild. Perhaps they're too condescending to think that humanity ever really has a chance; they've probably conquered thousands of other planets without anyone ever successfully resisting them. Perhaps they consider the X-COM project to be a rearguard action that, while a valiant effort and a credible threat, is ultimately doomed to failure because they simply cannot win in the end, which is why they undermine it. Indeed, the reason you need to launch the Cydonia mission in order to win is because X-COM simply cannot stop the aliens in a ground war; the aliens have an effectively infinite supply line and standing forces(though nothing says they're all waiting to swamp the earth), and the only way to win is to kill the command staff(which the aliens believe X-COM will not be able to do, lacking both knowledge of where the Brain is and any practical means to get there.) [[User:Arrow Quivershaft|Arrow Quivershaft]] 21:06, 26 February 2009 (CST)
::The most plausible explanation seems to be the one employed in the Worldwar series, by Harry Turtledove, but that does not seem to mesh with what the Brain says about having been on Mars for a while, since then they could watch the Earthlings perpetually. Of course, what it says is probably a bunch of lies. Thinking about what it says for too long also raises the question of why the aliens attacked when they did, of course... [[User:Vizzydix1|Vizzydix1]] 21:52, 18 March 2010 (EDT)

The aliens are completely lacking in weapons of mass destruction. When you get right down to it, their aircraft are very fast, manuevarable and durable, but they have rotten firepower. Even the battleship is unable to bring down an Interceptor in 1 shot.
The terror missions and X-com Base Defences prove that the Aliens are unable to simply launch orbital bombardments... in fact, they appear to have no Air to Land weapons whatsoever...
When you get right down to it, the aliens are pretty stupid. Also, their scientists seem inferior to Earth's. Seems to me that they only had the advantage of Elerium deposits and thus elerium based research.
X-COM was unable to win in an all-out war with the aliens, but remember that X-com is a small little covert group with several dozen soldiers and a handful of aircraft. Can you imagine the result if the aliens had caused a joint war effort by the UN? You would have Lockheed factories converted to Avenger production, several platoons of soldiers outfitted with Flying Suits, Lasers, Heavy Plasma, thousands upon thousands of Laser Tanks...
I would say that keeping the fight to covert action on both sides was actually beneficial to the aliens, really. [[User:Jasonred]]
* Nope, the aliens could just invoke John's Law and blow up the planet with a kamikaze battleship at .9c. Even failing that, the alien battlefleet could come in numbers sufficent to blot out the sun.--[[User:(name here)|(name here)]] 14:39, 8 November 2009 (EST)

==TFTD issues==
===What was the relationship between the aliens from the 1st and 2nd wars?===

Quoting from the UFOPaedia regarding Alien Origins: 'Deep in the oceans there lie ancient
sites used by the Aliens to contact their stellar cousins.' This also has some implications regarding the issue of why T'Leth was only activated when the Sectoids were defeated.

*Gill Men are coopted Terran creatures, Aquatoids are a differently-modified Sectoid breed, Lobstermen are machine soldiers that are manufactured, Tasoths are clone soldiers that are grown.

===What kind of materials were 'synomium' and 'adamantium'?===

The first one is mentioned on the name of the alien communication devices and the second one appears at the end when T'Leth is destroyed: 'he twisting hugeness of T'leth begins to rupture.
Flames and smoke spew from its gleaming spires and adamantium halls.'

:Synomium is probably a special material used in the comm. devices, like Stargate's naquadah (universal stuff), naquadria (unstable power source), trinium (hull material) and neutronium (superdense metal). Adamantium is a legendary material in ancient literature that is said to be indestructible, similarly to mithril.--[[User:Amitakartok|amitakartok]] 10:55, 3 November 2009 (EST)

===How deep were X-COM bases located on the seas?===

*Floating bases would be easier to build, repair and supply. However they would have to be tethered to the ocean bed or possess some sort of propulsion to prevent them from drifing with the ocean currents. But it would also allow for easy redeployment of the base.
*Submersible bases could allow for better sonar detection. Same problems regarding ocean currents would apply. In case of hull breaches entire modules would be quickly flooded and any crew present would be crushed by water pressure or drown. Base could be built and then submerged (requires depth control)
*Seabed bases would be the hardest to build and supply. Several other factors could limit their deployment, such as instable areas (underwater volcanos, prone to seaquakes, rock avalanches, etc.) and depths.
*Given that the Alien Retaliation missions in TFTD are called "Floating Base Attack", I'd say floating. Also remember that your starting sonar can't see Very Deep, which rules out seabed bases. [[User:magic9mushroom]]
** Floating doesn't always happen on the surface. The surface has to deal with large waves ad bobbing up and down, submerged only has the currents it could be stabilized easier. --[[User:BladeFireLight|BladeFireLight]] 11:57, 14 January 2010 (EST)
[[Category: Fiction]]

Talk:XcomUtil

2010-03-18T07:22:45Z

BladeFireLight: /* Open Bugs */

=XcomUtil 9.7 Beta=

9.7 Beta is available on www.bladefirelight.com

==Release Notes==

This is a Beta, so backup your files before using. And check back often for newer builds.

New in this version.

*Major overhall of the installer (XcuSetup) and the inclusion of 16/32bit exe's to support both DOSBox and Windows Vista/7 x64.
*New subfolders added to hold supporting files making the install cleaner
*New XcuSetup command line arguments were added to XcuSetup allowing for silent install and uninstallation.
*New XcuSetup option for debugging the install (XcuSetup debug) creating XcomUtil\debug.txt.
*New command line argument "nobackup" skips backup only if it has been ran atleast once.
*XcuSetup can now have minimal impact on the game.
**Almost all options default to NO (Only Split Windows EXE set to Yes).
**Almost all changes are now prompted for (skyranger guns, interceptor as transport, Disjointed Base Bug, etc...).
***Items still done by default:
***Copy protection questions set to 0000000 for UFO 1.0-1.3 and X-Com 1.0
***Difficulty bug fixed in UFO 1.0-1.4 and X-Com 1.0-1.4
***Unique names for all maps in TFTD, Used for Hybrid Games
***Placement of X-Com Units on the Battlefield based on XcomUtil.cfg
***MIA Recovery on Won Combat (Units under mind\MC control when last controling alien killed are returned to X-Com control)
*XcomUtil.cfg is now pieced together and overwritten by XcuSetup (see XcomUtil\XcomUtil.txt for how to make permanent changes).
*All game files are restored to the pre-XcomUtil state each time XcuSetup is ran. Any modifications by other utilities will have to be re-applied.
*Vista/Win7 patch now an option for XcuSetup.
**This will fix the blank screen issue.
**Updated to support the split EXE.
**Will set X-Com to use CPU 0.
*XcuSetup attempts to fix UAC issues by resetting folder permissions.
*A number of community made fixes are included and selectable with XcuSetup.
*Support for the DOS/Window STEAM Install.
**Installer will detect STEAM and change steam launcher to start the XcomUtil Steam Menu (can be re-installed with XcomUtil\SteamSetup.bat
*Out of the box support for UFO Extender. XcuSetup will detect it and ask if you want RunXcom to use it.
*XcuSetup can be run from windows and RunXcom run from DosBox
*Hybrid Colors updated based on BombBloke's pallets.
*EQL flag allowed any turn.
*Add Xcom UFO Italian Support.
*Auto Combat will not run on second half of two part using first parts saved data.
*Auto Combat will no longer run if combat was won.
*MIA Recovery on won combat only.
*MIA Recovery no longer recovering units that bleed to death.
*Auto equip no longer triggers on second part of 2 stage missions.
*Combine clips skiped if between stages of 2-3 part missions.
*Updated f0dders ReadMe per his request. (XcomUtil\bugfix-readme.txt)
*Add-on support added. see XcomUtil\XcomUtil.txt and XcomUtil\Addon\Example.txt
*Prompted Terrain in BattleField Generator allows to abort or use of current setting.
*Beta versions include
**XcomUtil\XcomUtil.log includes lots of debug info
**XcomUtil\Debug.txt created by default (Release will need "debug" command argument)

Removed from this versions

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

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

===Build 435===

Original Sound Effects from UFO were re-sampled to work with 1.4 and CE.

*Add Category to option headers.
*Improve randomness by using current time instead of game date/time in srand()
*Added Option to keep Current terrain/UFO to BFG.
*Original UFO 1.2 Sounds for Geoscape and Tactical added as an option for UFO 1.4 and CE.
*Force Split EXE on STEAM. Fixes issues with setup failing.
*Reset Laser/Gauss craft weapons stats to be default.
*Example addon now uses different flag extension to avoid deletion by XcuSetup
*fix issue with Lab Screen on DosBox always screening

==Beta Discussion==

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

----

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

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

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

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

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

----

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

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

----

I have a strange issue. I succeed in an AutoCombat terror mission (117%) but the mission is resolved partially as if I had actually aborted the mission - all Civilians die, even though I could see 3-4 alive, my 13 soldiers outside the Skyranger go MIA, even the one who was killed by AutoCombat, and only my sergeant standing in the Skyranger makes it back. The problem is repeatable. On one occasion the sergeant was killed randomly by AutoCombat, meaning that the Skyranger flew back by itself, empty. Obviously this should never happen.

I've uploaded the [[Media:MIAoverload.zip|AutoCombat game save file]]. Incidentally this shows how to 'game' the current AutoCombat rules: Take maximum soldiers, no tanks. You give everyone a Rocket Launcher, they only need 1 Lg Rocket in it. Until you get Heavy Lasers, then replace the Rocket Launchers with them. Next replace with Heavy Plasmas. This approach always gives you maximum damage per soldier, and thus maximum chance of getting the +15 bonus for the W:3- rule. [[User:Spike|Spike]] 19:02, 15 March 2010 (EDT)

:: Hmmm. Scott's MIA recovery raised an army of undead from those that died of fatal wounds. Mine only effects mind controlled units. The issue is telling who is dead and who is left behind.

Units from your saved game looked like this(on by Autocombat).

Shuji Okabe: Left behind (Health > 0)
[[UNITPOS.DAT|UnitPos]][0x0A] 1.0.0.0.0.0.0.0 (bit 2 == 0 Unit on the ground[dead or unconscious])
[[UNITREF.DAT|UnitRef]][0x78] 0.0.0.0.0.0.1.0 (bit 1 == 0 Unit Alive)
Yoko Fujimoto: On Craft (Health > 0)
UnitPos[0x0A] 1.1.0.0.0.0.0.0 (bit 2 == 1 Unit Standing [Active])
UnitRef[0x78] 0.0.0.1.0.0.0.0 (bit 1 == 0 Unit Alive)

From Bomb Blokes undead army MIA Test save (won by killing aliens).

Spencer Bryant: Lived (Health > 0)
[[UNITPOS.DAT|UnitPos]][0x0A] 0.1.0.0.0.1.0.0 (bit 2 == 1 Unit Standing [Active])
[[UNITREF.DAT|UnitRef]][0x78] 0.1.0.0.0.0.0.1 (bit 1 == 0 Unit Alive)
Oscar Thompson: Bleed to death (Health > 0)
UnitPos[0x0A] 0.0.0.0.0.1.0.0 (bit 2 == 0 Unit on the ground[dead or unconscious])
UnitRef[0x78] 0.1.0.0.0.0.0.1 (bit 1 == 0 Unit Alive)
Virgil Hudson: Killed by Aliens (Health == 0)
UnitPos[0x0A] 0.0.0.0.0.1.0.0 (bit 2 == 0 Unit on the ground[dead or unconscious])
UnitRef[0x78] 1.1.0.0.0.0.0.1 (bit 1 == 1 Unit Dead)

So right now I'm at a loss of how to detect tell the difference between thoes that are left behind and thoes that are dead.

:There must be something odd about my save game that takes 13 live soldiers and makes them all MIA on an abort. I wonder if it is something to do with the one guy who is still on the transport. I'm sure I've never seen an MIA after an AutoCombat victory, or defeat, before. Of course, after a victory, no one should be MIA. In a defeat, in theory AutoCombat could (but doesn't?) allocate some soldiers as MIAs. For the bleeding to death problem, perhaps you could check whether Health <= Fatal Wounds. In the normal game this might be an ambiguous borderline case? Treat it unambiguously - kill any soldiers matching that condition. In XComUtil after-combat messages, perhaps emit the message "So-and-so died from his/her wounds aboard the transport".
:But I guess the problem is not what XComUtil does, but how to "communicate" back to the game engine that the soldiers are alive and well and not MIA? Surely the game's logic must be '''first''' to determine if the battle was aborted, and only then to decide who was left behind on the battlefield vs who died vs who was on the transport and got home? Surely Scott's logic must intercept this abort flag, and ''then un-set it''?.
:By the way, in the listing above I'm not sure whether the least significant bit is at the left or the right? [[User:Spike|Spike]] 20:31, 16 March 2010 (EDT)
:: I'm guessing it's a bitfield not a number, so LSB/MSB doesn't exist. [[User:Cesium|Cesium]] 21:27, 16 March 2010 (EDT)
::: Yes it's a bit field. I linked to the wiki page with the description. The game engine doesn't need to tell why some one got removed from the game. Tatical calculates the score. --[[User:BladeFireLight|BladeFireLight]] 21:38, 16 March 2010 (EDT)

:::: Thanks for clarifying. I had checked the links, read the bits your way, then had doubts as the description seems the other way round, ie Bit 1 at the end. So, do all 13 of my guys have this "on the ground" flag set? Very weird as none were stunned or dead. They were in smoke with minor stun damage is all. And moving the Sgt off the transport gains nothing, I just get 14 MIAs instead of 13. The wacky thing is the screen says Aliens Defeated and gives me loot - even when the transport is lost. [[User:Spike|Spike]] 22:36, 16 March 2010 (EDT)
:: Ok I have a solution I'm working on. Turns out those that bleed to death are being counted by Autocombat as being in play. Autocombat is not instantaneous, so Everyone with health <= wounds get health = 0 then all units with Health != 0 are marked as not dead.
::: Good to have a solution to the bleeding to death issue. Does that shed any light on how 14 non-wounded, non-bleeding, healthy, XCom controlled soldiers suddenly turn MIA at the end of a mission that is an XCom victory? Or is that a different issue?
::: By the way I checked my savegame, and if I move all the soldiers back to the transport prior to Abort Mission / AutoCombat, there are no MIAs any more after AutoCombat. So it sounds again like the situation is being handled like part victory (all aliens are dead, UFO Navigation loot) and part Abort. [[User:Spike|Spike]] 19:46, 17 March 2010 (EDT)
:::: They are both related.
::::* When you bleed to death your health never reaches 0. you are left alive with ~1-5 hit points, but marked as on the ground and tactical ups the KIA Score.
::::* When you are not in the craft on abort. Tactical marks you as on the ground and increases the MIA score.
::::* Geoscape looks at: If Health = 0, or if unit on the gorund (dead, unconscious, left behind) the units is removed from the game.
:::: To fix this I could not just mark everyone on the ground as standing (active) or the ones that already bleed to death are raised from the dead. So I check if Fatal wounds >= Health and then kill the unit by marking health to 0. then I can take the remainder of those that are not on the craft and mark them as active so Geoscape keeps them. I get the added bonus of not having bleed to death units calculated in autocombat as a + to X-Com's score, and autocombat would take at least one round so units one turn from death would die anyway. This is done as part of autocombat and not the standard MIA function that runs on every combat, as I dont want to kill off units that are truly alive. Yes they would probably die on the trip home. but I assume that the skyranger has a non man-portable trauma kit. --[[User:BladeFireLight|BladeFireLight]] 03:21, 18 March 2010 (EDT)

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

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

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

=== Categorise Config Options ===

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

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

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

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

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

* Dart Gun

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=== Focused Research Help ===

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

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

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

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

== Features for 9.8+ - New features ==

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

=== Improved Base Comes At Cost ===

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

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

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

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

=== AutoCombat ===

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

==== AutoWithdrawal ====

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

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

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

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

=== Tougher UFOs ===

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

=== Rebalanced Craft Weapons ===

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

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

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

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

==== Fusion Ball Launcher ====

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

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

==== Cost Based Approach ====

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

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

See [[User:Spike#Cost_Based_Rebalancing]]

==== Stat Based Approach ====

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

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

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

See [[User:Spike#Stat_Based_Rebalancing]]

=== Rebalanced Infantry Weapons ===

See [[User:Spike#Balancing_Infantry_Weapons]]

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

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

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

==See Also==

[[Wish List]]

= Completed Wish List Items =

=== BFG Default To Unchanged ===

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

= MISC =

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

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

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

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

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

Talk:XcomUtil

2010-03-18T07:22:08Z

BladeFireLight: /* Open Bugs */

=XcomUtil 9.7 Beta=

9.7 Beta is available on www.bladefirelight.com

==Release Notes==

This is a Beta, so backup your files before using. And check back often for newer builds.

New in this version.

*Major overhall of the installer (XcuSetup) and the inclusion of 16/32bit exe's to support both DOSBox and Windows Vista/7 x64.
*New subfolders added to hold supporting files making the install cleaner
*New XcuSetup command line arguments were added to XcuSetup allowing for silent install and uninstallation.
*New XcuSetup option for debugging the install (XcuSetup debug) creating XcomUtil\debug.txt.
*New command line argument "nobackup" skips backup only if it has been ran atleast once.
*XcuSetup can now have minimal impact on the game.
**Almost all options default to NO (Only Split Windows EXE set to Yes).
**Almost all changes are now prompted for (skyranger guns, interceptor as transport, Disjointed Base Bug, etc...).
***Items still done by default:
***Copy protection questions set to 0000000 for UFO 1.0-1.3 and X-Com 1.0
***Difficulty bug fixed in UFO 1.0-1.4 and X-Com 1.0-1.4
***Unique names for all maps in TFTD, Used for Hybrid Games
***Placement of X-Com Units on the Battlefield based on XcomUtil.cfg
***MIA Recovery on Won Combat (Units under mind\MC control when last controling alien killed are returned to X-Com control)
*XcomUtil.cfg is now pieced together and overwritten by XcuSetup (see XcomUtil\XcomUtil.txt for how to make permanent changes).
*All game files are restored to the pre-XcomUtil state each time XcuSetup is ran. Any modifications by other utilities will have to be re-applied.
*Vista/Win7 patch now an option for XcuSetup.
**This will fix the blank screen issue.
**Updated to support the split EXE.
**Will set X-Com to use CPU 0.
*XcuSetup attempts to fix UAC issues by resetting folder permissions.
*A number of community made fixes are included and selectable with XcuSetup.
*Support for the DOS/Window STEAM Install.
**Installer will detect STEAM and change steam launcher to start the XcomUtil Steam Menu (can be re-installed with XcomUtil\SteamSetup.bat
*Out of the box support for UFO Extender. XcuSetup will detect it and ask if you want RunXcom to use it.
*XcuSetup can be run from windows and RunXcom run from DosBox
*Hybrid Colors updated based on BombBloke's pallets.
*EQL flag allowed any turn.
*Add Xcom UFO Italian Support.
*Auto Combat will not run on second half of two part using first parts saved data.
*Auto Combat will no longer run if combat was won.
*MIA Recovery on won combat only.
*MIA Recovery no longer recovering units that bleed to death.
*Auto equip no longer triggers on second part of 2 stage missions.
*Combine clips skiped if between stages of 2-3 part missions.
*Updated f0dders ReadMe per his request. (XcomUtil\bugfix-readme.txt)
*Add-on support added. see XcomUtil\XcomUtil.txt and XcomUtil\Addon\Example.txt
*Prompted Terrain in BattleField Generator allows to abort or use of current setting.
*Beta versions include
**XcomUtil\XcomUtil.log includes lots of debug info
**XcomUtil\Debug.txt created by default (Release will need "debug" command argument)

Removed from this versions

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

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

===Build 435===

Original Sound Effects from UFO were re-sampled to work with 1.4 and CE.

*Add Category to option headers.
*Improve randomness by using current time instead of game date/time in srand()
*Added Option to keep Current terrain/UFO to BFG.
*Original UFO 1.2 Sounds for Geoscape and Tactical added as an option for UFO 1.4 and CE.
*Force Split EXE on STEAM. Fixes issues with setup failing.
*Reset Laser/Gauss craft weapons stats to be default.
*Example addon now uses different flag extension to avoid deletion by XcuSetup
*fix issue with Lab Screen on DosBox always screening

==Beta Discussion==

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

----

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

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

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

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

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

----

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

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

----

I have a strange issue. I succeed in an AutoCombat terror mission (117%) but the mission is resolved partially as if I had actually aborted the mission - all Civilians die, even though I could see 3-4 alive, my 13 soldiers outside the Skyranger go MIA, even the one who was killed by AutoCombat, and only my sergeant standing in the Skyranger makes it back. The problem is repeatable. On one occasion the sergeant was killed randomly by AutoCombat, meaning that the Skyranger flew back by itself, empty. Obviously this should never happen.

I've uploaded the [[Media:MIAoverload.zip|AutoCombat game save file]]. Incidentally this shows how to 'game' the current AutoCombat rules: Take maximum soldiers, no tanks. You give everyone a Rocket Launcher, they only need 1 Lg Rocket in it. Until you get Heavy Lasers, then replace the Rocket Launchers with them. Next replace with Heavy Plasmas. This approach always gives you maximum damage per soldier, and thus maximum chance of getting the +15 bonus for the W:3- rule. [[User:Spike|Spike]] 19:02, 15 March 2010 (EDT)

:: Hmmm. Scott's MIA recovery raised an army of undead from those that died of fatal wounds. Mine only effects mind controlled units. The issue is telling who is dead and who is left behind.

Units from your saved game looked like this(on by Autocombat).

Shuji Okabe: Left behind (Health > 0)
[[UNITPOS.DAT|UnitPos]][0x0A] 1.0.0.0.0.0.0.0 (bit 2 == 0 Unit on the ground[dead or unconscious])
[[UNITREF.DAT|UnitRef]][0x78] 0.0.0.0.0.0.1.0 (bit 1 == 0 Unit Alive)
Yoko Fujimoto: On Craft (Health > 0)
UnitPos[0x0A] 1.1.0.0.0.0.0.0 (bit 2 == 1 Unit Standing [Active])
UnitRef[0x78] 0.0.0.1.0.0.0.0 (bit 1 == 0 Unit Alive)

From Bomb Blokes undead army MIA Test save (won by killing aliens).

Spencer Bryant: Lived (Health > 0)
[[UNITPOS.DAT|UnitPos]][0x0A] 0.1.0.0.0.1.0.0 (bit 2 == 1 Unit Standing [Active])
[[UNITREF.DAT|UnitRef]][0x78] 0.1.0.0.0.0.0.1 (bit 1 == 0 Unit Alive)
Oscar Thompson: Bleed to death (Health > 0)
UnitPos[0x0A] 0.0.0.0.0.1.0.0 (bit 2 == 0 Unit on the ground[dead or unconscious])
UnitRef[0x78] 0.1.0.0.0.0.0.1 (bit 1 == 0 Unit Alive)
Virgil Hudson: Killed by Aliens (Health == 0)
UnitPos[0x0A] 0.0.0.0.0.1.0.0 (bit 2 == 0 Unit on the ground[dead or unconscious])
UnitRef[0x78] 1.1.0.0.0.0.0.1 (bit 1 == 1 Unit Dead)

So right now I'm at a loss of how to detect tell the difference between thoes that are left behind and thoes that are dead.

:There must be something odd about my save game that takes 13 live soldiers and makes them all MIA on an abort. I wonder if it is something to do with the one guy who is still on the transport. I'm sure I've never seen an MIA after an AutoCombat victory, or defeat, before. Of course, after a victory, no one should be MIA. In a defeat, in theory AutoCombat could (but doesn't?) allocate some soldiers as MIAs. For the bleeding to death problem, perhaps you could check whether Health <= Fatal Wounds. In the normal game this might be an ambiguous borderline case? Treat it unambiguously - kill any soldiers matching that condition. In XComUtil after-combat messages, perhaps emit the message "So-and-so died from his/her wounds aboard the transport".
:But I guess the problem is not what XComUtil does, but how to "communicate" back to the game engine that the soldiers are alive and well and not MIA? Surely the game's logic must be '''first''' to determine if the battle was aborted, and only then to decide who was left behind on the battlefield vs who died vs who was on the transport and got home? Surely Scott's logic must intercept this abort flag, and ''then un-set it''?.
:By the way, in the listing above I'm not sure whether the least significant bit is at the left or the right? [[User:Spike|Spike]] 20:31, 16 March 2010 (EDT)
:: I'm guessing it's a bitfield not a number, so LSB/MSB doesn't exist. [[User:Cesium|Cesium]] 21:27, 16 March 2010 (EDT)
::: Yes it's a bit field. I linked to the wiki page with the description. The game engine doesn't need to tell why some one got removed from the game. Tatical calculates the score. --[[User:BladeFireLight|BladeFireLight]] 21:38, 16 March 2010 (EDT)

:::: Thanks for clarifying. I had checked the links, read the bits your way, then had doubts as the description seems the other way round, ie Bit 1 at the end. So, do all 13 of my guys have this "on the ground" flag set? Very weird as none were stunned or dead. They were in smoke with minor stun damage is all. And moving the Sgt off the transport gains nothing, I just get 14 MIAs instead of 13. The wacky thing is the screen says Aliens Defeated and gives me loot - even when the transport is lost. [[User:Spike|Spike]] 22:36, 16 March 2010 (EDT)
:: Ok I have a solution I'm working on. Turns out those that bleed to death are being counted by Autocombat as being in play. Autocombat is not instantaneous, so Everyone with health <= wounds get health = 0 then all units with Health != 0 are marked as not dead.
::: Good to have a solution to the bleeding to death issue. Does that shed any light on how 14 non-wounded, non-bleeding, healthy, XCom controlled soldiers suddenly turn MIA at the end of a mission that is an XCom victory? Or is that a different issue?
::: By the way I checked my savegame, and if I move all the soldiers back to the transport prior to Abort Mission / AutoCombat, there are no MIAs any more after AutoCombat. So it sounds again like the situation is being handled like part victory (all aliens are dead, UFO Navigation loot) and part Abort. [[User:Spike|Spike]] 19:46, 17 March 2010 (EDT)
:::: They are both related.
::::* When you bleed to death your health never reaches 0. you are left alive with ~1-5 hit points, but marked as on the ground and tactical ups the DOA Score.
::::* When you are not in the craft on abort. Tactical marks you as on the ground and increases the MIA score.
::::* Geoscape looks at: If Health = 0, or if unit on the gorund (dead, unconscious, left behind) the units is removed from the game.
:::: To fix this I could not just mark everyone on the ground as standing (active) or the ones that already bleed to death are raised from the dead. So I check if Fatal wounds >= Health and then kill the unit by marking health to 0. then I can take the remainder of those that are not on the craft and mark them as active so Geoscape keeps them. I get the added bonus of not having bleed to death units calculated in autocombat as a + to X-Com's score, and autocombat would take at least one round so units one turn from death would die anyway. This is done as part of autocombat and not the standard MIA function that runs on every combat, as I dont want to kill off units that are truly alive. Yes they would probably die on the trip home. but I assume that the skyranger has a non man-portable trauma kit. --[[User:BladeFireLight|BladeFireLight]] 03:21, 18 March 2010 (EDT)

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

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

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

=== Categorise Config Options ===

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

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

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

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

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

* Dart Gun

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=== Focused Research Help ===

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

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

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

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

== Features for 9.8+ - New features ==

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

=== Improved Base Comes At Cost ===

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

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

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

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

=== AutoCombat ===

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

==== AutoWithdrawal ====

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

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

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

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

=== Tougher UFOs ===

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

=== Rebalanced Craft Weapons ===

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

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

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

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

==== Fusion Ball Launcher ====

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

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

==== Cost Based Approach ====

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

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

See [[User:Spike#Cost_Based_Rebalancing]]

==== Stat Based Approach ====

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

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

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

See [[User:Spike#Stat_Based_Rebalancing]]

=== Rebalanced Infantry Weapons ===

See [[User:Spike#Balancing_Infantry_Weapons]]

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

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

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

==See Also==

[[Wish List]]

= Completed Wish List Items =

=== BFG Default To Unchanged ===

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

= MISC =

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

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

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

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

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

Talk:XcomUtil

2010-03-18T07:21:20Z

BladeFireLight: /* Open Bugs */

=XcomUtil 9.7 Beta=

9.7 Beta is available on www.bladefirelight.com

==Release Notes==

This is a Beta, so backup your files before using. And check back often for newer builds.

New in this version.

*Major overhall of the installer (XcuSetup) and the inclusion of 16/32bit exe's to support both DOSBox and Windows Vista/7 x64.
*New subfolders added to hold supporting files making the install cleaner
*New XcuSetup command line arguments were added to XcuSetup allowing for silent install and uninstallation.
*New XcuSetup option for debugging the install (XcuSetup debug) creating XcomUtil\debug.txt.
*New command line argument "nobackup" skips backup only if it has been ran atleast once.
*XcuSetup can now have minimal impact on the game.
**Almost all options default to NO (Only Split Windows EXE set to Yes).
**Almost all changes are now prompted for (skyranger guns, interceptor as transport, Disjointed Base Bug, etc...).
***Items still done by default:
***Copy protection questions set to 0000000 for UFO 1.0-1.3 and X-Com 1.0
***Difficulty bug fixed in UFO 1.0-1.4 and X-Com 1.0-1.4
***Unique names for all maps in TFTD, Used for Hybrid Games
***Placement of X-Com Units on the Battlefield based on XcomUtil.cfg
***MIA Recovery on Won Combat (Units under mind\MC control when last controling alien killed are returned to X-Com control)
*XcomUtil.cfg is now pieced together and overwritten by XcuSetup (see XcomUtil\XcomUtil.txt for how to make permanent changes).
*All game files are restored to the pre-XcomUtil state each time XcuSetup is ran. Any modifications by other utilities will have to be re-applied.
*Vista/Win7 patch now an option for XcuSetup.
**This will fix the blank screen issue.
**Updated to support the split EXE.
**Will set X-Com to use CPU 0.
*XcuSetup attempts to fix UAC issues by resetting folder permissions.
*A number of community made fixes are included and selectable with XcuSetup.
*Support for the DOS/Window STEAM Install.
**Installer will detect STEAM and change steam launcher to start the XcomUtil Steam Menu (can be re-installed with XcomUtil\SteamSetup.bat
*Out of the box support for UFO Extender. XcuSetup will detect it and ask if you want RunXcom to use it.
*XcuSetup can be run from windows and RunXcom run from DosBox
*Hybrid Colors updated based on BombBloke's pallets.
*EQL flag allowed any turn.
*Add Xcom UFO Italian Support.
*Auto Combat will not run on second half of two part using first parts saved data.
*Auto Combat will no longer run if combat was won.
*MIA Recovery on won combat only.
*MIA Recovery no longer recovering units that bleed to death.
*Auto equip no longer triggers on second part of 2 stage missions.
*Combine clips skiped if between stages of 2-3 part missions.
*Updated f0dders ReadMe per his request. (XcomUtil\bugfix-readme.txt)
*Add-on support added. see XcomUtil\XcomUtil.txt and XcomUtil\Addon\Example.txt
*Prompted Terrain in BattleField Generator allows to abort or use of current setting.
*Beta versions include
**XcomUtil\XcomUtil.log includes lots of debug info
**XcomUtil\Debug.txt created by default (Release will need "debug" command argument)

Removed from this versions

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

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

===Build 435===

Original Sound Effects from UFO were re-sampled to work with 1.4 and CE.

*Add Category to option headers.
*Improve randomness by using current time instead of game date/time in srand()
*Added Option to keep Current terrain/UFO to BFG.
*Original UFO 1.2 Sounds for Geoscape and Tactical added as an option for UFO 1.4 and CE.
*Force Split EXE on STEAM. Fixes issues with setup failing.
*Reset Laser/Gauss craft weapons stats to be default.
*Example addon now uses different flag extension to avoid deletion by XcuSetup
*fix issue with Lab Screen on DosBox always screening

==Beta Discussion==

===Build 435===
: I hope the improved randomness doesn't apply to the Aliens' d100 during AutoCombat. Otherwise, one could load-scum for success. [[User:Cesium|Cesium]] 06:33, 11 March 2010 (EST)
:: Actually it does. I can see what your getting at, but why do it that way. if you want to win the "WIN" command line option is faster and you get better loot from the UFO. also using the combat date would also swing the other way with an unwindable autocombat with an fully loaded avenger vs a survey ship. --[[User:BladeFireLight|BladeFireLight]] 17:41, 11 March 2010 (EST)
: In the setup question for sound files: "were replace" should be "were replaced". [[User:Cesium|Cesium]] 06:53, 11 March 2010 (EST)

----

Excellent! For the first time xcusetup.bat completed for me in Dosbox in Ubuntu. Previously the SDUMP commands were hanging it.

For the first time ever, I ran the sound setup utility. It did not response to any cursor keys, enter, tab, etc. The only key that worked was Escape, and I'm not sure what this did.

One point on the xcusetup.bat script - Ctrl C does not seem to work. On all those "press a key to continue" prompts could we also have "or 'q' to quit"?

[[User:Spike|Spike]] 18:41, 13 March 2010 (EST)

: "press a key to continue" is the Pause command. Ctrl + C works fine in Windows. DOSBox does not. The reason for the use of Pause is because an number of new players kept exiting setup early when I gave the option. Aborting early makes a mess and I dont want to have to troubleshoot it for Joe user. --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
:: OK I see, that makes a lot of sense. [[User:Spike|Spike]] 06:52, 14 March 2010 (EDT)

----

Does the SHP flag still work, after the changes to how XCOMUTIL.CFG is assembled? I just tried it, after rerunning XCUSETUP.BAT (Dosbox 0.72 under Ubuntu). XCOMUTIL SHP produces no output. XCOMUTIL SHP:CFG WRT writes GEOSCAPE.EXE, but nothing seems to change. During XCUSETUP I see the expected "Patch applied, ship data updated from CFG" (or whatever). [[User:Spike|Spike]] 17:40, 16 March 2010 (EDT)
:: Yes it works fine. your mistyping the command. it's "xcomutil ufoexe shp:cfg wrt" Second argument must be the target folder. Line 42 and 1266 of XcommUtil.txt.
::: Thanks! And I thought I'd read the manual. [[User:Spike|Spike]] 20:31, 16 March 2010 (EDT)

==Open Bugs==
*There's no Italian text for the Alternate Laser Weapons option. Applying the patch seems to work, but it displays the text for the default laser weapons.
:*Anyone want to translate the text into Italian? --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
*The number of aliens in the mission report is inconsistent with the number of live aliens captured per research help. See [[Image:Alien_numbers_mismatch.zip]] and [[Image:Dead_alien_count.zip]].
* Morale is random at start of second stage after autocombat of first stage?
:* Actually Morale is used as the clip size and time units as the weapon damage. Don't ask me why. It would take a major re-write of auto combat to fix this. --[[User:BladeFireLight|BladeFireLight]] 19:34, 23 February 2010 (EST)
*RPL bug, when you turn creatures into Gill Men, they are reported as Snakemen
:* Reported how? Is this consistent? The name's used are from xcomutil.cfg. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
::*Sorry. It's reported in morale failure pop up messages. Though maybe this is an original TFTD bug rather than an XComUtil bug. [[User:Spike|Spike]] 19:21, 21 February 2010 (EST)
:::* See this: [http://www.youtube.com/watch?v=uGlSghf7aTU]. In that case, all Gill man (were lobster man before RPL) were reported as snakemen.. [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST)
*RPL bug, when you turn Lobstermen into other creatures (e.g. Gill Men), they are very hard to kill despite having the stats of the creature they turned in to. Possibly they are keeping their damage resistance? Maybe the race is stored in more than one place, for different purposes, and XComUtil misses one of these places?
:: I will look into this --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: The RPL only changes the basics; The race, rank, name, TimeUnits, Health, Energy, Reactions, Armor(front,back,left,right), Strenght and PSI Strenght. All other stats are left as-is. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
:::: I'm not so sure about this. See 05:00 mark at [http://www.youtube.com/watch?v=y-_zLdjhUHI]. The armour doesn't match the one Gill man should have (per UFOpaedia, at least). [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST). See also 04:17 mark at [http://www.youtube.com/watch?v=z5LfzFSkRnI] for reason to suspect resistances aren't always changed. It's possible he just was unlucky though... [[User:Cesium|Cesium]] 19:53, 21 February 2010 (EST)
::::: Actually the function is something like this
<pre>#define UpdateStat(x,y) pur->x = (unsigned char) \
( ( (unsigned int)pur->x \
* (unsigned int)pasTo->y \
) / (unsigned int)pasFrom->y )
UpdateStat( TimeUnits0, TimeUnits );
UpdateStat( Health0, Health );
UpdateStat( Energy0, Energy );
UpdateStat( Reactions0, Reactions );
UpdateStat( AFront0, AFront2 );
UpdateStat( ALeft0, ALeft2 );
UpdateStat( ARight0, ARight2 );
UpdateStat( ARear0, ARear2 );
UpdateStat( AUnder0, AUnder2 );
UpdateStat( Strength, Strength );
UpdateStat( PsiStrength, PsiStrength );
</pre>
::::: the 0's are values at start of tactical.
::::: I read that as Current(from game_x) * Target default(from xcomutil.cfg) / source default (from Xcomutil.cfg) so the stats will be different. --[[User:BladeFireLight|BladeFireLight]] 21:33, 21 February 2010 (EST)
:::::: I'd have expected Current(game_x) == Source default if applied on first turn? This would end up with result == Target default, no? Hmmm... We already saw some compiler multiplication wackiness with the research help bug. Possibly this affected these calculations too?
:::::: As for the code, you're not updating PsiSkill, so non Psi-users can't get Psi after RPL. [[User:Cesium|Cesium]] 22:03, 21 February 2010 (EST)
::::::: I didn't write this. I'm amusing Scott did it this way to adjust for difficulty because XcomUtil.cfg has the beginner level stats. It need's an overhaul to use the full stat entries including the unknowns adjusted correctly for the level. Something for latter. --[[User:BladeFireLight|BladeFireLight]] 22:09, 21 February 2010 (EST)
:::::::: For this specific issue I think you will need to update 0x37 of [[UNITREF.DAT]] which is the Damage Modifier. For the general problem you will need to update the Psi Strength and also Firing Accuracy, energy regen rate, movement class... loads of stuff. And of course LOFTEMPS. So with current RPL not changing LOFTEMPS, changed aliens are the wrong size and shape probably. This would be visible using the LOFTEMPS map viewer I suppose. [[User:Spike|Spike]] 18:39, 9 March 2010 (EST)
*[[Known Bugs#XComUtil Inventory Stacking Bug]]
:* I hope to overcome this but Scott's notes point to a technical limitation. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*Fusion Ball Launcher fixes - detailed discussion moved to [[Talk:Fusion_Ball_Launcher#XComUtil_FBL_Issues]]
** Profitability (inconsistency item) - becomes most profitable item when using Alternate Laser (and Plasma) Tech option. Recommendation - workshop space and Engineer hours x10, 4 Alloys, 20 Elerium. And make it more useful (see below).
** Usefulness ''(wish list item)'' - perceived as being not very useful with standard stats. Recommendation - increase ammo to 3. Leave damage as-is to allow for Tougher UFOs (see Wish List).
*Zrbite lying around in odd places. Objects lying around in odd places in general - these are map modifying errors, probably only occur when customising terrain etc.
:: Will be part of an overhaul of the BFG --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*There is a small problem in editing/customising craft using '''XComUtil.cfg'''. Certain X-Com craft weapon values - the rate of fire value - can't be set. Or more specifically, they can be set (patched) in the executable but it has no effect in the game. To avoid confusion they should perhaps be removed from the format of custom craft, or commented out. (This rate of fire patching ''might'' work on UFOs, haven't tested it).
:: Can you be more specific? --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: There is a section in '''xcomutil.cfg''' which is used for patching XCom craft weapon characteristics. This is where Scott changed values for the Laser Cannon, etc. Probably very few people use these fields. I only used them because I was doing research into the game mechanics. One of the values changed in this section is the reload time. These values are present in the executable, and can be patched, but patching them has no effect (other than to change the UFOPaedia entry). The reload time seems to be hard coded elsewhere in the executable, based (broadly) on the class of weapon. So you might want to comment this column with an a note saying "cannot be modified for combat". On the other hand I could be wrong, or someone still might want to modify these fields. Discussion is at [[Talk:UFO_Interception#Observed_Rates_of_Fire]]. Offsets are at [[Talk:GEOSCAPE.EXE#Craft_weapon_stats]]. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
:::: Or maybe change these display-only values so that they reflect the [[Talk:UFO_Interception#Observed_Rates_of_Fire|observed reload rates]]? I am not yet 100% sure I have got these right, might want to wait until I do some more confirmation tests. [[User:Spike|Spike]] 15:26, 22 February 2010 (EST)
*EQL only works on turn 1 (see discussion above)
::: Added to my to do list. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*Research Help from Captured Aliens awards research help without checking first if you have Alien Containment at the base of origin. Resulting in dead aliens helping you with your enquiries! Possibly only applies to AutoCombat? [[User:Spike|Spike]] 21:05, 14 March 2010 (EDT)
:: Ideally it would not only check for containment but also have a research item for it and check on how many scientist days had been reduced since the last combat and use that as a value for how much you get form the aliens still in containment. But that could just be a pipe dream. Checking for containment for now is a good idea. --[[User:BladeFireLight|BladeFireLight]] 15:35, 16 March 2010 (EDT)

----

I have a strange issue. I succeed in an AutoCombat terror mission (117%) but the mission is resolved partially as if I had actually aborted the mission - all Civilians die, even though I could see 3-4 alive, my 13 soldiers outside the Skyranger go MIA, even the one who was killed by AutoCombat, and only my sergeant standing in the Skyranger makes it back. The problem is repeatable. On one occasion the sergeant was killed randomly by AutoCombat, meaning that the Skyranger flew back by itself, empty. Obviously this should never happen.

I've uploaded the [[Media:MIAoverload.zip|AutoCombat game save file]]. Incidentally this shows how to 'game' the current AutoCombat rules: Take maximum soldiers, no tanks. You give everyone a Rocket Launcher, they only need 1 Lg Rocket in it. Until you get Heavy Lasers, then replace the Rocket Launchers with them. Next replace with Heavy Plasmas. This approach always gives you maximum damage per soldier, and thus maximum chance of getting the +15 bonus for the W:3- rule. [[User:Spike|Spike]] 19:02, 15 March 2010 (EDT)

:: Hmmm. Scott's MIA recovery raised an army of undead from those that died of fatal wounds. Mine only effects mind controlled units. The issue is telling who is dead and who is left behind.

Units from your saved game looked like this(on by Autocombat).

Shuji Okabe: Left behind (Health > 0)
[[UNITPOS.DAT|UnitPos]][0x0A] 1.0.0.0.0.0.0.0 (bit 2 == 0 Unit on the ground[dead or unconscious])
[[UNITREF.DAT|UnitRef]][0x78] 0.0.0.0.0.0.1.0 (bit 1 == 0 Unit Alive)
Yoko Fujimoto: On Craft (Health > 0)
UnitPos[0x0A] 1.1.0.0.0.0.0.0 (bit 2 == 1 Unit Standing [Active])
UnitRef[0x78] 0.0.0.1.0.0.0.0 (bit 1 == 0 Unit Alive)

From Bomb Blokes undead army MIA Test save (won by killing aliens).

Spencer Bryant: Lived (Health > 0)
[[UNITPOS.DAT|UnitPos]][0x0A] 0.1.0.0.0.1.0.0 (bit 2 == 1 Unit Standing [Active])
[[UNITREF.DAT|UnitRef]][0x78] 0.1.0.0.0.0.0.1 (bit 1 == 0 Unit Alive)
Oscar Thompson: Bleed to death (Health > 0)
UnitPos[0x0A] 0.0.0.0.0.1.0.0 (bit 2 == 0 Unit on the ground[dead or unconscious])
UnitRef[0x78] 0.1.0.0.0.0.0.1 (bit 1 == 0 Unit Alive)
Virgil Hudson: Killed by Aliens (Health == 0)
UnitPos[0x0A] 0.0.0.0.0.1.0.0 (bit 2 == 0 Unit on the ground[dead or unconscious])
UnitRef[0x78] 1.1.0.0.0.0.0.1 (bit 1 == 1 Unit Dead)

So right now I'm at a loss of how to detect tell the difference between thoes that are left behind and thoes that are dead.

:There must be something odd about my save game that takes 13 live soldiers and makes them all MIA on an abort. I wonder if it is something to do with the one guy who is still on the transport. I'm sure I've never seen an MIA after an AutoCombat victory, or defeat, before. Of course, after a victory, no one should be MIA. In a defeat, in theory AutoCombat could (but doesn't?) allocate some soldiers as MIAs. For the bleeding to death problem, perhaps you could check whether Health <= Fatal Wounds. In the normal game this might be an ambiguous borderline case? Treat it unambiguously - kill any soldiers matching that condition. In XComUtil after-combat messages, perhaps emit the message "So-and-so died from his/her wounds aboard the transport".
:But I guess the problem is not what XComUtil does, but how to "communicate" back to the game engine that the soldiers are alive and well and not MIA? Surely the game's logic must be '''first''' to determine if the battle was aborted, and only then to decide who was left behind on the battlefield vs who died vs who was on the transport and got home? Surely Scott's logic must intercept this abort flag, and ''then un-set it''?.
:By the way, in the listing above I'm not sure whether the least significant bit is at the left or the right? [[User:Spike|Spike]] 20:31, 16 March 2010 (EDT)
:: I'm guessing it's a bitfield not a number, so LSB/MSB doesn't exist. [[User:Cesium|Cesium]] 21:27, 16 March 2010 (EDT)
::: Yes it's a bit field. I linked to the wiki page with the description. The game engine doesn't need to tell why some one got removed from the game. Tatical calculates the score. --[[User:BladeFireLight|BladeFireLight]] 21:38, 16 March 2010 (EDT)

:::: Thanks for clarifying. I had checked the links, read the bits your way, then had doubts as the description seems the other way round, ie Bit 1 at the end. So, do all 13 of my guys have this "on the ground" flag set? Very weird as none were stunned or dead. They were in smoke with minor stun damage is all. And moving the Sgt off the transport gains nothing, I just get 14 MIAs instead of 13. The wacky thing is the screen says Aliens Defeated and gives me loot - even when the transport is lost. [[User:Spike|Spike]] 22:36, 16 March 2010 (EDT)
:: Ok I have a solution I'm working on. Turns out those that bleed to death are being counted by Autocombat as being in play. Autocombat is not instantaneous, so Everyone with health <= wounds get health = 0 then all units with Health != 0 are marked as not dead.
::: Good to have a solution to the bleeding to death issue. Does that shed any light on how 14 non-wounded, non-bleeding, healthy, XCom controlled soldiers suddenly turn MIA at the end of a mission that is an XCom victory? Or is that a different issue?
::: By the way I checked my savegame, and if I move all the soldiers back to the transport prior to Abort Mission / AutoCombat, there are no MIAs any more after AutoCombat. So it sounds again like the situation is being handled like part victory (all aliens are dead, UFO Navigation loot) and part Abort. [[User:Spike|Spike]] 19:46, 17 March 2010 (EDT)
:::: They are both related.
::::* When you bleed to death you health never reaches 0. you are left alive with ~1-5 hit points, but marked as on the ground and tactical ups the DOA Score.
::::* When you are not in the craft on abort. Tactical marks you as on the ground and increases the MIA score.
::::* Geoscape looks at: If Health = 0, or if unit on the gorund (dead, unconscious, left behind) the units is removed from the game.
::: To fix this I could not just mark everyone on the ground as standing (active) or the ones that already bleed to death are raised from the dead. So I check if Fatal wounds >= Health and then kill the unit by marking health to 0. then I can take the remainder of those that are not on the craft and mark them as active so Geoscape keeps them. I get the added bonus of not having bleed to death units calculated in autocombat as a + to X-Com's score, and autocombat would take at least one round so units one turn from death would die anyway. This is done as part of autocombat and not the standard MIA function that runs on every combat, as I dont want to kill off units that are truly alive. Yes they would probably die on the trip home. but I assume that the skyranger has a non man-portable trauma kit. --[[User:BladeFireLight|BladeFireLight]] 03:21, 18 March 2010 (EDT)

==Fixed Bugs==
*don't prevent patching windows version while running in dosbox, or vice versa
:*Fixed: XcuSetup can be run independently to the OS RunXcom is used in.
*4DOS and MS-DOS 5 dont like "-" in variable names.
:*Fixed
*Enviroment space reached quickly on most DOS environments.
:*Partly Fixed: Requirement has been drastically reduced to to ~1024 use of Command.com /e:xxxx still may be required
*EnvClean.bat has an error in line 172: ser -> set.
:* Fixed in build 204.
*ANSI escape sequences aren't necessarily supported on a real dos environment/emulation
:*Fixed: ANSI only used in DOSBox
*If all the aliens are down (some of them stunned), the last save is named "AutoCombat" and I end turn, XcomUtil may still run "AutoCombat" phase. This may have slightly different results than end of combat would have had
:*Fixed: Autocombat will not run if you have already won.
*A fully loaded Hammerhead's initial deployment has three aquanauts outside the craft.
:*Fixed: the unit placement for the default 12 unit craft has been added to XcomUtil.cfg
*Select terrain: doesn't appear until after I select a terrain in BFG prompting
:*Fixed
*geodata/obdata.dat gets truncated with selecting any improved weapon.
:*Fixed: This happens because a full backup did not complete but XcuSetup does not detect it. Backup script's changed to avoid xcopy timeout on some versions of DOS. (Backups are required by SDUMP to apply patches)
*I get this error during backup "16-bit MS-DOS Subsystem NTVDM has encountered a System Error The handle is invalid."
:*Fixed: All NT based OS's now using 32bit EXE's
* You can get X-COM MIA if you abort a mission, even if everyone is in the exit. Possibly a second stage bug only? See [[Image:X-COM_MIA.zip]]. Note that this only affects the report - after mission all the X-COM troops are still available.
:*NOT Fixed: This happens even on vanilla TFTD with that save. Given it's TFTD it could be an issue with the mapfiles. --[[User:BladeFireLight|BladeFireLight]] 00:23, 24 February 2010 (EST)
*Various second stage bugs - ammo clip recovery, crashes after autocombat of first stage, etc. Mainly for TFTD, but possibly Cydonia in UFO is also affected.
:*Fixed: Clip recovery no longer ran between parts of 2-3 part missions. Autocombat only crashes on two part if you are aborting the second stage and the save in slot 10 is from the first stage. Stage comparisons are now done to abort autocombat if you do this.
*Removal of Small Scout map / Survey Ship map, making it impossible to do these Battlescape missions.
:*Fixed: 9.7 only removes the maps if you use the BFG. I hope to have 9.8 not remove them at all. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*The XcuSetup prompt for the option of less-profitable weapons manufacturing is misleadingly called "new laser weapons".
:*Fixed: Renamed to Alternate Lasor weapons.
* SteamSetup.bat won't run from DOSBox. It says "This needs to be run from Windows". Though, does it make any sense to run SteamSetup.bat under DOSBox (eg for a linux system with no Steam)? [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
:*NOT Fixed: STEAM doesnt give access by default to the command prompt. If you know how to add that then you should know enough of DOS not to need the STEAM menu. --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
* '''cfg/ShipDefU.txt''' has the XCU values for improved Laser Cannon (35/35/35), not the original values (21/35/70). Is this correct - is this file supposed to be the original defaults? [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)
:*Fixed: I was unaware that this had been changed. The weapons are not prompted for any change so they should not be changed. I'm reseting them all to defaults and looking to see if Scott had anything about them in the notes. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
* standalone patches the fix the difficulty bug
:*Partialy Fixed: 9.7 min install is the difficulty patch and changing Copy protection questions to all 0's.
*Version detection issues with obscure versions (Italian, 1.2a, etc.) causing corruption or lack of patching.
:*Fixed: Added support and patching offsets.
*Various default options make the game easier, not harder (''harder'' being the intent of XComUtil, right?). These should not be defaults. (More discussion at [[Talk:Enemy_Unknown_Extended#Standard_Config_Discussions]]) E.g.
::: 9.7 only has 3 items on by default. Remove copy protection. Fix Difficulty bug and Split EXE (split EXE can be skipped but not the others). All other options are default to NO.
::: As for the intent of XcomUtil. Scott added features to
:::# Increase difficulty.
:::# Make useless items useful.
:::# Get the game Started faster.
::: I have added:
:::# Don't make unwanted changes.
:::# Fix game bugs
:::::Yes all of those are very sensible. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
::::Latter versions of XcomUtil will turn the last two forced items to prompted. with only the Difficulty bug and the split EXE as Default=Yes. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Basic tanks using advanced tank stats
**Improved High Explosive - very powerful in favour of X-Com, especially as alien spawn points and routes aren't set up to cover holes in UFO hulls.
:*Gauss weapons have infinite ammo
::: 9.7 has a second option to just the increase power to closer match UFO.
:*Using fighters as transports (carrying soldiers)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Using transports as fighters (weapon hardpoints)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Improved Heavy Laser / Heavy Gauss. OK, this should maybe be a ''recommended'' option since the unpatched weapons are nearly pointless. But, it does make the game easier. [[User:Spike|Spike]] 20:12, 7 February 2010 (EST)
*FreeDOS breaks horribly during Setup
:*This is most likely an issue with the limits of FreeDOS.
:** Actually, this seems to work well for the latest builds (tested with FreeCOM 0.84 under dosemu). [[User:Cesium|Cesium]] 18:07, 14 March 2010 (EDT)

=XComUtil Wish List=
Things that are not bugs or inconsistencies in XComUtil but would be Nice To Have

== Features for 9.7 - Interface, consistency and bug fixes ==

=== Categorise Config Options ===

For each option, in the prompt, note which category of option this is, according your list above. E.g. faster start, making the game harder, making useless items useful, bug fix, variant game, etc. [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)

:Actually it might be even better to organise the options questions into sections, thematically grouped by these categories. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

:: Items are currently sorted like this.
* Windows EXE
* Game Fixes
* Game Mods
** Sound
** Craft
** Base
** Equipment
** Research
** Units
** Battlefield
** Alien Craft
** Misc
--[[User:BladeFireLight|BladeFireLight]] 19:25, 10 March 2010 (EST)

=== Improved Pistol Modification ===
*Remove 3rd burst for Pistol
Detailed discussion moved to [[Talk:Pistol#XComUtil_Burst_Mode_Pistol]] to de-clutter this page. Summarised recommendations will be posted back here based on whatever consensus emerges.

Current recommendation: Reduce auto accuracy from 60% to 20%, with the same TUs (54%).When prompting, point out that no improvements are required to the Pistol to make it useful. [[User:Spike|Spike]] 08:12, 14 March 2010 (EDT)

* Dart Gun

On the other hand, the Dart Gun really is useless, even as a last ditch personal defence weapon. Auto mode, with very low accuracy (10%?), would at least give it some value as a defensive sidearm for medics, heavy weapons troops, etc. Scouts and others carrying a scanner or grenade in the other hand would still be better off using a Jet Harpoon, or even an AP HydroJet Cannon, one-handed. [[User:Spike|Spike]] 03:47, 16 March 2010 (EDT)

=== Fusion weapons inconsistently exempted from Alternate Laser Tech ===
* Fusion weapons inconsistently exempted from the "more difficult" energy weapons manufacturing option ("alternate laser Tech"). Blaster Bombs and Blaster Launchers, Fusion hovertanks and ammo, and Fusion Balls and Fusion Ball Launchers - none of these are harder to build or use with the "alternate Tech" option. Why make laser weapons/tanks and plasma weapons/tanks harder but not Fusion weapons? It's not consistent. I wonder if Scott didn't look at these because he never used Blaster Launchers or Fusion Hovertanks, as he considered them to unbalancing already? And ignored FBLs because, well, most people ignore them? But this should be consistent. Or, the "harder weapons" option could be broken down into sub options, e.g. for each weapon technology:
** Much more expensive (typically: add some exotic materials, 10x workshop space and 10x Engineer hours)
** Can/can't manufacture the battlescape weapons/tanks (pure alien weapons only)
** Can/can't manufacture the ammo (pure alien weapons only)
:Personally I would prefer it to be all-or-nothing but include the Fusion weapons as being more difficult to make and use. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
* In the meantime (ahead of introducing any changes), maybe change the prompt to "Alternate Laser and Plasma Tech"/"Alternate Gauss and Sonic Tech", and/or point out explicitly that the changes don't affect any Fusion/Blaster/Pulse Wave weapons. [[User:Spike|Spike]] 08:15, 14 March 2010 (EDT)

=== AutoCombat issues ===
* All Civilians are dead if AutoCombat is used to end a Terror mission. It's too not much of a problem, since score is likely to be positive anyway. It would possibly be an improvement to assume all civs from first stage are dead (if ran at second stage) and get a random number (using mission seed) for dead civs at current stage? [[User:Cesium|Cesium]] 07:00, 22 February 2010 (EST)
:* This is odd. Autocombat is supposed to skip over civilians when using the kill function. --[[User:BladeFireLight|BladeFireLight]] 00:18, 24 February 2010 (EST)
::*Maybe kill civilians (or not) according to the force ratios. If XCom has only enough force to win the mission, all Civilians are dead. If XCom bring a certain amount of "excessive force", all or nearly all Civilians are saved. By the way I love AutoCombat, it is great for avoiding repetitive combat and only playing the new, interesting bits. [[User:Spike|Spike]] 15:53, 22 February 2010 (EST)
:::* Thinking about this, I recalled the scenario where someone fights the mission and uses AutoCombat to hunt the last aliens (another reason AutoCombat is great). Spike's suggestion is better from pure RNG, since in this case probably all civs that were at risk already died. So lets see what we suggest XcomUtil do:
:::# Count civs from first stage if there was one as dead (since IIRC XcomUtil has no memory of first stage when exiting second stage, so we can't take them into account?).
:::# Deduct dead civs from current stage.
:::# Calculate extra dead civs using force ratio to bias the RNG (I prefer merely biasing the RNG rather than precluding results, since Xcom in general has a large variance in almost every gameplay mechanic). [[User:Cesium|Cesium]] 18:27, 22 February 2010 (EST)
* Day vs Night
** The Day/night algorithm breaks. For example, at any point when XCom has more than twice as many flare-carrying soldiers than there are remaining aliens, XCom is actually ''stronger'' in darkness than it would be in full daylight. Toward the end of a battle this is a very common situation. But fixing the algorithm is tricky. What might work is to give -10 for each Soldier in darkness, reduce from -20 to -10 for each Alien in darkness, then add back +10 for every soldier with a light source. Thus there is no way XCom can go 'net positive' from light sources.
:: If you have more units then they do you can see more of the battle field. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:::It never makes sense for XCom to be stronger at night, than during the day, for the same force ratio. But that is what happens. An example. 10 XCom soldiers with flares and 3 aliens. At night there is an extra -30 modifier for the aliens, but a +100 modifier for XCom, net +70. The same 10 soldiers against the same 3 aliens are +70 ''more'' effective in darkness than they would be in daylight. It does not make any sense. [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
** The definition of a light source should be expanded to include a Flare ''or'' an Incendiary weapon. In fact, one Incendiary-capable weapon of any type (AC/HC/HjC/GC), with appropriate Incendiary rounds carried, should be enough for the entire squad to be considered as having a light source. But this may be hard to implement without a special flag and a special pre-search for a valid Incendiary weapon, since AutoCombat normally scores by individual soldiers, not by whole squads.
:: This would take a rewrite. currently the ammo is not used by W: --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
** To be honest I would prefer that each soldier without a light source in darkness is 50% effective, each soldier with a light source (personal or squad), is 75% effective. Meanwhile how about this:

//Darkness - Tested OK (except IN Rkt)
-10 L:-9 u:-2 // Human in Darkness

+10 L:-9 u:-2 W:-27 U:- // Human in Darkness w/Flare -OR-
+10 L:-9 u:-2 W:-4 W:-7 U:- // Human in Darkness w/In ammo and launcher HC/GC-IN -OR-
+10 L:-9 u:-2 W:-8 W:-11 U:- // Human in Darkness w/In ammo and launcher AC/HjC-IN -OR-
+10 L:-9 u:-2 W:-12 W:-15 U:- // Human in Darkness w/In ammo and launcher IN Rkt/Torp

-10 L:-9 u:4-14 // Alien in Darkness

:: Only thing I see is that this ''must'' come at the end. The U:- removes the unit from further consideration. --[[User:BladeFireLight|BladeFireLight]] 19:58, 9 March 2010 (EST)
::: Yes, to use the U: flag for this "OR" function, it must come at the end of the section for humans. That's how I have it my updated AutCombt.txt, these fragments are a bit out of context. It's not critical to have the "OR", it's just nice-to-have as it stops someone cheating by having a flare and one of each loaded incendiary launcher weapon in each hand and in their backpack, to get quadruple score. But hopefully people are unlikely to cheat at AutoCombat, there are easier ways such as the WIN flag. [[User:Spike|Spike]] 20:39, 9 March 2010 (EST)
* The Zombie is rated the same as a tank, a Chrysallid/Tentaculat or an effective Psi alien (-50). I think this is too high, as Zombies are much weaker than those units. A Zombie should be maybe -25.
: Disagree. the zombie should be slightly higher then a Chrysallid/Tentaculat as it will become one and you have to kill it twice. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:: OK good point! [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
* Area effect weapons (HE, IN, Small Launcher) should have at least the same bonus as effective-on-Auto weapons (+5). This is because they can damage/kill multiple targets. (The AC/HjC should not get both bonuses however.)

//Area Weapons. To be Tested. These values are probably too high.
//NB we are not indicating damage here, that is already calculated by the "effective" function. we are just
//factoring in the possibility of hitting multiple targets because of the area effect
//ToDo: needs compensating bonus for aliens (grenades?). should not be cumulative on the same unit.
//Also: add check if weapon is "effective" (at GZ) ?
+25 u:-2 W:-40 W:-41 //U: // Human w/ Blaster/DP Launcher and ammo
+10 u:-2 W:-12 W:-13 //U: // Human w/HE ammo and launcher Sm HE Rkt/Torp
+10 u:-2 W:-12 W:-13 //U: // Human w/HE ammo and launcher Lg HE Rkt/Torp
+10 u:-2 W:-42 W:-43 //U: // Human w/ Stun/Shok Launcher and ammo
+5 u:-2 W:-4 W:-6 //U: // Human w/HE ammo and launcher HC/GC-HE
+5 u:-2 W:-8 W:-10 //U: // Human w/HE ammo and launcher AC/HjC-HE

-25 u:4-14 W:-40 W:-41 //U: // Alien w/ Blaster/DP Launcher and ammo
-10 u:4-14 W:-42 W:-43 //U: // Alien w/ Stun/Shok Launcher and ammo

::Having tested the HC and AC rules, the first rule (HC-HE) does not work unless you remove the ammo specifier W:-6, making it just a test for an HC. But weirdly the second rule (AC-HE) works fine with its ammo specifier in place. Odd. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
::: The problem was due to [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Ammo loaded into a weapon by the game automatically prior to the equip phase is not caught by the W: function. When the ammo is loaded manually, both rules works fine. [[User:Spike|Spike]] 18:16, 13 March 2010 (EST)

* Pistols with the burst mode option should not count as Auto weapons (maybe they don't).
: Burst and snap are based on default stats --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
* Blaster Launchers / DPLs (with ammo) should be worth as much as a tank, e.g. +/- 50 (including the single shot effective bonus it should already get - see suggested rule above under area weapons)
* Should distinguish between tanks. Even with improved armour, a Tank/Cannon is not the same as a Fusion Hovertank. I would suggest a range of 25 for a Tank/Cannon to 75 for a Hovertank/Fusion. Maybe 40 for a Tank/Rocket, 50 for Tank/Laser, 60 for a Hovertank/Plasma?
:This does not seem to be possible with the existing ruleset as all Tanks are unit type 3
::Hmm, byte 42 of [[UNITREF.DAT]] is Rank but also Tank chassis. So this ''might'' allow distinguishing tracked tanks from hover tanks, at least. An alternative approach would be to pick some stat (that has a StatStrings statid) and set it to a different unique value for each tank type. [[User:Spike|Spike]] 18:32, 9 March 2010 (EST)
::This rule set might work:

// Tanks - distinguish chassis types. To be tested
+40 u:3-3 R:0-0 // Tank, Tracked (Cannon, Rocket, Laser)//To Test
+60 u:3-3 R:1-1 // Tank, Hover (Plasma, Fusion) //To Test

* Flying units (either side) should be worth say +/- 5
:Not possible for XCom as no statid makes a distinction between Power Suit and Flying Suit. Would be possible for aliens eg:

-1 T:0- u:6-6 // Flying Alien - Ethereal
-1 T:0- u:8-8 // Flying Alien - Floater
-1 T:1- u:13-13 // "Flying" Alien - Hallucinoid
-1 T:1- u:11-11 // "Flying" Alien - Tentaculat

::On reflection flying is hardly any advantage for aliens, it usually just makes them easier targets with no cover. I guess it helps with avoiding HE splash. [[User:Spike|Spike]] 20:57, 16 March 2010 (EDT)

* If the squad is carrying some Smoke or Dye that should be worth maybe +5 - +10. But since the aliens don't ever carry that, you need some balancing factor for them.

+1 u:-2 W:-20 // +1 per human with smoke grenade(s) (not +1 per grenade!) //Tested OK

* Effective melee weapons should be counted. This is particularly important in TFTD when ranged weapons may be ineffective, e.g. vs Lobstermen.
* Similarly if the enemy are in heavy armour and therefore a soldier/alien does not have an effective weapon, any HE Pack / Alien Grenade / Sonic Pulser should be counted for something (if it is "effective").

//Melee weapons
+5 u:-2 W:1- W:-26 // Human w/o effective ranged weapon but w/ Stun Rod
<s>+5 u:-2 W:3-26 // Human w/ effective Stun Rod (cumulative to above)</s>

::The second rule doesn't work at all, it looks like it counts all items of types 3-6. The "superiority" function (first value before the hyphen) does not seem to operate, probably because it is a melee weapon. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
::: did you try W:255-26 ? not that I know if it would work. AutoCombat doesn't recognize stun rods as weapons when applying damage.--[[User:BladeFireLight|BladeFireLight]] 21:01, 9 March 2010 (EST)
:::: OK, if AutoCombat rates stun rods as doing no damage, the lower range of the W: function ("superiority") will likely never work. So we can't tell whether or not a Stun Rod is "effective" vs the current enemy. In general, the Stun Rod is a pretty effective weapon. So instead we generalise and just use something like this rule set:

//Melee weapons
+3 u:-2 W:1- W:-26 // Human w/o effective ranged weapon but w/ Stun Rod //Tested OK
+3 u:-2 W:-26 // Human w/ effective Stun Rod (cumulative to above) //Tested OK

//It would be nice if AutoCombat checked for the presence of Stun Rods and used them to increase the chance of an alien casualty being stunned rather than killed.

//To Do: check if TFTD melee weapons are included in "effective" weapons by the W: statid.

//Grenades (this needs to be an OR block, so it's not cumulative for each grenade type)
+2 u:-2 W:1- W:-44 // Human w/o effective ranged weapon but w/ effective Alien grenade(s)
+2 u:-2 W:1- W:-22 // Human w/o effective ranged weapon but w/ effective HE pack(s)
+2 u:-2 W:1- W:-21 // Human w/o effective ranged weapon but w/ effective prox grenade(s)
+2 u:-2 W:1- W:-19 // Human w/o effective ranged weapon but w/ effective grenade(s)

-5 u:4-14 W:3-44 // -5 per Alien with effective Alien Grenade(s) (not -5 per grenade!)
:: Only one per unit. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)
::: One per unit tested ok too! [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
* AutoCombat victories should award all UFO Components, not just some Navigation, Elerium and Alloys.
* Every Civilian on the map should be a penalty to XCom of maybe -5, due to the distraction effects of trying to save them / avoid killing them.

-5 u:15-16 U:- // Civilian distraction effect, no further effect //Tested OK

Let me know if I should try to work some of this up as AutoCombat rules. Some of it requires new coding of course, but a lot of it could probably be done with existing rules. [[User:Spike|Spike]] 13:15, 7 March 2010 (EST)
: I dont plan on any changing to the underlying code yet. Your welcome to make up a new set of rules and testing them out. --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
:: OK added some rules above. I have not tested them yet, some of the syntax might not work. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)
::: Syntax looks good to me. Give them a test and let me know how they go.
::: Just a quick note on how AutoCombat works. First the success percent chance is calculated using the AutoCombat StatStrings, dead and unconscious units dont count. (those that bleed to death are considers alive, need to fix this). If it's below AbortThreshold it aborts. If it's 100-199 then change to 90. 200+ change to 95 (success is never a guarantee.) Aliens roll d100, if over your success chance you lose. If You win. Then average damage by each side is calculated based on Loaded weapon being carried and time units. All aliens are killed or stunned by X-Com unit chosen at random. Each Alien gets a chance to wound an X-Com unit based on Success Percentage. Randomly choose unit using random damage (max is average alien damage) Leave at least one X-Com Unit alive. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)

* It would be nice, in a future version of AutoCombat, to have some way of ORing rules together. Using the U: construct as a 'break' only allows you to have one single OR block per unit type (I think). [[User:Spike|Spike]] 20:57, 16 March 2010 (EDT)

* The battle report screen after AutoCombat does not report the number of Alien Artefacts recovered. This gives score I believe. Is it because it's hard to populate whatever data structure the game reads in order to generate the Artefact count? As I understand it, anything you haven't yet researched is an Artefact, and awards some score for recovering it. Anyway, fixing this would be nice-to-have. [[User:Spike|Spike]] 20:57, 16 March 2010 (EDT)

* It would be nice to compensate for the [[Known_Bugs#Equip_Phase_Ammo_Load_Error|Equip Phase Ammo Load Bug]] [[User:Spike|Spike]] 20:57, 16 March 2010 (EDT)

=== Focused Research Help ===

There is a minor and probably unintended consequence of Research Help from Captured Aliens. Normally when you capture a new alien artefact that opens up a new research project, you start the research project - typically with 0 Scientists - and then immediately sell the artefact. The problem with this for Research Help is that you soon have a huge number of projects underway. Then any Research Help tends to get very widely dispersed across all active projects (since it always goes to the project where the biggest reduction can be made, i.e. the projects furthest from completion). The result is that projects are completed only rarely, and progress is made on a broad front but without delivering much. Currently, to avoid this, it is necessary to keep single alien artefacts around in Stores, waiting for the time when the project they open up becomes a priority. In a way, this is interesting and challenging. In another way, it is a headache and take away vital cash.

You might argue that the trick above is a kind of exploit and should not be done. I don't know, maybe. But it is a common practice.

A solution, hopefully fairly easy to implement, is to only consider Research Help for projects which have actually made some progress, e.g. more than 1 scientist day has been applied to them.

In the meantime, maybe put a warning to players in the XCUSETUP script, to keep their research projects to a smaller number when using Research Help from Aliens. [[User:Spike|Spike]] 21:10, 16 March 2010 (EDT)

== Features for 9.8+ - New features ==

=== TFTD Gauss Tank Research Fix ===
*Have the option to make the Gauss Tank require only Gauss Cannon research - this can make it more distinct than the Sonic Displacer and maybe slightly useful for a while
:*I plan on it. just not this version. --[[User:BladeFireLight|BladeFireLight]] 20:53, 18 January 2010 (EST)

=== Improved Base Comes At Cost ===

The Improved Base is supposed to be a "faster start" option rather than a "make the game easier" option. But it does make the game easier, not least because it gives you a load of free base facility improvements. (Not to mention not having to struggle along the first month with only Small Radar and no Alien Containment) To partly avoid making the game easier, please add a sub-option that subtracts the cost of the extra facilities from your starting cash. This should be the ''full'' cost of the extra facilities, not just the difference between e.g. a Small Radar and a Large Radar.
[[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
: I dont have the offsets to the starting money ranges. so I cant do this. --[[User:BladeFireLight|BladeFireLight]] 19:13, 10 March 2010 (EST)
:: I never realised that the starting money is slightly random, I see ranges from $4,125,000 to $4,153,000, in ten samples. Does not seem to depend on Difficulty or starting base location. That is going to be a hard offset to find. [[User:Spike|Spike]] 20:36, 11 March 2010 (EST)
::: I believe there is no "starting money" anywhere to be found, or rather the starting money is effectively zero but it soon changes: the first thing the game does when you begin a new game is perform a hidden monthly report which grants you money from the funding nations. Only way to decrease it is to lower your rating toward countries (you should be able to hack the starting diplomacy data located at 0x4728F8). Or I could just patch the initial money to be negative instead of zero thus providing lower overall starting money. [[User:Seb76|Seb76]] 15:52, 12 March 2010 (EST)
:::: That makes a lot of sense. The initial money is the same as the initial funding. Doh! I should've realised that. The solution to poke a negative number into the money field, prior to the "hidden funding round", sounds a great idea.
:::: Looking at initial money vs funding, your initial cash is always $1,860,000 less than your initial funding. This $1.86M is probably made up of the first 3 rows (only) of your initial Monthly Costs: $500K transport rental, $1200K Interceptor rental, and $160K salary (not hiring fees) for 8 Soldiers. The salary (and hiring fees) for 10 Scientists and 10 Engineers are ignored. The Base Maintenance costs, $224K for a standard starting base, are also ignored. This generosity saves you at least $774K. Could this be considered a bug? Possibly.
:::: The cash value of the XComUtil Improved Base is a whopping $4.5M. This is $1.6M of facilities (Alien Containment, Large Radar, 2nd Living Quarters) and $2.9M of personnel (+10 Engineers, +40 Scientists). $4.5M would wipe out all starting cash and players would begin the game with a negative balance - quite challenging! For XComUtil, it might be best to break improved Facilities and Extra Starting Personnel into 2 options, with each having a sub-option to pay for the improvements. ''"These extra facilities/staff would cost $1.6M/$2.9M, do you want to deduct that amount from your starting cash?"'' [[User:Spike|Spike]] 20:48, 12 March 2010 (EST)

=== Easier Inventory Management ===
Inventory management is one of the things I hate about the first two X-Coms. I was hired to be a commander, not a supply clerk! A mod which made general stores have 10000 space (like Apoc) would be nice.. [[User:Cesium|Cesium]] 21:39, 9 February 2010 (EST)
: The manager of any facility has to deal with generalities of space issues. The clerk tells you if that fancy new tank you just bought will fit. He has to put it in storage and keep track of what shelf the ammo is on. --[[User:BladeFireLight|BladeFireLight]] 22:27, 9 February 2010 (EST)
:: That's the clerk's problem and if he complains too much I'll have him peel potatoes until his hands drop. In any event, the limit doesn't make any sense:
::* General stores size is 8x8x2 (8x8x3 in TFTD) per base defence map, and should have no problem storing more than 50 items.
::: The items taking up 1 item unit are typically about the size of humanoid body. I think it's not unreasonable to have no more than 50 of those in the area that the General Stores takes up.
:::: I can't find a list on the wiki of storage space requirements for items, so I'm not sure which items take up 1 item unit. Typically the main space wasters are Heavy Plasma ammo/Blaster Bombs/Stun Bombs (late game) and/or HWPs and avalanches (early game). These either are definitely not the size of a human body (ammo/Bombs), or shouldn't be stored in stores at all (HWPs gain nothing, and might as well lay around somewhere else in base).
::* The size of a fully built X-Com base is about the size of a city block (judging by comparison of base defence to terror missions), and should easily be able to hold hundreds of items even in the starting base if it's willing to put some stuff not in the general stores.
::* The space limit makes no sense. Why do Blaster Bombs and Heavy Plasma ammo take so much space whereas in the inventory view it doesn't take any more than normal ammo? Who stores <s>mini tanks</s> HWPs in the same compartment as light weapons? And the way X-Com (probably) stores ammo and explosives is scary...
::: As you suggest, extremely powerful ammunition probably requires a lot more space for safe and secure storage in-base, versus on a tactical mission. Imagine what would happen if a Blaster Bomb exploded in a base? Or was stolen? They probably use nuclear warhead style storage facilities for those. And similarly for Avalanche warheads, alien artifacts, Elerium, etc. Segregating dangerous/explosive items from other items probably uses up a lot of overhead in the construction of the storage space - think armoured, bomb-proof lockers and bulkheads, advanced security systems, airlocks, scanners, etc. This is not just like piling stuff up in your shed! And the Commander who left Elerium or Avalanche warheads lying around in his hanger or corridors would justifiably be sacked on the spot by XCom High Command. [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Well, judging by all the explosives in the hangar during base defence and the X-COM 1.0 Elerium bug, Elerium and explosive warheads ''are'' lying around in the base... And all the equipment in the General Stores is stored in ordinary lockers according to the General Stores map ;-) More to the point, if X-COM wants to store explosives safely (judging by said warheads X-COM doesn't care too much) they need a special facility for this, not to store them in the room which also contains all the base's weapons and priceless alien artifacts.

:::: Furthermore, I expect X-COM to improvise on storage in the interest of actually winning the war. X-COM does do this and ignore the limit when manufacturing stuff in-base or getting loot from missions. All that's needed is that X-COM will improvise for transfers too. I can't imagine a quartermaster informing the commander there isn't any room for the new armour and that the troops should go without. Maybe the reason X-COM doesn't pay quartermasters each month is that they keep getting themselves lynched by enraged X-COM troops...
::* Gameplay wise, inventory micromanagement is just no fun, especially in the late game when you have all the cash you need but still has to sell stuff after each combat (which can be prolonged if you haven't sold for awhile), otherwise you can't transfer items to the base where your main team is at.
::* Maybe this entire "stores" thing is a plot by the CFN to force X-Com to share its technology with them by forcing X-Com to sell sell sell. It's not like they pay X-Com the real worth of the technology anyway. [[User:Cesium|Cesium]] 23:47, 9 February 2010 (EST)
::: I think a lot of people do find the inventory management tedious, or unrealistically low. Personally I think it's about right for large equipment (missiles, tanks, bodies), but too low for small arms and personal equipment. And yes, it only reflects using the General Stores modules, not storing stuff at random points in the base - maybe fair enough. If the right offset to patch can be found, the storage limits could easily be raised. The last few bytes of [[BASE.DAT]] could be a good place to look for this offset. BASE.DAT can store up to 9,999 units of each item per base. The total limit for items per base would need to be found by experiment, but 9,999 might work for those who want to ignore inventory. For those who feel inventory management is OK but the limits set too tight, the capacity of each General Stores could be increased from 50 to 100 - assuming we can find the offset for this to patch it. [[User:Spike|Spike]] 19:50, 10 February 2010 (EST)
::::Maybe you can try there:
.text:00439C85 66 81 C5 F4 01 add bp, 500
::::[[User:Seb76|Seb76]] 13:03, 11 February 2010 (EST)
::::: Yes that works nicely. E.g. patch '''66 81 C5 E8 03''' at that location and you get 100 space per General Stores. Thanks Seb! [[User:Spike|Spike]] 18:21, 13 February 2010 (EST)
:::::: Now if only I had the offsets or search signature so we can add that as an options --[[User:BladeFireLight|BladeFireLight]] 18:24, 13 February 2010 (EST)
::::::: UFO 1.4 dos: offset 143748. TFTD 2.1 dos: offset 178462. TFTD v1 dos: offset 176861. TFTD CE: offset 252795. UFO CE: offset 236680. (all offsets are in decimal and point to the "F4 01" value to be patched).
::::::: Patching to "E8 03" has been tested on dos versions (not on CE) and it works. The "base information" screen will display the correct value, though the values to line length scale is such that the line will max at 250. [[User:Cesium|Cesium]] 05:57, 14 February 2010 (EST)
::::::::Are the preceding bytes the same from TFTD 1 and 2x? --[[User:BladeFireLight|BladeFireLight]] 17:26, 15 February 2010 (EST)
::::::::: Yes they are. '''81 C3 F4 01''' is the add instruction. [[User:Cesium|Cesium]] 17:48, 15 February 2010 (EST)
::::::::: Sig for UFO Dos is '''81 C6 F4 01''' --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
:::::::::: Do you also have the preceding bytes for UFO? with the signatures I can create a patch file for all versions --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
::::::::::: I am not sure I understand your question.. Judging the the two UFO versions I have available (1.3 per xcusetup and 1.4) the common preceding bytes are ''80 78 16 07 75 0C 80 78 3A 00 75 06'' (followed by the sig). You could try to use the sig alone - it exists only once in the file. [[User:Cesium|Cesium]] 19:35, 15 February 2010 (EST)
:::::::::::: Offset Locations are something I'm collecting but also the unique series of bytes to find them for the two geoscape/tactical that I dont have. (UFO Spanish, TFTD Italian) I hope to add a lot more options in the in the future. I do feel this one nerfs the storage system anything to get the game up and going faster is always a plus. --[[User:BladeFireLight|BladeFireLight]] 22:01, 15 February 2010 (EST)
::::::::::::: Well, you may want to add another General Stores to the improved starting base if you want to achieve the faster startup effect without "nerfing" storage system for rest of game (I prefer a "nerf" due to late-game reasons). Also, I suggest you add an message in Xcusetup to ask people to get in contact with you if they use an unknown/unrecognized version. [[User:Cesium|Cesium]] 14:27, 16 February 2010 (EST)
::: Inventory management is just as much a pain in the early game, where you almost always are out of space until your 2nd general stores is built. I like realistic constraints, but not tedium. Maybe upping the space per Stores from 50 units to 100 units would be a generally acceptable approach (now that Seb76 has kindly found the offset)? [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Yeah, that would be a great improvement. [[User:Cesium|Cesium]] 15:45, 13 February 2010 (EST)

:I can confirm Seb76 is correct, as ever. The 2 bytes at offsets '''0x39c88''' and '''0x39c89''' in geoscape.exe code for the capacity of each General Stores. Default value is 500 ('''F4 01''') which equates to 50 in-game internal capacity units. (Smallest item uses 0.1 in game capacity so I guess that is 1 unit in internal units). I am not sure about a signature. From what I can tell, the preceding bytes '''66 81 C5''' are unique in geoscape.exe, which seems pretty odd, so someone else should verify that. [[User:Spike|Spike]] 19:48, 13 February 2010 (EST)
:: Yes it is unique to CE. it does not exist in any DOS EXE, but "F4 01" can be found in 79 places. Trial and error could locate it. --[[User:BladeFireLight|BladeFireLight]] 20:50, 13 February 2010 (EST)

=== AutoCombat ===

==== Firepower Factors ====
You might want to consider replacing the weapon offensive weighting factors for Autocombat with some factors that are (inversely) related to the [[Weapon_Analysis#Quantitative_Analysis|% TUs Per Kill]]. I've tabulated these for each weapon (including tanks) vs each alien race. You would still need to account for Psi, light/darkness, and XCom armour. Plus you would need a similar offensive factor for the aliens' attacks. But I could probably help with that, I have the data that's directly comparable to the % TUs per Kill for XCom weapons. [[User:Spike|Spike]] 22:06, 12 February 2010 (EST)

==== AutoWithdrawal ====

One of the most tedious things you can try to do in XCom is to scavenge the battlefield and retreat to landing craft for an Abort. A great option would be an AutoWithdrawal, similar to an AutoCombat, but with an easier threshold of XCom vs Alien combat power.

Basically it would scavenge all loose equipment off the Battlescape - dropped friendly and alien items, friendly and alien corpses and wounded, all go back into the landing craft. Elerium, Alloys, and UFO Components would not be recovered, as this is (normally) impossible apart from full tactical victory. All friendly troops return to the landing craft. Friendly losses, and equipment recovered, would be proportional to the offensive factor ratios but much more favourable than for AutoCombat. E.g. as long as XCom factors were at least equal to Alien factors, they would be able to scavenge everything and recover without casualties. If the aliens were stronger than XCom, they would only recover part of the scavenged equipment, and risk partial casualties, at say one third the rate of AutoCombat. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

: It's too easy compared to actual game IMHO. Every time a battle went FUBAR for me, it got FUBAR all the way and I was lucky if I could salvage my own team/equipment and maybe a single alien weapon/body. An AutoWithdrawal without salvage might be useful, but perhaps instead we should change AutoCombat failure mode to work better (e.g. Make some X-COM people survive a failed AutoCombat, depending on strength vs aliens). [[User:Cesium|Cesium]] 15:00, 7 March 2010 (EST)

:: Yes fair point. I was not thinking of the FUBAR situations, and you are right about how hairy those are. I was thinking of the situation where you control a certain part of the battlefield, but you either don't want to go on an endless hunt for the last few aliens, or you pretty much know you can't take on the aliens that are left (e.g. in the UFO or some other stronghold) without getting creamed. You can exercise a safe withdrawal, it's just tedious to carry out all the bodies and equipment. But it's pretty hard for an AutoCombat algorithm to detect which of those situations it is - FUBAR, boredom, or tactical withdrawal. I'll have to think about that, there may be no realistic solution at all. And there is the existing "teleport loose items back to base" command line option to XComUtil, maybe that's enough. [[User:Spike|Spike]] 16:08, 7 March 2010 (EST)

=== Tougher UFOs ===

[[Wish_List_(EU)#Tougher_UFOs|Tougher UFOs]]
As this is entirely implemented by patching data and data files it is a good candidate for XComUtil rather than [[UFO Extender]].
: That would definitely make the game harder. 9.7 is about the installer and the bug fixes. This would be a good candidate for 9.8. --[[User:BladeFireLight|BladeFireLight]] 01:38, 19 February 2010 (EST)
:: Cool! [[User:Spike|Spike]] 02:25, 19 February 2010 (EST)

=== Rebalanced Craft Weapons ===

This fits under the "making useless things usefull" category. It would be a 9.8 or later option. The idea is to make the Cannon, Stingray, Laser Cannon and Fusion Ball Launcher useful. Hopefully it breaks up the monotony of Dual Avalanches followed by Dual Plasma Beams, every game.

There is one common element in the approach, and two options. The common element is to fix the stats on the Fusion Ball Launcher. The two options are to use a stat-based approach, or a cost-based approach, to fix the other weapons.

NB This proposal is still a draft and will need tweaking, but I've got it to the point where it is worth discussing. Feedback is welcome!

''(Ultimately, the Plasma Beam still ends up being pretty much the optimum weapon in the end game. To mitigate this, it is a good idea to select the existing Alternate Energy Weapons Manufacturing option in XComUtil.)''

==== Fusion Ball Launcher ====

Increase the ammo capacity from 2 to 3. Don't mess with the damage. Job done.

See [[User:Spike#Fusion_Ball_Launcher]] and discussions linked from there.

==== Cost Based Approach ====

This uses historically realistic costs to restore game balance between different craft weapons. The stand off advantage of Avalanche missiles is now purchased at a price which is significant in terms of XCom budgets and mission yields. Stingrays and Cannons become significantly cheaper alternatives. The Laser Cannon, with similar capabilities to Stingrays but free to operate, also becomes very attractive. Mounting dual launched weapons becomes a very expensive luxury.

*Increase Avalanche missile Purchase cost to $386,000
*Increase Stingray missile Purchase cost to $125,000
*Leave Sell prices unmodified (to avoid creating a cash reservoir at the start of the game)
*Leave Launcher buy/sell prices unmodified

See [[User:Spike#Cost_Based_Rebalancing]]

==== Stat Based Approach ====

This provides a benefit trade-off to shorter range weapons, by increasing their firepower or effectiveness relative to longer range weapons.

*Increase Cannon stats to 15 Damage, 50% hit. Firepower is tripled, slightly ahead of (unmodified) Avalanches launching in Aggressive mode. Increase rearming rate to 200.
*Increase Stingray accuracy to 80%. Decrease Avalanche accuracy to 60%. Stingray now has 50% more firepower relative to Avalanche. Increase Stingray rearming rate to 2, so a full craft can be re-armed in the same time period with either weapon (instead of twice as long for Stingray).
*Increase Laser Cannon stats to 100 Damage, 50% hit. Firepower is doubled, 20% more than (unmodified) Avalanches launching in Aggressive mode, 2/3rds of Plasma Beam firepower.

To avoid advanced XCom aircraft exploiting the extra firepower of the Cannon weapons and disregarding the return fire from UFOs, this is best used alongside the Tougher UFOs option.

See [[User:Spike#Stat_Based_Rebalancing]]

=== Rebalanced Infantry Weapons ===

See [[User:Spike#Balancing_Infantry_Weapons]]

Primarily this means making the Rifle a bit stronger, and probably making the Pistol a bit weaker.

=== Advanced Laser Cannon ===
The "Advance Laser Weapons" option only nerfs the Laser Cannon (raising cost and reducing profitability but not changing any damage/range values. Previously xcomutil modified them unconditionally). I wonder if that's the best result - should damage and/or range be raised to make the cannon useful or to compensate? Most commanders don't use the cannon as is, but maybe it's prejudice... [[User:Cesium|Cesium]] 21:36, 16 March 2010 (EDT)

: Note this isn't a "rebalancing issue" compared to the other weapons - I'm talking about (maybe) balancing for the increased cost of production and lower profit. [[User:Cesium|Cesium]] 21:41, 16 March 2010 (EDT)
:: I guess the craft weapon rebalancing options listed just above, either the cost-based or the stat-based, would help out here. The intent of "Alternate Laser Weapons" is purely to make the game harder, which it definitely does. Is it necessary to "balance" something that deliberately makes the game harder? I don't think so. But I do think the general principle should be that there are no "pointless" items of equipment. So either way the Laser Cannon deserves a buff. Personally I never thought the previous XCU buff to Laser Cannon made it worth using. What it gave with one hand (range increase, but still lousy range), it took away with the other (firepower). I would actually rather have the standard Laser Cannon than the old XCU "buffed" one. [[User:Spike|Spike]] 22:11, 16 March 2010 (EDT)

==See Also==

[[Wish List]]

= Completed Wish List Items =

=== BFG Default To Unchanged ===

Is it possible when using the BattleFieldGenerator, for it to detect the actual conditions for the mission (terrain, enemy craft, and light level) and offer these as defaults? [[User:Spike|Spike]] 08:22, 13 February 2010 (EST)
:Press The esc key at the prompt. (Line 719 in Xcomutil.txt, not that I expect anyone to read the manual :) ) Enter should also work. --[[User:BladeFireLight|BladeFireLight]] 12:34, 13 February 2010 (EST)
:: RTFM eh? My biggest failing. Maybe you could add an explicit prompt "Esc or Enter = [whatever the unmodified value would be]". [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)
::: From what I can see, hitting Escape during BFG makes it continue with ''all'' values reverting to the original conditions. It would be nice to be able to select some but not all original conditions. My main use of this is to turn a night mission into a day mission without the hassle of keeping the landing craft hovering around until the terminator crosses the landing site. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
:::: You could just use the force all daylight option.
:::: After reviewing Scott's code. Esc leaves all setting as-is. Pressing enter or any other key not listed will randomly choose for you. I will see if I can change enter to leave as is. --[[User:BladeFireLight|BladeFireLight]] 11:00, 7 March 2010 (EST)
::::: This has been added --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)

= MISC =

* It's actually quite hard to downgrade to DOSBox 0.72 in Ubuntu. Only 0.73 is offered, there is no ability to Force back to a lower package level with Synaptic Package Manager. Unix guru skilz are required to rollback to 0.72, and I guess 0.74 is not around yet, or not packaged for Ubunut APT? Is there any way to fudge around this, e.g. by providing the command line arguments in an optional text file for xcusetup.bat to parse? Having said that, even with no command line arguments, xcusetup hangs on my 0.73 DOSBox while executing SDUMP. I had to reboot in Windows to run xcusetup.bat - something that is only possible on a dual boot machine / Wubi machine. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
** Try using a different batch interpreter like 4DOS [http://www.4dos.info] to execute xcusetup inside DosBox. I tested this throughly before under DosBox/Linux and it works well with recent 9.7 builds. I suggest running "config -set cpu core=dynamic" and "config -set cpu cycles=max" before xcusetup to speed it up (xcusetup doesn't detect DosBox when 4Dos is run, so it doesn't run these automatically unlike normal DosBox case). [[User:Cesium|Cesium]] 09:48, 7 March 2010 (EST)
** Oh, and downgrading isn't that difficult: Get a dosbox 0.72 deb, and run "dpkg -i" on it, and then do "echo dosbox hold | dpkg --set-selections" to prevent future upgrades. [[User:Cesium|Cesium]] 09:50, 7 March 2010 (EST)
** Another option is to install the dosemu package, and run xcusetup under that. EU/TFTD can be run under that, but it doesn't work as well there. (Oh, and there's no mount command there. UFO/TFTD needs to exist under ~/.dosemu/drive_c which is C:) [[User:Cesium|Cesium]] 11:42, 7 March 2010 (EST)

:Thanks Cesium I will check this out. I still think it would be good to have a solution that works for people who are not knowledgeable with the unix command line though. [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)

:: Why use Linux if you dont know how to use the console? It is a text mode OS with a separate GUI. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)

::: Well Ubuntu is a bit different, as it's supposed to be an OS for the general public, where you never need to touch text mode! Incidentally I can't find any DEB or other packages for 0.72, all that is available on the DOSBox website is the source code. They really don't seem to realise that 0.73 is buggy! So I guess I will need to '''make''' it. Or just wait for 0.74 as I think it's out soon. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)

:::: See [http://archive.ubuntu.com/ubuntu/pool/universe/d/dosbox/] for 0.72 debs. Unlike Windows, package systems in Unix land are centralized, so best location to search is typically a package server mirror or a distro mirror, not a vendor's website. [[User:Cesium|Cesium]] 17:36, 9 March 2010 (EST)

Talk:XcomUtil

2010-03-17T20:35:20Z

BladeFireLight: /* Open Bugs */ Solution to Autocombat MIA.

=XcomUtil 9.7 Beta=

9.7 Beta is available on www.bladefirelight.com

==Release Notes==

This is a Beta, so backup your files before using. And check back often for newer builds.

New in this version.

*Major overhall of the installer (XcuSetup) and the inclusion of 16/32bit exe's to support both DOSBox and Windows Vista/7 x64.
*New subfolders added to hold supporting files making the install cleaner
*New XcuSetup command line arguments were added to XcuSetup allowing for silent install and uninstallation.
*New XcuSetup option for debugging the install (XcuSetup debug) creating XcomUtil\debug.txt.
*New command line argument "nobackup" skips backup only if it has been ran atleast once.
*XcuSetup can now have minimal impact on the game.
**Almost all options default to NO (Only Split Windows EXE set to Yes).
**Almost all changes are now prompted for (skyranger guns, interceptor as transport, Disjointed Base Bug, etc...).
***Items still done by default:
***Copy protection questions set to 0000000 for UFO 1.0-1.3 and X-Com 1.0
***Difficulty bug fixed in UFO 1.0-1.4 and X-Com 1.0-1.4
***Unique names for all maps in TFTD, Used for Hybrid Games
***Placement of X-Com Units on the Battlefield based on XcomUtil.cfg
***MIA Recovery on Won Combat (Units under mind\MC control when last controling alien killed are returned to X-Com control)
*XcomUtil.cfg is now pieced together and overwritten by XcuSetup (see XcomUtil\XcomUtil.txt for how to make permanent changes).
*All game files are restored to the pre-XcomUtil state each time XcuSetup is ran. Any modifications by other utilities will have to be re-applied.
*Vista/Win7 patch now an option for XcuSetup.
**This will fix the blank screen issue.
**Updated to support the split EXE.
**Will set X-Com to use CPU 0.
*XcuSetup attempts to fix UAC issues by resetting folder permissions.
*A number of community made fixes are included and selectable with XcuSetup.
*Support for the DOS/Window STEAM Install.
**Installer will detect STEAM and change steam launcher to start the XcomUtil Steam Menu (can be re-installed with XcomUtil\SteamSetup.bat
*Out of the box support for UFO Extender. XcuSetup will detect it and ask if you want RunXcom to use it.
*XcuSetup can be run from windows and RunXcom run from DosBox
*Hybrid Colors updated based on BombBloke's pallets.
*EQL flag allowed any turn.
*Add Xcom UFO Italian Support.
*Auto Combat will not run on second half of two part using first parts saved data.
*Auto Combat will no longer run if combat was won.
*MIA Recovery on won combat only.
*MIA Recovery no longer recovering units that bleed to death.
*Auto equip no longer triggers on second part of 2 stage missions.
*Combine clips skiped if between stages of 2-3 part missions.
*Updated f0dders ReadMe per his request. (XcomUtil\bugfix-readme.txt)
*Add-on support added. see XcomUtil\XcomUtil.txt and XcomUtil\Addon\Example.txt
*Prompted Terrain in BattleField Generator allows to abort or use of current setting.
*Beta versions include
**XcomUtil\XcomUtil.log includes lots of debug info
**XcomUtil\Debug.txt created by default (Release will need "debug" command argument)

Removed from this versions

*New Desert and Urban terrain. (Will be added once I have a C++ version of the Java Terrain Edit.)
*Expanded capacity Laviathan, Hammerhead and Avenger (maps avalible in XcomUtil\Patches)

NOTE: If you use DosBox, this requires DosBox 0.72 (Does not work on 0.73 due to buffer overflow setting ERRORLVEL)

===Build 435===

Original Sound Effects from UFO were re-sampled to work with 1.4 and CE.

*Add Category to option headers.
*Improve randomness by using current time instead of game date/time in srand()
*Added Option to keep Current terrain/UFO to BFG.
*Original UFO 1.2 Sounds for Geoscape and Tactical added as an option for UFO 1.4 and CE.
*Force Split EXE on STEAM. Fixes issues with setup failing.
*Reset Laser/Gauss craft weapons stats to be default.
*Example addon now uses different flag extension to avoid deletion by XcuSetup
*fix issue with Lab Screen on DosBox always screening

==Beta Discussion==

===Build 435===
: I hope the improved randomness doesn't apply to the Aliens' d100 during AutoCombat. Otherwise, one could load-scum for success. [[User:Cesium|Cesium]] 06:33, 11 March 2010 (EST)
:: Actually it does. I can see what your getting at, but why do it that way. if you want to win the "WIN" command line option is faster and you get better loot from the UFO. also using the combat date would also swing the other way with an unwindable autocombat with an fully loaded avenger vs a survey ship. --[[User:BladeFireLight|BladeFireLight]] 17:41, 11 March 2010 (EST)
: In the setup question for sound files: "were replace" should be "were replaced". [[User:Cesium|Cesium]] 06:53, 11 March 2010 (EST)

----

Excellent! For the first time xcusetup.bat completed for me in Dosbox in Ubuntu. Previously the SDUMP commands were hanging it.

For the first time ever, I ran the sound setup utility. It did not response to any cursor keys, enter, tab, etc. The only key that worked was Escape, and I'm not sure what this did.

One point on the xcusetup.bat script - Ctrl C does not seem to work. On all those "press a key to continue" prompts could we also have "or 'q' to quit"?

[[User:Spike|Spike]] 18:41, 13 March 2010 (EST)

: "press a key to continue" is the Pause command. Ctrl + C works fine in Windows. DOSBox does not. The reason for the use of Pause is because an number of new players kept exiting setup early when I gave the option. Aborting early makes a mess and I dont want to have to troubleshoot it for Joe user. --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
:: OK I see, that makes a lot of sense. [[User:Spike|Spike]] 06:52, 14 March 2010 (EDT)

----

Does the SHP flag still work, after the changes to how XCOMUTIL.CFG is assembled? I just tried it, after rerunning XCUSETUP.BAT (Dosbox 0.72 under Ubuntu). XCOMUTIL SHP produces no output. XCOMUTIL SHP:CFG WRT writes GEOSCAPE.EXE, but nothing seems to change. During XCUSETUP I see the expected "Patch applied, ship data updated from CFG" (or whatever). [[User:Spike|Spike]] 17:40, 16 March 2010 (EDT)
:: Yes it works fine. your mistyping the command. it's "xcomutil ufoexe shp:cfg wrt" Second argument must be the target folder. Line 42 and 1266 of XcommUtil.txt.
::: Thanks! And I thought I'd read the manual. [[User:Spike|Spike]] 20:31, 16 March 2010 (EDT)

==Open Bugs==
*There's no Italian text for the Alternate Laser Weapons option. Applying the patch seems to work, but it displays the text for the default laser weapons.
:*Anyone want to translate the text into Italian? --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
*The number of aliens in the mission report is inconsistent with the number of live aliens captured per research help. See [[Image:Alien_numbers_mismatch.zip]] and [[Image:Dead_alien_count.zip]].
* Morale is random at start of second stage after autocombat of first stage?
:* Actually Morale is used as the clip size and time units as the weapon damage. Don't ask me why. It would take a major re-write of auto combat to fix this. --[[User:BladeFireLight|BladeFireLight]] 19:34, 23 February 2010 (EST)
*RPL bug, when you turn creatures into Gill Men, they are reported as Snakemen
:* Reported how? Is this consistent? The name's used are from xcomutil.cfg. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
::*Sorry. It's reported in morale failure pop up messages. Though maybe this is an original TFTD bug rather than an XComUtil bug. [[User:Spike|Spike]] 19:21, 21 February 2010 (EST)
:::* See this: [http://www.youtube.com/watch?v=uGlSghf7aTU]. In that case, all Gill man (were lobster man before RPL) were reported as snakemen.. [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST)
*RPL bug, when you turn Lobstermen into other creatures (e.g. Gill Men), they are very hard to kill despite having the stats of the creature they turned in to. Possibly they are keeping their damage resistance? Maybe the race is stored in more than one place, for different purposes, and XComUtil misses one of these places?
:: I will look into this --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: The RPL only changes the basics; The race, rank, name, TimeUnits, Health, Energy, Reactions, Armor(front,back,left,right), Strenght and PSI Strenght. All other stats are left as-is. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
:::: I'm not so sure about this. See 05:00 mark at [http://www.youtube.com/watch?v=y-_zLdjhUHI]. The armour doesn't match the one Gill man should have (per UFOpaedia, at least). [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST). See also 04:17 mark at [http://www.youtube.com/watch?v=z5LfzFSkRnI] for reason to suspect resistances aren't always changed. It's possible he just was unlucky though... [[User:Cesium|Cesium]] 19:53, 21 February 2010 (EST)
::::: Actually the function is something like this
<pre>#define UpdateStat(x,y) pur->x = (unsigned char) \
( ( (unsigned int)pur->x \
* (unsigned int)pasTo->y \
) / (unsigned int)pasFrom->y )
UpdateStat( TimeUnits0, TimeUnits );
UpdateStat( Health0, Health );
UpdateStat( Energy0, Energy );
UpdateStat( Reactions0, Reactions );
UpdateStat( AFront0, AFront2 );
UpdateStat( ALeft0, ALeft2 );
UpdateStat( ARight0, ARight2 );
UpdateStat( ARear0, ARear2 );
UpdateStat( AUnder0, AUnder2 );
UpdateStat( Strength, Strength );
UpdateStat( PsiStrength, PsiStrength );
</pre>
::::: the 0's are values at start of tactical.
::::: I read that as Current(from game_x) * Target default(from xcomutil.cfg) / source default (from Xcomutil.cfg) so the stats will be different. --[[User:BladeFireLight|BladeFireLight]] 21:33, 21 February 2010 (EST)
:::::: I'd have expected Current(game_x) == Source default if applied on first turn? This would end up with result == Target default, no? Hmmm... We already saw some compiler multiplication wackiness with the research help bug. Possibly this affected these calculations too?
:::::: As for the code, you're not updating PsiSkill, so non Psi-users can't get Psi after RPL. [[User:Cesium|Cesium]] 22:03, 21 February 2010 (EST)
::::::: I didn't write this. I'm amusing Scott did it this way to adjust for difficulty because XcomUtil.cfg has the beginner level stats. It need's an overhaul to use the full stat entries including the unknowns adjusted correctly for the level. Something for latter. --[[User:BladeFireLight|BladeFireLight]] 22:09, 21 February 2010 (EST)
:::::::: For this specific issue I think you will need to update 0x37 of [[UNITREF.DAT]] which is the Damage Modifier. For the general problem you will need to update the Psi Strength and also Firing Accuracy, energy regen rate, movement class... loads of stuff. And of course LOFTEMPS. So with current RPL not changing LOFTEMPS, changed aliens are the wrong size and shape probably. This would be visible using the LOFTEMPS map viewer I suppose. [[User:Spike|Spike]] 18:39, 9 March 2010 (EST)
*[[Known Bugs#XComUtil Inventory Stacking Bug]]
:* I hope to overcome this but Scott's notes point to a technical limitation. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*Fusion Ball Launcher fixes - detailed discussion moved to [[Talk:Fusion_Ball_Launcher#XComUtil_FBL_Issues]]
** Profitability (inconsistency item) - becomes most profitable item when using Alternate Laser (and Plasma) Tech option. Recommendation - workshop space and Engineer hours x10, 4 Alloys, 20 Elerium. And make it more useful (see below).
** Usefulness ''(wish list item)'' - perceived as being not very useful with standard stats. Recommendation - increase ammo to 3. Leave damage as-is to allow for Tougher UFOs (see Wish List).
*Zrbite lying around in odd places. Objects lying around in odd places in general - these are map modifying errors, probably only occur when customising terrain etc.
:: Will be part of an overhaul of the BFG --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*There is a small problem in editing/customising craft using '''XComUtil.cfg'''. Certain X-Com craft weapon values - the rate of fire value - can't be set. Or more specifically, they can be set (patched) in the executable but it has no effect in the game. To avoid confusion they should perhaps be removed from the format of custom craft, or commented out. (This rate of fire patching ''might'' work on UFOs, haven't tested it).
:: Can you be more specific? --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: There is a section in '''xcomutil.cfg''' which is used for patching XCom craft weapon characteristics. This is where Scott changed values for the Laser Cannon, etc. Probably very few people use these fields. I only used them because I was doing research into the game mechanics. One of the values changed in this section is the reload time. These values are present in the executable, and can be patched, but patching them has no effect (other than to change the UFOPaedia entry). The reload time seems to be hard coded elsewhere in the executable, based (broadly) on the class of weapon. So you might want to comment this column with an a note saying "cannot be modified for combat". On the other hand I could be wrong, or someone still might want to modify these fields. Discussion is at [[Talk:UFO_Interception#Observed_Rates_of_Fire]]. Offsets are at [[Talk:GEOSCAPE.EXE#Craft_weapon_stats]]. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
:::: Or maybe change these display-only values so that they reflect the [[Talk:UFO_Interception#Observed_Rates_of_Fire|observed reload rates]]? I am not yet 100% sure I have got these right, might want to wait until I do some more confirmation tests. [[User:Spike|Spike]] 15:26, 22 February 2010 (EST)
*EQL only works on turn 1 (see discussion above)
::: Added to my to do list. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*Research Help from Captured Aliens awards research help without checking first if you have Alien Containment at the base of origin. Resulting in dead aliens helping you with your enquiries! Possibly only applies to AutoCombat? [[User:Spike|Spike]] 21:05, 14 March 2010 (EDT)
:: Ideally it would not only check for containment but also have a research item for it and check on how many scientist days had been reduced since the last combat and use that as a value for how much you get form the aliens still in containment. But that could just be a pipe dream. Checking for containment for now is a good idea. --[[User:BladeFireLight|BladeFireLight]] 15:35, 16 March 2010 (EDT)

----

I have a strange issue. I succeed in an AutoCombat terror mission (117%) but the mission is resolved partially as if I had actually aborted the mission - all Civilians die, even though I could see 3-4 alive, my 13 soldiers outside the Skyranger go MIA, even the one who was killed by AutoCombat, and only my sergeant standing in the Skyranger makes it back. The problem is repeatable. On one occasion the sergeant was killed randomly by AutoCombat, meaning that the Skyranger flew back by itself, empty. Obviously this should never happen.

I've uploaded the [[Media:MIAoverload.zip|AutoCombat game save file]]. Incidentally this shows how to 'game' the current AutoCombat rules: Take maximum soldiers, no tanks. You give everyone a Rocket Launcher, they only need 1 Lg Rocket in it. Until you get Heavy Lasers, then replace the Rocket Launchers with them. Next replace with Heavy Plasmas. This approach always gives you maximum damage per soldier, and thus maximum chance of getting the +15 bonus for the W:3- rule. [[User:Spike|Spike]] 19:02, 15 March 2010 (EDT)

:: Hmmm. Scott's MIA recovery raised an army of undead from those that died of fatal wounds. Mine only effects mind controlled units. The issue is telling who is dead and who is left behind.

Units from your saved game looked like this(on by Autocombat).

Shuji Okabe: Left behind (Health > 0)
[[UNITPOS.DAT|UnitPos]][0x0A] 1.0.0.0.0.0.0.0 (bit 2 == 0 Unit on the ground[dead or unconscious])
[[UNITREF.DAT|UnitRef]][0x78] 0.0.0.0.0.0.1.0 (bit 1 == 0 Unit Alive)
Yoko Fujimoto: On Craft (Health > 0)
UnitPos[0x0A] 1.1.0.0.0.0.0.0 (bit 2 == 1 Unit Standing [Active])
UnitRef[0x78] 0.0.0.1.0.0.0.0 (bit 1 == 0 Unit Alive)

From Bomb Blokes undead army MIA Test save (won by killing aliens).

Spencer Bryant: Lived (Health > 0)
[[UNITPOS.DAT|UnitPos]][0x0A] 0.1.0.0.0.1.0.0 (bit 2 == 1 Unit Standing [Active])
[[UNITREF.DAT|UnitRef]][0x78] 0.1.0.0.0.0.0.1 (bit 1 == 0 Unit Alive)
Oscar Thompson: Bleed to death (Health > 0)
UnitPos[0x0A] 0.0.0.0.0.1.0.0 (bit 2 == 0 Unit on the ground[dead or unconscious])
UnitRef[0x78] 0.1.0.0.0.0.0.1 (bit 1 == 0 Unit Alive)
Virgil Hudson: Killed by Aliens (Health == 0)
UnitPos[0x0A] 0.0.0.0.0.1.0.0 (bit 2 == 0 Unit on the ground[dead or unconscious])
UnitRef[0x78] 1.1.0.0.0.0.0.1 (bit 1 == 1 Unit Dead)

So right now I'm at a loss of how to detect tell the difference between thoes that are left behind and thoes that are dead.

:There must be something odd about my save game that takes 13 live soldiers and makes them all MIA on an abort. I wonder if it is something to do with the one guy who is still on the transport. I'm sure I've never seen an MIA after an AutoCombat victory, or defeat, before. Of course, after a victory, no one should be MIA. In a defeat, in theory AutoCombat could (but doesn't?) allocate some soldiers as MIAs. For the bleeding to death problem, perhaps you could check whether Health <= Fatal Wounds. In the normal game this might be an ambiguous borderline case? Treat it unambiguously - kill any soldiers matching that condition. In XComUtil after-combat messages, perhaps emit the message "So-and-so died from his/her wounds aboard the transport".
:But I guess the problem is not what XComUtil does, but how to "communicate" back to the game engine that the soldiers are alive and well and not MIA? Surely the game's logic must be '''first''' to determine if the battle was aborted, and only then to decide who was left behind on the battlefield vs who died vs who was on the transport and got home? Surely Scott's logic must intercept this abort flag, and ''then un-set it''?.
:By the way, in the listing above I'm not sure whether the least significant bit is at the left or the right? [[User:Spike|Spike]] 20:31, 16 March 2010 (EDT)
:: I'm guessing it's a bitfield not a number, so LSB/MSB doesn't exist. [[User:Cesium|Cesium]] 21:27, 16 March 2010 (EDT)
::: Yes it's a bit field. I linked to the wiki page with the description. The game engine doesn't need to tell why some one got removed from the game. Tatical calculates the score. --[[User:BladeFireLight|BladeFireLight]] 21:38, 16 March 2010 (EDT)

:::: Thanks for clarifying. I had checked the links, read the bits your way, then had doubts as the description seems the other way round, ie Bit 1 at the end. So, do all 13 of my guys have this "on the ground" flag set? Very weird as none were stunned or dead. They were in smoke with minor stun damage is all. And moving the Sgt off the transport gains nothing, I just get 14 MIAs instead of 13. The wacky thing is the screen says Aliens Defeated and gives me loot - even when the transport is lost. [[User:Spike|Spike]] 22:36, 16 March 2010 (EDT)
:: Ok I have a solution I'm working on. Turns out those that bleed to death are being counted by Autocombat as being in play. Autocombat is not instantaneous, so Everyone with health <= wounds get health = 0 then all units with Health != 0 are marked as not dead.

==Fixed Bugs==
*don't prevent patching windows version while running in dosbox, or vice versa
:*Fixed: XcuSetup can be run independently to the OS RunXcom is used in.
*4DOS and MS-DOS 5 dont like "-" in variable names.
:*Fixed
*Enviroment space reached quickly on most DOS environments.
:*Partly Fixed: Requirement has been drastically reduced to to ~1024 use of Command.com /e:xxxx still may be required
*EnvClean.bat has an error in line 172: ser -> set.
:* Fixed in build 204.
*ANSI escape sequences aren't necessarily supported on a real dos environment/emulation
:*Fixed: ANSI only used in DOSBox
*If all the aliens are down (some of them stunned), the last save is named "AutoCombat" and I end turn, XcomUtil may still run "AutoCombat" phase. This may have slightly different results than end of combat would have had
:*Fixed: Autocombat will not run if you have already won.
*A fully loaded Hammerhead's initial deployment has three aquanauts outside the craft.
:*Fixed: the unit placement for the default 12 unit craft has been added to XcomUtil.cfg
*Select terrain: doesn't appear until after I select a terrain in BFG prompting
:*Fixed
*geodata/obdata.dat gets truncated with selecting any improved weapon.
:*Fixed: This happens because a full backup did not complete but XcuSetup does not detect it. Backup script's changed to avoid xcopy timeout on some versions of DOS. (Backups are required by SDUMP to apply patches)
*I get this error during backup "16-bit MS-DOS Subsystem NTVDM has encountered a System Error The handle is invalid."
:*Fixed: All NT based OS's now using 32bit EXE's
* You can get X-COM MIA if you abort a mission, even if everyone is in the exit. Possibly a second stage bug only? See [[Image:X-COM_MIA.zip]]. Note that this only affects the report - after mission all the X-COM troops are still available.
:*NOT Fixed: This happens even on vanilla TFTD with that save. Given it's TFTD it could be an issue with the mapfiles. --[[User:BladeFireLight|BladeFireLight]] 00:23, 24 February 2010 (EST)
*Various second stage bugs - ammo clip recovery, crashes after autocombat of first stage, etc. Mainly for TFTD, but possibly Cydonia in UFO is also affected.
:*Fixed: Clip recovery no longer ran between parts of 2-3 part missions. Autocombat only crashes on two part if you are aborting the second stage and the save in slot 10 is from the first stage. Stage comparisons are now done to abort autocombat if you do this.
*Removal of Small Scout map / Survey Ship map, making it impossible to do these Battlescape missions.
:*Fixed: 9.7 only removes the maps if you use the BFG. I hope to have 9.8 not remove them at all. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*The XcuSetup prompt for the option of less-profitable weapons manufacturing is misleadingly called "new laser weapons".
:*Fixed: Renamed to Alternate Lasor weapons.
* SteamSetup.bat won't run from DOSBox. It says "This needs to be run from Windows". Though, does it make any sense to run SteamSetup.bat under DOSBox (eg for a linux system with no Steam)? [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
:*NOT Fixed: STEAM doesnt give access by default to the command prompt. If you know how to add that then you should know enough of DOS not to need the STEAM menu. --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
* '''cfg/ShipDefU.txt''' has the XCU values for improved Laser Cannon (35/35/35), not the original values (21/35/70). Is this correct - is this file supposed to be the original defaults? [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)
:*Fixed: I was unaware that this had been changed. The weapons are not prompted for any change so they should not be changed. I'm reseting them all to defaults and looking to see if Scott had anything about them in the notes. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
* standalone patches the fix the difficulty bug
:*Partialy Fixed: 9.7 min install is the difficulty patch and changing Copy protection questions to all 0's.
*Version detection issues with obscure versions (Italian, 1.2a, etc.) causing corruption or lack of patching.
:*Fixed: Added support and patching offsets.
*Various default options make the game easier, not harder (''harder'' being the intent of XComUtil, right?). These should not be defaults. (More discussion at [[Talk:Enemy_Unknown_Extended#Standard_Config_Discussions]]) E.g.
::: 9.7 only has 3 items on by default. Remove copy protection. Fix Difficulty bug and Split EXE (split EXE can be skipped but not the others). All other options are default to NO.
::: As for the intent of XcomUtil. Scott added features to
:::# Increase difficulty.
:::# Make useless items useful.
:::# Get the game Started faster.
::: I have added:
:::# Don't make unwanted changes.
:::# Fix game bugs
:::::Yes all of those are very sensible. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
::::Latter versions of XcomUtil will turn the last two forced items to prompted. with only the Difficulty bug and the split EXE as Default=Yes. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Basic tanks using advanced tank stats
**Improved High Explosive - very powerful in favour of X-Com, especially as alien spawn points and routes aren't set up to cover holes in UFO hulls.
:*Gauss weapons have infinite ammo
::: 9.7 has a second option to just the increase power to closer match UFO.
:*Using fighters as transports (carrying soldiers)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Using transports as fighters (weapon hardpoints)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Improved Heavy Laser / Heavy Gauss. OK, this should maybe be a ''recommended'' option since the unpatched weapons are nearly pointless. But, it does make the game easier. [[User:Spike|Spike]] 20:12, 7 February 2010 (EST)
*FreeDOS breaks horribly during Setup
:*This is most likely an issue with the limits of FreeDOS.
:** Actually, this seems to work well for the latest builds (tested with FreeCOM 0.84 under dosemu). [[User:Cesium|Cesium]] 18:07, 14 March 2010 (EDT)

=XComUtil Wish List=
Things that are not bugs or inconsistencies in XComUtil but would be Nice To Have

== Features for 9.7 - Interface, consistency and bug fixes ==

=== Categorise Config Options ===

For each option, in the prompt, note which category of option this is, according your list above. E.g. faster start, making the game harder, making useless items useful, bug fix, variant game, etc. [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)

:Actually it might be even better to organise the options questions into sections, thematically grouped by these categories. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

:: Items are currently sorted like this.
* Windows EXE
* Game Fixes
* Game Mods
** Sound
** Craft
** Base
** Equipment
** Research
** Units
** Battlefield
** Alien Craft
** Misc
--[[User:BladeFireLight|BladeFireLight]] 19:25, 10 March 2010 (EST)

=== Improved Pistol Modification ===
*Remove 3rd burst for Pistol
Detailed discussion moved to [[Talk:Pistol#XComUtil_Burst_Mode_Pistol]] to de-clutter this page. Summarised recommendations will be posted back here based on whatever consensus emerges.

Current recommendation: Reduce auto accuracy from 60% to 20%, with the same TUs (54%).When prompting, point out that no improvements are required to the Pistol to make it useful. [[User:Spike|Spike]] 08:12, 14 March 2010 (EDT)

* Dart Gun

On the other hand, the Dart Gun really is useless, even as a last ditch personal defence weapon. Auto mode, with very low accuracy (10%?), would at least give it some value as a defensive sidearm for medics, heavy weapons troops, etc. Scouts and others carrying a scanner or grenade in the other hand would still be better off using a Jet Harpoon, or even an AP HydroJet Cannon, one-handed. [[User:Spike|Spike]] 03:47, 16 March 2010 (EDT)

=== Fusion weapons inconsistently exempted from Alternate Laser Tech ===
* Fusion weapons inconsistently exempted from the "more difficult" energy weapons manufacturing option ("alternate laser Tech"). Blaster Bombs and Blaster Launchers, Fusion hovertanks and ammo, and Fusion Balls and Fusion Ball Launchers - none of these are harder to build or use with the "alternate Tech" option. Why make laser weapons/tanks and plasma weapons/tanks harder but not Fusion weapons? It's not consistent. I wonder if Scott didn't look at these because he never used Blaster Launchers or Fusion Hovertanks, as he considered them to unbalancing already? And ignored FBLs because, well, most people ignore them? But this should be consistent. Or, the "harder weapons" option could be broken down into sub options, e.g. for each weapon technology:
** Much more expensive (typically: add some exotic materials, 10x workshop space and 10x Engineer hours)
** Can/can't manufacture the battlescape weapons/tanks (pure alien weapons only)
** Can/can't manufacture the ammo (pure alien weapons only)
:Personally I would prefer it to be all-or-nothing but include the Fusion weapons as being more difficult to make and use. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
* In the meantime (ahead of introducing any changes), maybe change the prompt to "Alternate Laser and Plasma Tech"/"Alternate Gauss and Sonic Tech", and/or point out explicitly that the changes don't affect any Fusion/Blaster/Pulse Wave weapons. [[User:Spike|Spike]] 08:15, 14 March 2010 (EDT)

=== AutoCombat issues ===
* All Civilians are dead if AutoCombat is used to end a Terror mission. It's too not much of a problem, since score is likely to be positive anyway. It would possibly be an improvement to assume all civs from first stage are dead (if ran at second stage) and get a random number (using mission seed) for dead civs at current stage? [[User:Cesium|Cesium]] 07:00, 22 February 2010 (EST)
:* This is odd. Autocombat is supposed to skip over civilians when using the kill function. --[[User:BladeFireLight|BladeFireLight]] 00:18, 24 February 2010 (EST)
::*Maybe kill civilians (or not) according to the force ratios. If XCom has only enough force to win the mission, all Civilians are dead. If XCom bring a certain amount of "excessive force", all or nearly all Civilians are saved. By the way I love AutoCombat, it is great for avoiding repetitive combat and only playing the new, interesting bits. [[User:Spike|Spike]] 15:53, 22 February 2010 (EST)
:::* Thinking about this, I recalled the scenario where someone fights the mission and uses AutoCombat to hunt the last aliens (another reason AutoCombat is great). Spike's suggestion is better from pure RNG, since in this case probably all civs that were at risk already died. So lets see what we suggest XcomUtil do:
:::# Count civs from first stage if there was one as dead (since IIRC XcomUtil has no memory of first stage when exiting second stage, so we can't take them into account?).
:::# Deduct dead civs from current stage.
:::# Calculate extra dead civs using force ratio to bias the RNG (I prefer merely biasing the RNG rather than precluding results, since Xcom in general has a large variance in almost every gameplay mechanic). [[User:Cesium|Cesium]] 18:27, 22 February 2010 (EST)
* Day vs Night
** The Day/night algorithm breaks. For example, at any point when XCom has more than twice as many flare-carrying soldiers than there are remaining aliens, XCom is actually ''stronger'' in darkness than it would be in full daylight. Toward the end of a battle this is a very common situation. But fixing the algorithm is tricky. What might work is to give -10 for each Soldier in darkness, reduce from -20 to -10 for each Alien in darkness, then add back +10 for every soldier with a light source. Thus there is no way XCom can go 'net positive' from light sources.
:: If you have more units then they do you can see more of the battle field. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:::It never makes sense for XCom to be stronger at night, than during the day, for the same force ratio. But that is what happens. An example. 10 XCom soldiers with flares and 3 aliens. At night there is an extra -30 modifier for the aliens, but a +100 modifier for XCom, net +70. The same 10 soldiers against the same 3 aliens are +70 ''more'' effective in darkness than they would be in daylight. It does not make any sense. [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
** The definition of a light source should be expanded to include a Flare ''or'' an Incendiary weapon. In fact, one Incendiary-capable weapon of any type (AC/HC/HjC/GC), with appropriate Incendiary rounds carried, should be enough for the entire squad to be considered as having a light source. But this may be hard to implement without a special flag and a special pre-search for a valid Incendiary weapon, since AutoCombat normally scores by individual soldiers, not by whole squads.
:: This would take a rewrite. currently the ammo is not used by W: --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
** To be honest I would prefer that each soldier without a light source in darkness is 50% effective, each soldier with a light source (personal or squad), is 75% effective. Meanwhile how about this:

//Darkness - Tested OK (except IN Rkt)
-10 L:-9 u:-2 // Human in Darkness

+10 L:-9 u:-2 W:-27 U:- // Human in Darkness w/Flare -OR-
+10 L:-9 u:-2 W:-4 W:-7 U:- // Human in Darkness w/In ammo and launcher HC/GC-IN -OR-
+10 L:-9 u:-2 W:-8 W:-11 U:- // Human in Darkness w/In ammo and launcher AC/HjC-IN -OR-
+10 L:-9 u:-2 W:-12 W:-15 U:- // Human in Darkness w/In ammo and launcher IN Rkt/Torp

-10 L:-9 u:4-14 // Alien in Darkness

:: Only thing I see is that this ''must'' come at the end. The U:- removes the unit from further consideration. --[[User:BladeFireLight|BladeFireLight]] 19:58, 9 March 2010 (EST)
::: Yes, to use the U: flag for this "OR" function, it must come at the end of the section for humans. That's how I have it my updated AutCombt.txt, these fragments are a bit out of context. It's not critical to have the "OR", it's just nice-to-have as it stops someone cheating by having a flare and one of each loaded incendiary launcher weapon in each hand and in their backpack, to get quadruple score. But hopefully people are unlikely to cheat at AutoCombat, there are easier ways such as the WIN flag. [[User:Spike|Spike]] 20:39, 9 March 2010 (EST)
* The Zombie is rated the same as a tank, a Chrysallid/Tentaculat or an effective Psi alien (-50). I think this is too high, as Zombies are much weaker than those units. A Zombie should be maybe -25.
: Disagree. the zombie should be slightly higher then a Chrysallid/Tentaculat as it will become one and you have to kill it twice. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:: OK good point! [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
* Area effect weapons (HE, IN, Small Launcher) should have at least the same bonus as effective-on-Auto weapons (+5). This is because they can damage/kill multiple targets. (The AC/HjC should not get both bonuses however.)

//Area Weapons. To be Tested. These values are probably too high.
//NB we are not indicating damage here, that is already calculated by the "effective" function. we are just
//factoring in the possibility of hitting multiple targets because of the area effect
//ToDo: needs compensating bonus for aliens (grenades?). should not be cumulative on the same unit.
//Also: add check if weapon is "effective" (at GZ) ?
+25 u:-2 W:-40 W:-41 //U: // Human w/ Blaster/DP Launcher and ammo
+10 u:-2 W:-12 W:-13 //U: // Human w/HE ammo and launcher Sm HE Rkt/Torp
+10 u:-2 W:-12 W:-13 //U: // Human w/HE ammo and launcher Lg HE Rkt/Torp
+10 u:-2 W:-42 W:-43 //U: // Human w/ Stun/Shok Launcher and ammo
+5 u:-2 W:-4 W:-6 //U: // Human w/HE ammo and launcher HC/GC-HE
+5 u:-2 W:-8 W:-10 //U: // Human w/HE ammo and launcher AC/HjC-HE

-25 u:4-14 W:-40 W:-41 //U: // Alien w/ Blaster/DP Launcher and ammo
-10 u:4-14 W:-42 W:-43 //U: // Alien w/ Stun/Shok Launcher and ammo

::Having tested the HC and AC rules, the first rule (HC-HE) does not work unless you remove the ammo specifier W:-6, making it just a test for an HC. But weirdly the second rule (AC-HE) works fine with its ammo specifier in place. Odd. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
::: The problem was due to [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Ammo loaded into a weapon by the game automatically prior to the equip phase is not caught by the W: function. When the ammo is loaded manually, both rules works fine. [[User:Spike|Spike]] 18:16, 13 March 2010 (EST)

* Pistols with the burst mode option should not count as Auto weapons (maybe they don't).
: Burst and snap are based on default stats --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
* Blaster Launchers / DPLs (with ammo) should be worth as much as a tank, e.g. +/- 50 (including the single shot effective bonus it should already get - see suggested rule above under area weapons)
* Should distinguish between tanks. Even with improved armour, a Tank/Cannon is not the same as a Fusion Hovertank. I would suggest a range of 25 for a Tank/Cannon to 75 for a Hovertank/Fusion. Maybe 40 for a Tank/Rocket, 50 for Tank/Laser, 60 for a Hovertank/Plasma?
:This does not seem to be possible with the existing ruleset as all Tanks are unit type 3
::Hmm, byte 42 of [[UNITREF.DAT]] is Rank but also Tank chassis. So this ''might'' allow distinguishing tracked tanks from hover tanks, at least. An alternative approach would be to pick some stat (that has a StatStrings statid) and set it to a different unique value for each tank type. [[User:Spike|Spike]] 18:32, 9 March 2010 (EST)
::This rule set might work:

// Tanks - distinguish chassis types. To be tested
+40 u:3-3 R:0-0 // Tank, Tracked (Cannon, Rocket, Laser)//To Test
+60 u:3-3 R:1-1 // Tank, Hover (Plasma, Fusion) //To Test

* Flying units (either side) should be worth say +/- 5
:Not possible for XCom as no statid makes a distinction between Power Suit and Flying Suit. Would be possible for aliens eg:

-1 T:0- u:6-6 // Flying Alien - Ethereal
-1 T:0- u:8-8 // Flying Alien - Floater
-1 T:1- u:13-13 // "Flying" Alien - Hallucinoid
-1 T:1- u:11-11 // "Flying" Alien - Tentaculat

::On reflection flying is hardly any advantage for aliens, it usually just makes them easier targets with no cover. I guess it helps with avoiding HE splash. [[User:Spike|Spike]] 20:57, 16 March 2010 (EDT)

* If the squad is carrying some Smoke or Dye that should be worth maybe +5 - +10. But since the aliens don't ever carry that, you need some balancing factor for them.

+1 u:-2 W:-20 // +1 per human with smoke grenade(s) (not +1 per grenade!) //Tested OK

* Effective melee weapons should be counted. This is particularly important in TFTD when ranged weapons may be ineffective, e.g. vs Lobstermen.
* Similarly if the enemy are in heavy armour and therefore a soldier/alien does not have an effective weapon, any HE Pack / Alien Grenade / Sonic Pulser should be counted for something (if it is "effective").

//Melee weapons
+5 u:-2 W:1- W:-26 // Human w/o effective ranged weapon but w/ Stun Rod
<s>+5 u:-2 W:3-26 // Human w/ effective Stun Rod (cumulative to above)</s>

::The second rule doesn't work at all, it looks like it counts all items of types 3-6. The "superiority" function (first value before the hyphen) does not seem to operate, probably because it is a melee weapon. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
::: did you try W:255-26 ? not that I know if it would work. AutoCombat doesn't recognize stun rods as weapons when applying damage.--[[User:BladeFireLight|BladeFireLight]] 21:01, 9 March 2010 (EST)
:::: OK, if AutoCombat rates stun rods as doing no damage, the lower range of the W: function ("superiority") will likely never work. So we can't tell whether or not a Stun Rod is "effective" vs the current enemy. In general, the Stun Rod is a pretty effective weapon. So instead we generalise and just use something like this rule set:

//Melee weapons
+3 u:-2 W:1- W:-26 // Human w/o effective ranged weapon but w/ Stun Rod //Tested OK
+3 u:-2 W:-26 // Human w/ effective Stun Rod (cumulative to above) //Tested OK

//It would be nice if AutoCombat checked for the presence of Stun Rods and used them to increase the chance of an alien casualty being stunned rather than killed.

//To Do: check if TFTD melee weapons are included in "effective" weapons by the W: statid.

//Grenades (this needs to be an OR block, so it's not cumulative for each grenade type)
+2 u:-2 W:1- W:-44 // Human w/o effective ranged weapon but w/ effective Alien grenade(s)
+2 u:-2 W:1- W:-22 // Human w/o effective ranged weapon but w/ effective HE pack(s)
+2 u:-2 W:1- W:-21 // Human w/o effective ranged weapon but w/ effective prox grenade(s)
+2 u:-2 W:1- W:-19 // Human w/o effective ranged weapon but w/ effective grenade(s)

-5 u:4-14 W:3-44 // -5 per Alien with effective Alien Grenade(s) (not -5 per grenade!)
:: Only one per unit. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)
::: One per unit tested ok too! [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
* AutoCombat victories should award all UFO Components, not just some Navigation, Elerium and Alloys.
* Every Civilian on the map should be a penalty to XCom of maybe -5, due to the distraction effects of trying to save them / avoid killing them.

-5 u:15-16 U:- // Civilian distraction effect, no further effect //Tested OK

Let me know if I should try to work some of this up as AutoCombat rules. Some of it requires new coding of course, but a lot of it could probably be done with existing rules. [[User:Spike|Spike]] 13:15, 7 March 2010 (EST)
: I dont plan on any changing to the underlying code yet. Your welcome to make up a new set of rules and testing them out. --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
:: OK added some rules above. I have not tested them yet, some of the syntax might not work. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)
::: Syntax looks good to me. Give them a test and let me know how they go.
::: Just a quick note on how AutoCombat works. First the success percent chance is calculated using the AutoCombat StatStrings, dead and unconscious units dont count. (those that bleed to death are considers alive, need to fix this). If it's below AbortThreshold it aborts. If it's 100-199 then change to 90. 200+ change to 95 (success is never a guarantee.) Aliens roll d100, if over your success chance you lose. If You win. Then average damage by each side is calculated based on Loaded weapon being carried and time units. All aliens are killed or stunned by X-Com unit chosen at random. Each Alien gets a chance to wound an X-Com unit based on Success Percentage. Randomly choose unit using random damage (max is average alien damage) Leave at least one X-Com Unit alive. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)

* It would be nice, in a future version of AutoCombat, to have some way of ORing rules together. Using the U: construct as a 'break' only allows you to have one single OR block per unit type (I think). [[User:Spike|Spike]] 20:57, 16 March 2010 (EDT)

* The battle report screen after AutoCombat does not report the number of Alien Artefacts recovered. This gives score I believe. Is it because it's hard to populate whatever data structure the game reads in order to generate the Artefact count? As I understand it, anything you haven't yet researched is an Artefact, and awards some score for recovering it. Anyway, fixing this would be nice-to-have. [[User:Spike|Spike]] 20:57, 16 March 2010 (EDT)

* It would be nice to compensate for the [[Known_Bugs#Equip_Phase_Ammo_Load_Error|Equip Phase Ammo Load Bug]] [[User:Spike|Spike]] 20:57, 16 March 2010 (EDT)

=== Focused Research Help ===

There is a minor and probably unintended consequence of Research Help from Captured Aliens. Normally when you capture a new alien artefact that opens up a new research project, you start the research project - typically with 0 Scientists - and then immediately sell the artefact. The problem with this for Research Help is that you soon have a huge number of projects underway. Then any Research Help tends to get very widely dispersed across all active projects (since it always goes to the project where the biggest reduction can be made, i.e. the projects furthest from completion). The result is that projects are completed only rarely, and progress is made on a broad front but without delivering much. Currently, to avoid this, it is necessary to keep single alien artefacts around in Stores, waiting for the time when the project they open up becomes a priority. In a way, this is interesting and challenging. In another way, it is a headache and take away vital cash.

You might argue that the trick above is a kind of exploit and should not be done. I don't know, maybe. But it is a common practice.

A solution, hopefully fairly easy to implement, is to only consider Research Help for projects which have actually made some progress, e.g. more than 1 scientist day has been applied to them.

In the meantime, maybe put a warning to players in the XCUSETUP script, to keep their research projects to a smaller number when using Research Help from Aliens. [[User:Spike|Spike]] 21:10, 16 March 2010 (EDT)

== Features for 9.8+ - New features ==

=== TFTD Gauss Tank Research Fix ===
*Have the option to make the Gauss Tank require only Gauss Cannon research - this can make it more distinct than the Sonic Displacer and maybe slightly useful for a while
:*I plan on it. just not this version. --[[User:BladeFireLight|BladeFireLight]] 20:53, 18 January 2010 (EST)

=== Improved Base Comes At Cost ===

The Improved Base is supposed to be a "faster start" option rather than a "make the game easier" option. But it does make the game easier, not least because it gives you a load of free base facility improvements. (Not to mention not having to struggle along the first month with only Small Radar and no Alien Containment) To partly avoid making the game easier, please add a sub-option that subtracts the cost of the extra facilities from your starting cash. This should be the ''full'' cost of the extra facilities, not just the difference between e.g. a Small Radar and a Large Radar.
[[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
: I dont have the offsets to the starting money ranges. so I cant do this. --[[User:BladeFireLight|BladeFireLight]] 19:13, 10 March 2010 (EST)
:: I never realised that the starting money is slightly random, I see ranges from $4,125,000 to $4,153,000, in ten samples. Does not seem to depend on Difficulty or starting base location. That is going to be a hard offset to find. [[User:Spike|Spike]] 20:36, 11 March 2010 (EST)
::: I believe there is no "starting money" anywhere to be found, or rather the starting money is effectively zero but it soon changes: the first thing the game does when you begin a new game is perform a hidden monthly report which grants you money from the funding nations. Only way to decrease it is to lower your rating toward countries (you should be able to hack the starting diplomacy data located at 0x4728F8). Or I could just patch the initial money to be negative instead of zero thus providing lower overall starting money. [[User:Seb76|Seb76]] 15:52, 12 March 2010 (EST)
:::: That makes a lot of sense. The initial money is the same as the initial funding. Doh! I should've realised that. The solution to poke a negative number into the money field, prior to the "hidden funding round", sounds a great idea.
:::: Looking at initial money vs funding, your initial cash is always $1,860,000 less than your initial funding. This $1.86M is probably made up of the first 3 rows (only) of your initial Monthly Costs: $500K transport rental, $1200K Interceptor rental, and $160K salary (not hiring fees) for 8 Soldiers. The salary (and hiring fees) for 10 Scientists and 10 Engineers are ignored. The Base Maintenance costs, $224K for a standard starting base, are also ignored. This generosity saves you at least $774K. Could this be considered a bug? Possibly.
:::: The cash value of the XComUtil Improved Base is a whopping $4.5M. This is $1.6M of facilities (Alien Containment, Large Radar, 2nd Living Quarters) and $2.9M of personnel (+10 Engineers, +40 Scientists). $4.5M would wipe out all starting cash and players would begin the game with a negative balance - quite challenging! For XComUtil, it might be best to break improved Facilities and Extra Starting Personnel into 2 options, with each having a sub-option to pay for the improvements. ''"These extra facilities/staff would cost $1.6M/$2.9M, do you want to deduct that amount from your starting cash?"'' [[User:Spike|Spike]] 20:48, 12 March 2010 (EST)

=== Easier Inventory Management ===
Inventory management is one of the things I hate about the first two X-Coms. I was hired to be a commander, not a supply clerk! A mod which made general stores have 10000 space (like Apoc) would be nice.. [[User:Cesium|Cesium]] 21:39, 9 February 2010 (EST)
: The manager of any facility has to deal with generalities of space issues. The clerk tells you if that fancy new tank you just bought will fit. He has to put it in storage and keep track of what shelf the ammo is on. --[[User:BladeFireLight|BladeFireLight]] 22:27, 9 February 2010 (EST)
:: That's the clerk's problem and if he complains too much I'll have him peel potatoes until his hands drop. In any event, the limit doesn't make any sense:
::* General stores size is 8x8x2 (8x8x3 in TFTD) per base defence map, and should have no problem storing more than 50 items.
::: The items taking up 1 item unit are typically about the size of humanoid body. I think it's not unreasonable to have no more than 50 of those in the area that the General Stores takes up.
:::: I can't find a list on the wiki of storage space requirements for items, so I'm not sure which items take up 1 item unit. Typically the main space wasters are Heavy Plasma ammo/Blaster Bombs/Stun Bombs (late game) and/or HWPs and avalanches (early game). These either are definitely not the size of a human body (ammo/Bombs), or shouldn't be stored in stores at all (HWPs gain nothing, and might as well lay around somewhere else in base).
::* The size of a fully built X-Com base is about the size of a city block (judging by comparison of base defence to terror missions), and should easily be able to hold hundreds of items even in the starting base if it's willing to put some stuff not in the general stores.
::* The space limit makes no sense. Why do Blaster Bombs and Heavy Plasma ammo take so much space whereas in the inventory view it doesn't take any more than normal ammo? Who stores <s>mini tanks</s> HWPs in the same compartment as light weapons? And the way X-Com (probably) stores ammo and explosives is scary...
::: As you suggest, extremely powerful ammunition probably requires a lot more space for safe and secure storage in-base, versus on a tactical mission. Imagine what would happen if a Blaster Bomb exploded in a base? Or was stolen? They probably use nuclear warhead style storage facilities for those. And similarly for Avalanche warheads, alien artifacts, Elerium, etc. Segregating dangerous/explosive items from other items probably uses up a lot of overhead in the construction of the storage space - think armoured, bomb-proof lockers and bulkheads, advanced security systems, airlocks, scanners, etc. This is not just like piling stuff up in your shed! And the Commander who left Elerium or Avalanche warheads lying around in his hanger or corridors would justifiably be sacked on the spot by XCom High Command. [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Well, judging by all the explosives in the hangar during base defence and the X-COM 1.0 Elerium bug, Elerium and explosive warheads ''are'' lying around in the base... And all the equipment in the General Stores is stored in ordinary lockers according to the General Stores map ;-) More to the point, if X-COM wants to store explosives safely (judging by said warheads X-COM doesn't care too much) they need a special facility for this, not to store them in the room which also contains all the base's weapons and priceless alien artifacts.

:::: Furthermore, I expect X-COM to improvise on storage in the interest of actually winning the war. X-COM does do this and ignore the limit when manufacturing stuff in-base or getting loot from missions. All that's needed is that X-COM will improvise for transfers too. I can't imagine a quartermaster informing the commander there isn't any room for the new armour and that the troops should go without. Maybe the reason X-COM doesn't pay quartermasters each month is that they keep getting themselves lynched by enraged X-COM troops...
::* Gameplay wise, inventory micromanagement is just no fun, especially in the late game when you have all the cash you need but still has to sell stuff after each combat (which can be prolonged if you haven't sold for awhile), otherwise you can't transfer items to the base where your main team is at.
::* Maybe this entire "stores" thing is a plot by the CFN to force X-Com to share its technology with them by forcing X-Com to sell sell sell. It's not like they pay X-Com the real worth of the technology anyway. [[User:Cesium|Cesium]] 23:47, 9 February 2010 (EST)
::: I think a lot of people do find the inventory management tedious, or unrealistically low. Personally I think it's about right for large equipment (missiles, tanks, bodies), but too low for small arms and personal equipment. And yes, it only reflects using the General Stores modules, not storing stuff at random points in the base - maybe fair enough. If the right offset to patch can be found, the storage limits could easily be raised. The last few bytes of [[BASE.DAT]] could be a good place to look for this offset. BASE.DAT can store up to 9,999 units of each item per base. The total limit for items per base would need to be found by experiment, but 9,999 might work for those who want to ignore inventory. For those who feel inventory management is OK but the limits set too tight, the capacity of each General Stores could be increased from 50 to 100 - assuming we can find the offset for this to patch it. [[User:Spike|Spike]] 19:50, 10 February 2010 (EST)
::::Maybe you can try there:
.text:00439C85 66 81 C5 F4 01 add bp, 500
::::[[User:Seb76|Seb76]] 13:03, 11 February 2010 (EST)
::::: Yes that works nicely. E.g. patch '''66 81 C5 E8 03''' at that location and you get 100 space per General Stores. Thanks Seb! [[User:Spike|Spike]] 18:21, 13 February 2010 (EST)
:::::: Now if only I had the offsets or search signature so we can add that as an options --[[User:BladeFireLight|BladeFireLight]] 18:24, 13 February 2010 (EST)
::::::: UFO 1.4 dos: offset 143748. TFTD 2.1 dos: offset 178462. TFTD v1 dos: offset 176861. TFTD CE: offset 252795. UFO CE: offset 236680. (all offsets are in decimal and point to the "F4 01" value to be patched).
::::::: Patching to "E8 03" has been tested on dos versions (not on CE) and it works. The "base information" screen will display the correct value, though the values to line length scale is such that the line will max at 250. [[User:Cesium|Cesium]] 05:57, 14 February 2010 (EST)
::::::::Are the preceding bytes the same from TFTD 1 and 2x? --[[User:BladeFireLight|BladeFireLight]] 17:26, 15 February 2010 (EST)
::::::::: Yes they are. '''81 C3 F4 01''' is the add instruction. [[User:Cesium|Cesium]] 17:48, 15 February 2010 (EST)
::::::::: Sig for UFO Dos is '''81 C6 F4 01''' --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
:::::::::: Do you also have the preceding bytes for UFO? with the signatures I can create a patch file for all versions --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
::::::::::: I am not sure I understand your question.. Judging the the two UFO versions I have available (1.3 per xcusetup and 1.4) the common preceding bytes are ''80 78 16 07 75 0C 80 78 3A 00 75 06'' (followed by the sig). You could try to use the sig alone - it exists only once in the file. [[User:Cesium|Cesium]] 19:35, 15 February 2010 (EST)
:::::::::::: Offset Locations are something I'm collecting but also the unique series of bytes to find them for the two geoscape/tactical that I dont have. (UFO Spanish, TFTD Italian) I hope to add a lot more options in the in the future. I do feel this one nerfs the storage system anything to get the game up and going faster is always a plus. --[[User:BladeFireLight|BladeFireLight]] 22:01, 15 February 2010 (EST)
::::::::::::: Well, you may want to add another General Stores to the improved starting base if you want to achieve the faster startup effect without "nerfing" storage system for rest of game (I prefer a "nerf" due to late-game reasons). Also, I suggest you add an message in Xcusetup to ask people to get in contact with you if they use an unknown/unrecognized version. [[User:Cesium|Cesium]] 14:27, 16 February 2010 (EST)
::: Inventory management is just as much a pain in the early game, where you almost always are out of space until your 2nd general stores is built. I like realistic constraints, but not tedium. Maybe upping the space per Stores from 50 units to 100 units would be a generally acceptable approach (now that Seb76 has kindly found the offset)? [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Yeah, that would be a great improvement. [[User:Cesium|Cesium]] 15:45, 13 February 2010 (EST)

:I can confirm Seb76 is correct, as ever. The 2 bytes at offsets '''0x39c88''' and '''0x39c89''' in geoscape.exe code for the capacity of each General Stores. Default value is 500 ('''F4 01''') which equates to 50 in-game internal capacity units. (Smallest item uses 0.1 in game capacity so I guess that is 1 unit in internal units). I am not sure about a signature. From what I can tell, the preceding bytes '''66 81 C5''' are unique in geoscape.exe, which seems pretty odd, so someone else should verify that. [[User:Spike|Spike]] 19:48, 13 February 2010 (EST)
:: Yes it is unique to CE. it does not exist in any DOS EXE, but "F4 01" can be found in 79 places. Trial and error could locate it. --[[User:BladeFireLight|BladeFireLight]] 20:50, 13 February 2010 (EST)

=== AutoCombat ===

==== Firepower Factors ====
You might want to consider replacing the weapon offensive weighting factors for Autocombat with some factors that are (inversely) related to the [[Weapon_Analysis#Quantitative_Analysis|% TUs Per Kill]]. I've tabulated these for each weapon (including tanks) vs each alien race. You would still need to account for Psi, light/darkness, and XCom armour. Plus you would need a similar offensive factor for the aliens' attacks. But I could probably help with that, I have the data that's directly comparable to the % TUs per Kill for XCom weapons. [[User:Spike|Spike]] 22:06, 12 February 2010 (EST)

==== AutoWithdrawal ====

One of the most tedious things you can try to do in XCom is to scavenge the battlefield and retreat to landing craft for an Abort. A great option would be an AutoWithdrawal, similar to an AutoCombat, but with an easier threshold of XCom vs Alien combat power.

Basically it would scavenge all loose equipment off the Battlescape - dropped friendly and alien items, friendly and alien corpses and wounded, all go back into the landing craft. Elerium, Alloys, and UFO Components would not be recovered, as this is (normally) impossible apart from full tactical victory. All friendly troops return to the landing craft. Friendly losses, and equipment recovered, would be proportional to the offensive factor ratios but much more favourable than for AutoCombat. E.g. as long as XCom factors were at least equal to Alien factors, they would be able to scavenge everything and recover without casualties. If the aliens were stronger than XCom, they would only recover part of the scavenged equipment, and risk partial casualties, at say one third the rate of AutoCombat. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

: It's too easy compared to actual game IMHO. Every time a battle went FUBAR for me, it got FUBAR all the way and I was lucky if I could salvage my own team/equipment and maybe a single alien weapon/body. An AutoWithdrawal without salvage might be useful, but perhaps instead we should change AutoCombat failure mode to work better (e.g. Make some X-COM people survive a failed AutoCombat, depending on strength vs aliens). [[User:Cesium|Cesium]] 15:00, 7 March 2010 (EST)

:: Yes fair point. I was not thinking of the FUBAR situations, and you are right about how hairy those are. I was thinking of the situation where you control a certain part of the battlefield, but you either don't want to go on an endless hunt for the last few aliens, or you pretty much know you can't take on the aliens that are left (e.g. in the UFO or some other stronghold) without getting creamed. You can exercise a safe withdrawal, it's just tedious to carry out all the bodies and equipment. But it's pretty hard for an AutoCombat algorithm to detect which of those situations it is - FUBAR, boredom, or tactical withdrawal. I'll have to think about that, there may be no realistic solution at all. And there is the existing "teleport loose items back to base" command line option to XComUtil, maybe that's enough. [[User:Spike|Spike]] 16:08, 7 March 2010 (EST)

=== Tougher UFOs ===

[[Wish_List_(EU)#Tougher_UFOs|Tougher UFOs]]
As this is entirely implemented by patching data and data files it is a good candidate for XComUtil rather than [[UFO Extender]].
: That would definitely make the game harder. 9.7 is about the installer and the bug fixes. This would be a good candidate for 9.8. --[[User:BladeFireLight|BladeFireLight]] 01:38, 19 February 2010 (EST)
:: Cool! [[User:Spike|Spike]] 02:25, 19 February 2010 (EST)

=== Rebalanced Craft Weapons ===

This fits under the "making useless things usefull" category. It would be a 9.8 or later option. The idea is to make the Cannon, Stingray, Laser Cannon and Fusion Ball Launcher useful. Hopefully it breaks up the monotony of Dual Avalanches followed by Dual Plasma Beams, every game.

There is one common element in the approach, and two options. The common element is to fix the stats on the Fusion Ball Launcher. The two options are to use a stat-based approach, or a cost-based approach, to fix the other weapons.

NB This proposal is still a draft and will need tweaking, but I've got it to the point where it is worth discussing. Feedback is welcome!

''(Ultimately, the Plasma Beam still ends up being pretty much the optimum weapon in the end game. To mitigate this, it is a good idea to select the existing Alternate Energy Weapons Manufacturing option in XComUtil.)''

==== Fusion Ball Launcher ====

Increase the ammo capacity from 2 to 3. Don't mess with the damage. Job done.

See [[User:Spike#Fusion_Ball_Launcher]] and discussions linked from there.

==== Cost Based Approach ====

This uses historically realistic costs to restore game balance between different craft weapons. The stand off advantage of Avalanche missiles is now purchased at a price which is significant in terms of XCom budgets and mission yields. Stingrays and Cannons become significantly cheaper alternatives. The Laser Cannon, with similar capabilities to Stingrays but free to operate, also becomes very attractive. Mounting dual launched weapons becomes a very expensive luxury.

*Increase Avalanche missile Purchase cost to $386,000
*Increase Stingray missile Purchase cost to $125,000
*Leave Sell prices unmodified (to avoid creating a cash reservoir at the start of the game)
*Leave Launcher buy/sell prices unmodified

See [[User:Spike#Cost_Based_Rebalancing]]

==== Stat Based Approach ====

This provides a benefit trade-off to shorter range weapons, by increasing their firepower or effectiveness relative to longer range weapons.

*Increase Cannon stats to 15 Damage, 50% hit. Firepower is tripled, slightly ahead of (unmodified) Avalanches launching in Aggressive mode. Increase rearming rate to 200.
*Increase Stingray accuracy to 80%. Decrease Avalanche accuracy to 60%. Stingray now has 50% more firepower relative to Avalanche. Increase Stingray rearming rate to 2, so a full craft can be re-armed in the same time period with either weapon (instead of twice as long for Stingray).
*Increase Laser Cannon stats to 100 Damage, 50% hit. Firepower is doubled, 20% more than (unmodified) Avalanches launching in Aggressive mode, 2/3rds of Plasma Beam firepower.

To avoid advanced XCom aircraft exploiting the extra firepower of the Cannon weapons and disregarding the return fire from UFOs, this is best used alongside the Tougher UFOs option.

See [[User:Spike#Stat_Based_Rebalancing]]

=== Rebalanced Infantry Weapons ===

See [[User:Spike#Balancing_Infantry_Weapons]]

Primarily this means making the Rifle a bit stronger, and probably making the Pistol a bit weaker.

=== Advanced Laser Cannon ===
The "Advance Laser Weapons" option only nerfs the Laser Cannon (raising cost and reducing profitability but not changing any damage/range values. Previously xcomutil modified them unconditionally). I wonder if that's the best result - should damage and/or range be raised to make the cannon useful or to compensate? Most commanders don't use the cannon as is, but maybe it's prejudice... [[User:Cesium|Cesium]] 21:36, 16 March 2010 (EDT)

: Note this isn't a "rebalancing issue" compared to the other weapons - I'm talking about (maybe) balancing for the increased cost of production and lower profit. [[User:Cesium|Cesium]] 21:41, 16 March 2010 (EDT)
:: I guess the craft weapon rebalancing options listed just above, either the cost-based or the stat-based, would help out here. The intent of "Alternate Laser Weapons" is purely to make the game harder, which it definitely does. Is it necessary to "balance" something that deliberately makes the game harder? I don't think so. But I do think the general principle should be that there are no "pointless" items of equipment. So either way the Laser Cannon deserves a buff. Personally I never thought the previous XCU buff to Laser Cannon made it worth using. What it gave with one hand (range increase, but still lousy range), it took away with the other (firepower). I would actually rather have the standard Laser Cannon than the old XCU "buffed" one. [[User:Spike|Spike]] 22:11, 16 March 2010 (EDT)

==See Also==

[[Wish List]]

= Completed Wish List Items =

=== BFG Default To Unchanged ===

Is it possible when using the BattleFieldGenerator, for it to detect the actual conditions for the mission (terrain, enemy craft, and light level) and offer these as defaults? [[User:Spike|Spike]] 08:22, 13 February 2010 (EST)
:Press The esc key at the prompt. (Line 719 in Xcomutil.txt, not that I expect anyone to read the manual :) ) Enter should also work. --[[User:BladeFireLight|BladeFireLight]] 12:34, 13 February 2010 (EST)
:: RTFM eh? My biggest failing. Maybe you could add an explicit prompt "Esc or Enter = [whatever the unmodified value would be]". [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)
::: From what I can see, hitting Escape during BFG makes it continue with ''all'' values reverting to the original conditions. It would be nice to be able to select some but not all original conditions. My main use of this is to turn a night mission into a day mission without the hassle of keeping the landing craft hovering around until the terminator crosses the landing site. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
:::: You could just use the force all daylight option.
:::: After reviewing Scott's code. Esc leaves all setting as-is. Pressing enter or any other key not listed will randomly choose for you. I will see if I can change enter to leave as is. --[[User:BladeFireLight|BladeFireLight]] 11:00, 7 March 2010 (EST)
::::: This has been added --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)

= MISC =

* It's actually quite hard to downgrade to DOSBox 0.72 in Ubuntu. Only 0.73 is offered, there is no ability to Force back to a lower package level with Synaptic Package Manager. Unix guru skilz are required to rollback to 0.72, and I guess 0.74 is not around yet, or not packaged for Ubunut APT? Is there any way to fudge around this, e.g. by providing the command line arguments in an optional text file for xcusetup.bat to parse? Having said that, even with no command line arguments, xcusetup hangs on my 0.73 DOSBox while executing SDUMP. I had to reboot in Windows to run xcusetup.bat - something that is only possible on a dual boot machine / Wubi machine. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
** Try using a different batch interpreter like 4DOS [http://www.4dos.info] to execute xcusetup inside DosBox. I tested this throughly before under DosBox/Linux and it works well with recent 9.7 builds. I suggest running "config -set cpu core=dynamic" and "config -set cpu cycles=max" before xcusetup to speed it up (xcusetup doesn't detect DosBox when 4Dos is run, so it doesn't run these automatically unlike normal DosBox case). [[User:Cesium|Cesium]] 09:48, 7 March 2010 (EST)
** Oh, and downgrading isn't that difficult: Get a dosbox 0.72 deb, and run "dpkg -i" on it, and then do "echo dosbox hold | dpkg --set-selections" to prevent future upgrades. [[User:Cesium|Cesium]] 09:50, 7 March 2010 (EST)
** Another option is to install the dosemu package, and run xcusetup under that. EU/TFTD can be run under that, but it doesn't work as well there. (Oh, and there's no mount command there. UFO/TFTD needs to exist under ~/.dosemu/drive_c which is C:) [[User:Cesium|Cesium]] 11:42, 7 March 2010 (EST)

:Thanks Cesium I will check this out. I still think it would be good to have a solution that works for people who are not knowledgeable with the unix command line though. [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)

:: Why use Linux if you dont know how to use the console? It is a text mode OS with a separate GUI. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)

::: Well Ubuntu is a bit different, as it's supposed to be an OS for the general public, where you never need to touch text mode! Incidentally I can't find any DEB or other packages for 0.72, all that is available on the DOSBox website is the source code. They really don't seem to realise that 0.73 is buggy! So I guess I will need to '''make''' it. Or just wait for 0.74 as I think it's out soon. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)

:::: See [http://archive.ubuntu.com/ubuntu/pool/universe/d/dosbox/] for 0.72 debs. Unlike Windows, package systems in Unix land are centralized, so best location to search is typically a package server mirror or a distro mirror, not a vendor's website. [[User:Cesium|Cesium]] 17:36, 9 March 2010 (EST)

Talk:XcomUtil

2010-03-17T01:38:52Z

BladeFireLight: /* Open Bugs */

=XcomUtil 9.7 Beta=

9.7 Beta is available on www.bladefirelight.com

==Release Notes==

This is a Beta, so backup your files before using. And check back often for newer builds.

New in this version.

*Major overhall of the installer (XcuSetup) and the inclusion of 16/32bit exe's to support both DOSBox and Windows Vista/7 x64.
*New subfolders added to hold supporting files making the install cleaner
*New XcuSetup command line arguments were added to XcuSetup allowing for silent install and uninstallation.
*New XcuSetup option for debugging the install (XcuSetup debug) creating XcomUtil\debug.txt.
*New command line argument "nobackup" skips backup only if it has been ran atleast once.
*XcuSetup can now have minimal impact on the game.
**Almost all options default to NO (Only Split Windows EXE set to Yes).
**Almost all changes are now prompted for (skyranger guns, interceptor as transport, Disjointed Base Bug, etc...).
***Items still done by default:
***Copy protection questions set to 0000000 for UFO 1.0-1.3 and X-Com 1.0
***Difficulty bug fixed in UFO 1.0-1.4 and X-Com 1.0-1.4
***Unique names for all maps in TFTD, Used for Hybrid Games
***Placement of X-Com Units on the Battlefield based on XcomUtil.cfg
***MIA Recovery on Won Combat (Units under mind\MC control when last controling alien killed are returned to X-Com control)
*XcomUtil.cfg is now pieced together and overwritten by XcuSetup (see XcomUtil\XcomUtil.txt for how to make permanent changes).
*All game files are restored to the pre-XcomUtil state each time XcuSetup is ran. Any modifications by other utilities will have to be re-applied.
*Vista/Win7 patch now an option for XcuSetup.
**This will fix the blank screen issue.
**Updated to support the split EXE.
**Will set X-Com to use CPU 0.
*XcuSetup attempts to fix UAC issues by resetting folder permissions.
*A number of community made fixes are included and selectable with XcuSetup.
*Support for the DOS/Window STEAM Install.
**Installer will detect STEAM and change steam launcher to start the XcomUtil Steam Menu (can be re-installed with XcomUtil\SteamSetup.bat
*Out of the box support for UFO Extender. XcuSetup will detect it and ask if you want RunXcom to use it.
*XcuSetup can be run from windows and RunXcom run from DosBox
*Hybrid Colors updated based on BombBloke's pallets.
*EQL flag allowed any turn.
*Add Xcom UFO Italian Support.
*Auto Combat will not run on second half of two part using first parts saved data.
*Auto Combat will no longer run if combat was won.
*MIA Recovery on won combat only.
*MIA Recovery no longer recovering units that bleed to death.
*Auto equip no longer triggers on second part of 2 stage missions.
*Combine clips skiped if between stages of 2-3 part missions.
*Updated f0dders ReadMe per his request. (XcomUtil\bugfix-readme.txt)
*Add-on support added. see XcomUtil\XcomUtil.txt and XcomUtil\Addon\Example.txt
*Prompted Terrain in BattleField Generator allows to abort or use of current setting.
*Beta versions include
**XcomUtil\XcomUtil.log includes lots of debug info
**XcomUtil\Debug.txt created by default (Release will need "debug" command argument)

Removed from this versions

*New Desert and Urban terrain. (Will be added once I have a C++ version of the Java Terrain Edit.)
*Expanded capacity Laviathan, Hammerhead and Avenger (maps avalible in XcomUtil\Patches)

NOTE: If you use DosBox, this requires DosBox 0.72 (Does not work on 0.73 due to buffer overflow setting ERRORLVEL)

===Build 435===

Original Sound Effects from UFO were re-sampled to work with 1.4 and CE.

*Add Category to option headers.
*Improve randomness by using current time instead of game date/time in srand()
*Added Option to keep Current terrain/UFO to BFG.
*Original UFO 1.2 Sounds for Geoscape and Tactical added as an option for UFO 1.4 and CE.
*Force Split EXE on STEAM. Fixes issues with setup failing.
*Reset Laser/Gauss craft weapons stats to be default.
*Example addon now uses different flag extension to avoid deletion by XcuSetup
*fix issue with Lab Screen on DosBox always screening

==Beta Discussion==

===Build 435===
: I hope the improved randomness doesn't apply to the Aliens' d100 during AutoCombat. Otherwise, one could load-scum for success. [[User:Cesium|Cesium]] 06:33, 11 March 2010 (EST)
:: Actually it does. I can see what your getting at, but why do it that way. if you want to win the "WIN" command line option is faster and you get better loot from the UFO. also using the combat date would also swing the other way with an unwindable autocombat with an fully loaded avenger vs a survey ship. --[[User:BladeFireLight|BladeFireLight]] 17:41, 11 March 2010 (EST)
: In the setup question for sound files: "were replace" should be "were replaced". [[User:Cesium|Cesium]] 06:53, 11 March 2010 (EST)

----

Excellent! For the first time xcusetup.bat completed for me in Dosbox in Ubuntu. Previously the SDUMP commands were hanging it.

For the first time ever, I ran the sound setup utility. It did not response to any cursor keys, enter, tab, etc. The only key that worked was Escape, and I'm not sure what this did.

One point on the xcusetup.bat script - Ctrl C does not seem to work. On all those "press a key to continue" prompts could we also have "or 'q' to quit"?

[[User:Spike|Spike]] 18:41, 13 March 2010 (EST)

: "press a key to continue" is the Pause command. Ctrl + C works fine in Windows. DOSBox does not. The reason for the use of Pause is because an number of new players kept exiting setup early when I gave the option. Aborting early makes a mess and I dont want to have to troubleshoot it for Joe user. --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
:: OK I see, that makes a lot of sense. [[User:Spike|Spike]] 06:52, 14 March 2010 (EDT)

----

Does the SHP flag still work, after the changes to how XCOMUTIL.CFG is assembled? I just tried it, after rerunning XCUSETUP.BAT (Dosbox 0.72 under Ubuntu). XCOMUTIL SHP produces no output. XCOMUTIL SHP:CFG WRT writes GEOSCAPE.EXE, but nothing seems to change. During XCUSETUP I see the expected "Patch applied, ship data updated from CFG" (or whatever). [[User:Spike|Spike]] 17:40, 16 March 2010 (EDT)
:: Yes it works fine. your mistyping the command. it's "xcomutil ufoexe shp:cfg wrt" Second argument must be the target folder. Line 42 and 1266 of XcommUtil.txt.
::: Thanks! And I thought I'd read the manual. [[User:Spike|Spike]] 20:31, 16 March 2010 (EDT)

==Open Bugs==
*There's no Italian text for the Alternate Laser Weapons option. Applying the patch seems to work, but it displays the text for the default laser weapons.
:*Anyone want to translate the text into Italian? --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
*The number of aliens in the mission report is inconsistent with the number of live aliens captured per research help. See [[Image:Alien_numbers_mismatch.zip]] and [[Image:Dead_alien_count.zip]].
* Morale is random at start of second stage after autocombat of first stage?
:* Actually Morale is used as the clip size and time units as the weapon damage. Don't ask me why. It would take a major re-write of auto combat to fix this. --[[User:BladeFireLight|BladeFireLight]] 19:34, 23 February 2010 (EST)
*RPL bug, when you turn creatures into Gill Men, they are reported as Snakemen
:* Reported how? Is this consistent? The name's used are from xcomutil.cfg. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
::*Sorry. It's reported in morale failure pop up messages. Though maybe this is an original TFTD bug rather than an XComUtil bug. [[User:Spike|Spike]] 19:21, 21 February 2010 (EST)
:::* See this: [http://www.youtube.com/watch?v=uGlSghf7aTU]. In that case, all Gill man (were lobster man before RPL) were reported as snakemen.. [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST)
*RPL bug, when you turn Lobstermen into other creatures (e.g. Gill Men), they are very hard to kill despite having the stats of the creature they turned in to. Possibly they are keeping their damage resistance? Maybe the race is stored in more than one place, for different purposes, and XComUtil misses one of these places?
:: I will look into this --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: The RPL only changes the basics; The race, rank, name, TimeUnits, Health, Energy, Reactions, Armor(front,back,left,right), Strenght and PSI Strenght. All other stats are left as-is. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
:::: I'm not so sure about this. See 05:00 mark at [http://www.youtube.com/watch?v=y-_zLdjhUHI]. The armour doesn't match the one Gill man should have (per UFOpaedia, at least). [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST). See also 04:17 mark at [http://www.youtube.com/watch?v=z5LfzFSkRnI] for reason to suspect resistances aren't always changed. It's possible he just was unlucky though... [[User:Cesium|Cesium]] 19:53, 21 February 2010 (EST)
::::: Actually the function is something like this
<pre>#define UpdateStat(x,y) pur->x = (unsigned char) \
( ( (unsigned int)pur->x \
* (unsigned int)pasTo->y \
) / (unsigned int)pasFrom->y )
UpdateStat( TimeUnits0, TimeUnits );
UpdateStat( Health0, Health );
UpdateStat( Energy0, Energy );
UpdateStat( Reactions0, Reactions );
UpdateStat( AFront0, AFront2 );
UpdateStat( ALeft0, ALeft2 );
UpdateStat( ARight0, ARight2 );
UpdateStat( ARear0, ARear2 );
UpdateStat( AUnder0, AUnder2 );
UpdateStat( Strength, Strength );
UpdateStat( PsiStrength, PsiStrength );
</pre>
::::: the 0's are values at start of tactical.
::::: I read that as Current(from game_x) * Target default(from xcomutil.cfg) / source default (from Xcomutil.cfg) so the stats will be different. --[[User:BladeFireLight|BladeFireLight]] 21:33, 21 February 2010 (EST)
:::::: I'd have expected Current(game_x) == Source default if applied on first turn? This would end up with result == Target default, no? Hmmm... We already saw some compiler multiplication wackiness with the research help bug. Possibly this affected these calculations too?
:::::: As for the code, you're not updating PsiSkill, so non Psi-users can't get Psi after RPL. [[User:Cesium|Cesium]] 22:03, 21 February 2010 (EST)
::::::: I didn't write this. I'm amusing Scott did it this way to adjust for difficulty because XcomUtil.cfg has the beginner level stats. It need's an overhaul to use the full stat entries including the unknowns adjusted correctly for the level. Something for latter. --[[User:BladeFireLight|BladeFireLight]] 22:09, 21 February 2010 (EST)
:::::::: For this specific issue I think you will need to update 0x37 of [[UNITREF.DAT]] which is the Damage Modifier. For the general problem you will need to update the Psi Strength and also Firing Accuracy, energy regen rate, movement class... loads of stuff. And of course LOFTEMPS. So with current RPL not changing LOFTEMPS, changed aliens are the wrong size and shape probably. This would be visible using the LOFTEMPS map viewer I suppose. [[User:Spike|Spike]] 18:39, 9 March 2010 (EST)
*[[Known Bugs#XComUtil Inventory Stacking Bug]]
:* I hope to overcome this but Scott's notes point to a technical limitation. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*Fusion Ball Launcher fixes - detailed discussion moved to [[Talk:Fusion_Ball_Launcher#XComUtil_FBL_Issues]]
** Profitability (inconsistency item) - becomes most profitable item when using Alternate Laser (and Plasma) Tech option. Recommendation - workshop space and Engineer hours x10, 4 Alloys, 20 Elerium. And make it more useful (see below).
** Usefulness ''(wish list item)'' - perceived as being not very useful with standard stats. Recommendation - increase ammo to 3. Leave damage as-is to allow for Tougher UFOs (see Wish List).
*Zrbite lying around in odd places. Objects lying around in odd places in general - these are map modifying errors, probably only occur when customising terrain etc.
:: Will be part of an overhaul of the BFG --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*There is a small problem in editing/customising craft using '''XComUtil.cfg'''. Certain X-Com craft weapon values - the rate of fire value - can't be set. Or more specifically, they can be set (patched) in the executable but it has no effect in the game. To avoid confusion they should perhaps be removed from the format of custom craft, or commented out. (This rate of fire patching ''might'' work on UFOs, haven't tested it).
:: Can you be more specific? --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: There is a section in '''xcomutil.cfg''' which is used for patching XCom craft weapon characteristics. This is where Scott changed values for the Laser Cannon, etc. Probably very few people use these fields. I only used them because I was doing research into the game mechanics. One of the values changed in this section is the reload time. These values are present in the executable, and can be patched, but patching them has no effect (other than to change the UFOPaedia entry). The reload time seems to be hard coded elsewhere in the executable, based (broadly) on the class of weapon. So you might want to comment this column with an a note saying "cannot be modified for combat". On the other hand I could be wrong, or someone still might want to modify these fields. Discussion is at [[Talk:UFO_Interception#Observed_Rates_of_Fire]]. Offsets are at [[Talk:GEOSCAPE.EXE#Craft_weapon_stats]]. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
:::: Or maybe change these display-only values so that they reflect the [[Talk:UFO_Interception#Observed_Rates_of_Fire|observed reload rates]]? I am not yet 100% sure I have got these right, might want to wait until I do some more confirmation tests. [[User:Spike|Spike]] 15:26, 22 February 2010 (EST)
*EQL only works on turn 1 (see discussion above)
::: Added to my to do list. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*Research Help from Captured Aliens awards research help without checking first if you have Alien Containment at the base of origin. Resulting in dead aliens helping you with your enquiries! Possibly only applies to AutoCombat? [[User:Spike|Spike]] 21:05, 14 March 2010 (EDT)
:: Ideally it would not only check for containment but also have a research item for it and check on how many scientist days had been reduced since the last combat and use that as a value for how much you get form the aliens still in containment. But that could just be a pipe dream. Checking for containment for now is a good idea. --[[User:BladeFireLight|BladeFireLight]] 15:35, 16 March 2010 (EDT)

----

I have a strange issue. I succeed in an AutoCombat terror mission (117%) but the mission is resolved partially as if I had actually aborted the mission - all Civilians die, even though I could see 3-4 alive, my 13 soldiers outside the Skyranger go MIA, even the one who was killed by AutoCombat, and only my sergeant standing in the Skyranger makes it back. The problem is repeatable. On one occasion the sergeant was killed randomly by AutoCombat, meaning that the Skyranger flew back by itself, empty. Obviously this should never happen.

I've uploaded the [[Media:MIAoverload.zip|AutoCombat game save file]]. Incidentally this shows how to 'game' the current AutoCombat rules: Take maximum soldiers, no tanks. You give everyone a Rocket Launcher, they only need 1 Lg Rocket in it. Until you get Heavy Lasers, then replace the Rocket Launchers with them. Next replace with Heavy Plasmas. This approach always gives you maximum damage per soldier, and thus maximum chance of getting the +15 bonus for the W:3- rule. [[User:Spike|Spike]] 19:02, 15 March 2010 (EDT)

:: Hmmm. Scott's MIA recovery raised an army of undead from those that died of fatal wounds. Mine only effects mind controlled units. The issue is telling who is dead and who is left behind.

Units from your saved game looked like this(on by Autocombat).

Shuji Okabe: Left behind (Health > 0)
[[UNITPOS.DAT|UnitPos]][0x0A] 1.0.0.0.0.0.0.0 (bit 2 == 0 Unit on the ground[dead or unconscious])
[[UNITREF.DAT|UnitRef]][0x78] 0.0.0.0.0.0.1.0 (bit 1 == 0 Unit Alive)
Yoko Fujimoto: On Craft (Health > 0)
UnitPos[0x0A] 1.1.0.0.0.0.0.0 (bit 2 == 1 Unit Standing [Active])
UnitRef[0x78] 0.0.0.1.0.0.0.0 (bit 1 == 0 Unit Alive)

From Bomb Blokes undead army MIA Test save (won by killing aliens).

Spencer Bryant: Lived (Health > 0)
[[UNITPOS.DAT|UnitPos]][0x0A] 0.1.0.0.0.1.0.0 (bit 2 == 1 Unit Standing [Active])
[[UNITREF.DAT|UnitRef]][0x78] 0.1.0.0.0.0.0.1 (bit 1 == 0 Unit Alive)
Oscar Thompson: Bleed to death (Health > 0)
UnitPos[0x0A] 0.0.0.0.0.1.0.0 (bit 2 == 0 Unit on the ground[dead or unconscious])
UnitRef[0x78] 0.1.0.0.0.0.0.1 (bit 1 == 0 Unit Alive)
Virgil Hudson: Killed by Aliens (Health == 0)
UnitPos[0x0A] 0.0.0.0.0.1.0.0 (bit 2 == 0 Unit on the ground[dead or unconscious])
UnitRef[0x78] 1.1.0.0.0.0.0.1 (bit 1 == 1 Unit Dead)

So right now I'm at a loss of how to detect tell the difference between thoes that are left behind and thoes that are dead.

:There must be something odd about my save game that takes 13 live soldiers and makes them all MIA on an abort. I wonder if it is something to do with the one guy who is still on the transport. I'm sure I've never seen an MIA after an AutoCombat victory, or defeat, before. Of course, after a victory, no one should be MIA. In a defeat, in theory AutoCombat could (but doesn't?) allocate some soldiers as MIAs. For the bleeding to death problem, perhaps you could check whether Health <= Fatal Wounds. In the normal game this might be an ambiguous borderline case? Treat it unambiguously - kill any soldiers matching that condition. In XComUtil after-combat messages, perhaps emit the message "So-and-so died from his/her wounds aboard the transport".
:But I guess the problem is not what XComUtil does, but how to "communicate" back to the game engine that the soldiers are alive and well and not MIA? Surely the game's logic must be '''first''' to determine if the battle was aborted, and only then to decide who was left behind on the battlefield vs who died vs who was on the transport and got home? Surely Scott's logic must intercept this abort flag, and ''then un-set it''?.
:By the way, in the listing above I'm not sure whether the least significant bit is at the left or the right? [[User:Spike|Spike]] 20:31, 16 March 2010 (EDT)
:: I'm guessing it's a bitfield not a number, so LSB/MSB doesn't exist. [[User:Cesium|Cesium]] 21:27, 16 March 2010 (EDT)
::: Yes it's a bit field. I linked to the wiki page with the description. The game engine doesn't need to tell why some one got removed from the game. Tatical calculates the score. --[[User:BladeFireLight|BladeFireLight]] 21:38, 16 March 2010 (EDT)

==Fixed Bugs==
*don't prevent patching windows version while running in dosbox, or vice versa
:*Fixed: XcuSetup can be run independantly to the OS RunXcom is used in.
*4DOS and MS-DOS 5 dont like "-" in variable names.
:*Fixed
*Enviroment space reached quickly on most DOS envirments.
:*Partly Fixed: Requirement has been drasticly reduced to to ~1024 use of Command.com /e:xxxx still may be required
*EnvClean.bat has an error in line 172: ser -> set.
:* Fixed in build 204.
*ANSI escape sequences aren't necessarily supported on a real dos environment/emulation
:*Fixed: ANSI only used in DOSBox
*If all the aliens are down (some of them stunned), the last save is named "AutoCombat" and I end turn, XcomUtil may still run "AutoCombat" phase. This may have slightly different results than end of combat would have had
:*Fixed: Autocombat will not run if you have already won.
*A fully loaded Hammerhead's initial deployment has three aquanauts outside the craft.
:*Fixed: the unit placement for the default 12 unit craft has been added to XcomUtil.cfg
*Select terrain: dosent apear untill after I select a terrain in BFG prompting
:*Fixed
*geodata/obdata.dat get's trunkated with slecting any improved weapon.
:*Fixed: This happend because a full backup did not complete but XcuSetup does not detect it. Backup script's changed to avoid xcopy timeout on some versions of DOS. (Backups are required by SDUMP to apply patches)
*I get this error dureing backup "16-bit MS-DOS Subsystem NTVDM has encountered a System Error The handle is invalid."
:*Fixed: All NT based OS's now useing 32bit EXE's
* You can get X-COM MIA if you abort a mission, even if everyone is in the exit. Possibly a second stage bug only? See [[Image:X-COM_MIA.zip]]. Note that this only affects the report - after mission all the X-COM troops are still available.
:*NOT Fixed: This happens even on vanilla TFTD with that save. Given it's TFTD it could be an issue with the mapfiles. --[[User:BladeFireLight|BladeFireLight]] 00:23, 24 February 2010 (EST)
*Various second stage bugs - ammo clip recovery, crashes after autocombat of first stage, etc. Mainly for TFTD, but possibly Cydonia in UFO is also affected.
:*Fixed: Clip recoverty no longer ran between parts of 2-3 part missions. Autocombat only crashes on two part if you are aborting the second stage and the save in slot 10 is from the first stage. Stage comparisons are now done to abort autocmbat if you do this.
*Removal of Small Scout map / Survey Ship map, making it impossible to do these Battlescape missions.
:*Fixed: 9.7 only removes the maps if you use the BFG. I hope to have 9.8 not remove them at all. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*The XcuSetup prompt for the option of less-profitable weapons manufacturing is misleadingly called "new laser weapons".
:*Fixed: Renamed to Alternate Lasor weapons.
* SteamSetup.bat won't run from DOSBox. It says "This needs to be run from Windows". Though, does it make any sense to run SteamSetup.bat under DOSBox (eg for a linux system with no Steam)? [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
:*NOT Fixed: STEAM dosent give access by default to the command prompt. If you know how to add that then you should know enought of DOS not to need the STEAM menu. --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
* '''cfg/ShipDefU.txt''' has the XCU values for improved Laser Cannon (35/35/35), not the original values (21/35/70). Is this correct - is this file supposed to be the original defaults? [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)
:*Fixed: I was unawhare that this had been changed. The weapons are not prompted for any change so they should not be changed. I'm reseting them all to defaults and looking to see if Scott had anything about them in the notes. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
* standalone patches the fix the difficulty bug
:*Partialy Fixed: 9.7 min install is the dificulty patch and changeing Copy protection questions to all 0's.
*Version detection issues with obscure versions (Italian, 1.2a, etc.) causing corruption or lack of patching.
:*Fixed: Added support and patching offsets.
*Various default options make the game easier, not harder (''harder'' being the intent of XComUtil, right?). These should not be defaults. (More discussion at [[Talk:Enemy_Unknown_Extended#Standard_Config_Discussions]]) E.g.
::: 9.7 only has 3 items on by default. Remove copy protection. Fix Difficulty bug and Split EXE (split EXE can be skiped but not the others). All other options are default to NO.
::: As for the intent of XcomUtil. Scott added features to
:::# Increase difficulty.
:::# Make useless items useful.
:::# Get the game Started faster.
::: I have added:
:::# Don't make unwanted changes.
:::# Fix game bugs
:::::Yes all of those are very sensible. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
::::Latter versions of XcomUtil will turn the last two forced items to prompted. with only the Difficulty bug and the split EXE as Default=Yes. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Basic tanks using advanced tank stats
**Improved High Explosive - very powerful in favour of X-Com, especially as alien spawn points and routes aren't set up to cover holes in UFO hulls.
:*Gauss weapons have infinite ammo
::: 9.7 has a second option to just the increase power to closer match UFO.
:*Using fighters as transports (carrying soldiers)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Using transports as fighters (weapon hardpoints)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Improved Heavy Laser / Heavy Gauss. OK, this should maybe be a ''recommended'' option since the unpatched weapons are nearly pointless. But, it does make the game easier. [[User:Spike|Spike]] 20:12, 7 February 2010 (EST)
*FreeDOS breaks horribly dering Setup
:*This is most likely an issue with the limits of FreeDOS.
:** Actually, this seems to work well for the latest builds (tested with FreeCOM 0.84 under dosemu). [[User:Cesium|Cesium]] 18:07, 14 March 2010 (EDT)

=XComUtil Wish List=
Things that are not bugs or inconsistencies in XComUtil but would be Nice To Have

== Features for 9.7 - Interface, consistency and bug fixes ==

=== Categorise Config Options ===

For each option, in the prompt, note which category of option this is, according your list above. E.g. faster start, making the game harder, making useless items useful, bug fix, variant game, etc. [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)

:Actually it might be even better to organise the options questions into sections, thematically grouped by these categories. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

:: Items are currently sorted like this.
* Windows EXE
* Game Fixes
* Game Mods
** Sound
** Craft
** Base
** Equipment
** Research
** Units
** Battlefield
** Alien Craft
** Misc
--[[User:BladeFireLight|BladeFireLight]] 19:25, 10 March 2010 (EST)

=== Improved Pistol Modification ===
*Remove 3rd burst for Pistol
Detailed discussion moved to [[Talk:Pistol#XComUtil_Burst_Mode_Pistol]] to de-clutter this page. Summarised recommendations will be posted back here based on whatever consensus emerges.

Current recommendation: Reduce auto accuracy from 60% to 20%, with the same TUs (54%).When prompting, point out that no improvements are required to the Pistol to make it useful. [[User:Spike|Spike]] 08:12, 14 March 2010 (EDT)

* Dart Gun

On the other hand, the Dart Gun really is useless, even as a last ditch personal defence weapon. Auto mode, with very low accuracy (10%?), would at least give it some value as a defensive sidearm for medics, heavy weapons troops, etc. Scouts and others carrying a scanner or grenade in the other hand would still be better off using a Jet Harpoon, or even an AP HydroJet Cannon, one-handed. [[User:Spike|Spike]] 03:47, 16 March 2010 (EDT)

=== Fusion weapons inconsistently exempted from Alternate Laser Tech ===
* Fusion weapons inconsistently exempted from the "more difficult" energy weapons manufacturing option ("alternate laser Tech"). Blaster Bombs and Blaster Launchers, Fusion hovertanks and ammo, and Fusion Balls and Fusion Ball Launchers - none of these are harder to build or use with the "alternate Tech" option. Why make laser weapons/tanks and plasma weapons/tanks harder but not Fusion weapons? It's not consistent. I wonder if Scott didn't look at these because he never used Blaster Launchers or Fusion Hovertanks, as he considered them to unbalancing already? And ignored FBLs because, well, most people ignore them? But this should be consistent. Or, the "harder weapons" option could be broken down into sub options, e.g. for each weapon technology:
** Much more expensive (typically: add some exotic materials, 10x workshop space and 10x Engineer hours)
** Can/can't manufacture the battlescape weapons/tanks (pure alien weapons only)
** Can/can't manufacture the ammo (pure alien weapons only)
:Personally I would prefer it to be all-or-nothing but include the Fusion weapons as being more difficult to make and use. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
* In the meantime (ahead of introducing any changes), maybe change the prompt to "Alternate Laser and Plasma Tech"/"Alternate Gauss and Sonic Tech", and/or point out explicitly that the changes don't affect any Fusion/Blaster/Pulse Wave weapons. [[User:Spike|Spike]] 08:15, 14 March 2010 (EDT)

=== AutoCombat issues ===
* All Civilians are dead if AutoCombat is used to end a Terror mission. It's too not much of a problem, since score is likely to be positive anyway. It would possibly be an improvement to assume all civs from first stage are dead (if ran at second stage) and get a random number (using mission seed) for dead civs at current stage? [[User:Cesium|Cesium]] 07:00, 22 February 2010 (EST)
:* This is odd. Autocombat is supposed to skip over civilians when using the kill function. --[[User:BladeFireLight|BladeFireLight]] 00:18, 24 February 2010 (EST)
::*Maybe kill civilians (or not) according to the force ratios. If XCom has only enough force to win the mission, all Civilians are dead. If XCom bring a certain amount of "excessive force", all or nearly all Civilians are saved. By the way I love AutoCombat, it is great for avoiding repetitive combat and only playing the new, interesting bits. [[User:Spike|Spike]] 15:53, 22 February 2010 (EST)
:::* Thinking about this, I recalled the scenario where someone fights the mission and uses AutoCombat to hunt the last aliens (another reason AutoCombat is great). Spike's suggestion is better from pure RNG, since in this case probably all civs that were at risk already died. So lets see what we suggest XcomUtil do:
:::# Count civs from first stage if there was one as dead (since IIRC XcomUtil has no memory of first stage when exiting second stage, so we can't take them into account?).
:::# Deduct dead civs from current stage.
:::# Calculate extra dead civs using force ratio to bias the RNG (I prefer merely biasing the RNG rather than precluding results, since Xcom in general has a large variance in almost every gameplay mechanic). [[User:Cesium|Cesium]] 18:27, 22 February 2010 (EST)
* Day vs Night
** The Day/night algorithm breaks. For example, at any point when XCom has more than twice as many flare-carrying soldiers than there are remaining aliens, XCom is actually ''stronger'' in darkness than it would be in full daylight. Toward the end of a battle this is a very common situation. But fixing the algorithm is tricky. What might work is to give -10 for each Soldier in darkness, reduce from -20 to -10 for each Alien in darkness, then add back +10 for every soldier with a light source. Thus there is no way XCom can go 'net positive' from light sources.
:: If you have more units then they do you can see more of the battle field. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:::It never makes sense for XCom to be stronger at night, than during the day, for the same force ratio. But that is what happens. An example. 10 XCom soldiers with flares and 3 aliens. At night there is an extra -30 modifier for the aliens, but a +100 modifier for XCom, net +70. The same 10 soldiers against the same 3 aliens are +70 ''more'' effective in darkness than they would be in daylight. It does not make any sense. [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
** The definition of a light source should be expanded to include a Flare ''or'' an Incendiary weapon. In fact, one Incendiary-capable weapon of any type (AC/HC/HjC/GC), with appropriate Incendiary rounds carried, should be enough for the entire squad to be considered as having a light source. But this may be hard to implement without a special flag and a special pre-search for a valid Incendiary weapon, since AutoCombat normally scores by individual soldiers, not by whole squads.
:: This would take a rewrite. currently the ammo is not used by W: --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
** To be honest I would prefer that each soldier without a light source in darkness is 50% effective, each soldier with a light source (personal or squad), is 75% effective. Meanwhile how about this:

//Darkness - Tested OK (except IN Rkt)
-10 L:-9 u:-2 // Human in Darkness

+10 L:-9 u:-2 W:-27 U:- // Human in Darkness w/Flare -OR-
+10 L:-9 u:-2 W:-4 W:-7 U:- // Human in Darkness w/In ammo and launcher HC/GC-IN -OR-
+10 L:-9 u:-2 W:-8 W:-11 U:- // Human in Darkness w/In ammo and launcher AC/HjC-IN -OR-
+10 L:-9 u:-2 W:-12 W:-15 U:- // Human in Darkness w/In ammo and launcher IN Rkt/Torp

-10 L:-9 u:4-14 // Alien in Darkness

:: Only thing I see is that this ''must'' come at the end. The U:- removes the unit from further consideration. --[[User:BladeFireLight|BladeFireLight]] 19:58, 9 March 2010 (EST)
::: Yes, to use the U: flag for this "OR" function, it must come at the end of the section for humans. That's how I have it my updated AutCombt.txt, these fragments are a bit out of context. It's not critical to have the "OR", it's just nice-to-have as it stops someone cheating by having a flare and one of each loaded incendiary launcher weapon in each hand and in their backpack, to get quadruple score. But hopefully people are unlikely to cheat at AutoCombat, there are easier ways such as the WIN flag. [[User:Spike|Spike]] 20:39, 9 March 2010 (EST)
* The Zombie is rated the same as a tank, a Chrysallid/Tentaculat or an effective Psi alien (-50). I think this is too high, as Zombies are much weaker than those units. A Zombie should be maybe -25.
: Disagree. the zombie should be slightly higher then a Chrysallid/Tentaculat as it will become one and you have to kill it twice. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:: OK good point! [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
* Area effect weapons (HE, IN, Small Launcher) should have at least the same bonus as effective-on-Auto weapons (+5). This is because they can damage/kill multiple targets. (The AC/HjC should not get both bonuses however.)

//Area Weapons. To be Tested. These values are probably too high.
//NB we are not indicating damage here, that is already calculated by the "effective" function. we are just
//factoring in the possibility of hitting multiple targets because of the area effect
//ToDo: needs compensating bonus for aliens (grenades?). should not be cumulative on the same unit.
//Also: add check if weapon is "effective" (at GZ) ?
+25 u:-2 W:-40 W:-41 //U: // Human w/ Blaster/DP Launcher and ammo
+10 u:-2 W:-12 W:-13 //U: // Human w/HE ammo and launcher Sm HE Rkt/Torp
+10 u:-2 W:-12 W:-13 //U: // Human w/HE ammo and launcher Lg HE Rkt/Torp
+10 u:-2 W:-42 W:-43 //U: // Human w/ Stun/Shok Launcher and ammo
+5 u:-2 W:-4 W:-6 //U: // Human w/HE ammo and launcher HC/GC-HE
+5 u:-2 W:-8 W:-10 //U: // Human w/HE ammo and launcher AC/HjC-HE

-25 u:4-14 W:-40 W:-41 //U: // Alien w/ Blaster/DP Launcher and ammo
-10 u:4-14 W:-42 W:-43 //U: // Alien w/ Stun/Shok Launcher and ammo

::Having tested the HC and AC rules, the first rule (HC-HE) does not work unless you remove the ammo specifier W:-6, making it just a test for an HC. But weirdly the second rule (AC-HE) works fine with its ammo specifier in place. Odd. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
::: The problem was due to [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Ammo loaded into a weapon by the game automatically prior to the equip phase is not caught by the W: function. When the ammo is loaded manually, both rules works fine. [[User:Spike|Spike]] 18:16, 13 March 2010 (EST)

* Pistols with the burst mode option should not count as Auto weapons (maybe they don't).
: Burst and snap are based on default stats --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
* Blaster Launchers / DPLs (with ammo) should be worth as much as a tank, e.g. +/- 50 (including the single shot effective bonus it should already get - see suggested rule above under area weapons)
* Should distinguish between tanks. Even with improved armour, a Tank/Cannon is not the same as a Fusion Hovertank. I would suggest a range of 25 for a Tank/Cannon to 75 for a Hovertank/Fusion. Maybe 40 for a Tank/Rocket, 50 for Tank/Laser, 60 for a Hovertank/Plasma?
:This does not seem to be possible with the existing ruleset as all Tanks are unit type 3
::Hmm, byte 42 of [[UNITREF.DAT]] is Rank but also Tank chassis. So this ''might'' allow distinguishing tracked tanks from hover tanks, at least. An alternative approach would be to pick some stat (that has a StatStrings statid) and set it to a different unique value for each tank type. [[User:Spike|Spike]] 18:32, 9 March 2010 (EST)
::This rule set might work:

// Tanks - distinguish chassis types. To be tested
+40 u:3-3 R:0-0 // Tank, Tracked (Cannon, Rocket, Laser)//To Test
+60 u:3-3 R:1-1 // Tank, Hover (Plasma, Fusion) //To Test

* Flying units (either side) should be worth say +/- 5
:Not possible for XCom as no statid makes a distinction between Power Suit and Flying Suit. Would be possible for aliens eg:

-1 T:0- u:6-6 // Flying Alien - Ethereal
-1 T:0- u:8-8 // Flying Alien - Floater
-1 T:1- u:13-13 // "Flying" Alien - Hallucinoid
-1 T:1- u:11-11 // "Flying" Alien - Tentaculat

::On reflection flying is hardly any advantage for aliens, it usually just makes them easier targets with no cover. I guess it helps with avoiding HE splash. [[User:Spike|Spike]] 20:57, 16 March 2010 (EDT)

* If the squad is carrying some Smoke or Dye that should be worth maybe +5 - +10. But since the aliens don't ever carry that, you need some balancing factor for them.

+1 u:-2 W:-20 // +1 per human with smoke grenade(s) (not +1 per grenade!) //Tested OK

* Effective melee weapons should be counted. This is particularly important in TFTD when ranged weapons may be ineffective, e.g. vs Lobstermen.
* Similarly if the enemy are in heavy armour and therefore a soldier/alien does not have an effective weapon, any HE Pack / Alien Grenade / Sonic Pulser should be counted for something (if it is "effective").

//Melee weapons
+5 u:-2 W:1- W:-26 // Human w/o effective ranged weapon but w/ Stun Rod
<s>+5 u:-2 W:3-26 // Human w/ effective Stun Rod (cumulative to above)</s>

::The second rule doesn't work at all, it looks like it counts all items of types 3-6. The "superiority" function (first value before the hyphen) does not seem to operate, probably because it is a melee weapon. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
::: did you try W:255-26 ? not that I know if it would work. AutoCombat doesn't recognize stun rods as weapons when applying damage.--[[User:BladeFireLight|BladeFireLight]] 21:01, 9 March 2010 (EST)
:::: OK, if AutoCombat rates stun rods as doing no damage, the lower range of the W: function ("superiority") will likely never work. So we can't tell whether or not a Stun Rod is "effective" vs the current enemy. In general, the Stun Rod is a pretty effective weapon. So instead we generalise and just use something like this rule set:

//Melee weapons
+3 u:-2 W:1- W:-26 // Human w/o effective ranged weapon but w/ Stun Rod //Tested OK
+3 u:-2 W:-26 // Human w/ effective Stun Rod (cumulative to above) //Tested OK

//It would be nice if AutoCombat checked for the presence of Stun Rods and used them to increase the chance of an alien casualty being stunned rather than killed.

//To Do: check if TFTD melee weapons are included in "effective" weapons by the W: statid.

//Grenades (this needs to be an OR block, so it's not cumulative for each grenade type)
+2 u:-2 W:1- W:-44 // Human w/o effective ranged weapon but w/ effective Alien grenade(s)
+2 u:-2 W:1- W:-22 // Human w/o effective ranged weapon but w/ effective HE pack(s)
+2 u:-2 W:1- W:-21 // Human w/o effective ranged weapon but w/ effective prox grenade(s)
+2 u:-2 W:1- W:-19 // Human w/o effective ranged weapon but w/ effective grenade(s)

-5 u:4-14 W:3-44 // -5 per Alien with effective Alien Grenade(s) (not -5 per grenade!)
:: Only one per unit. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)
::: One per unit tested ok too! [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
* AutoCombat victories should award all UFO Components, not just some Navigation, Elerium and Alloys.
* Every Civilian on the map should be a penalty to XCom of maybe -5, due to the distraction effects of trying to save them / avoid killing them.

-5 u:15-16 U:- // Civilian distraction effect, no further effect //Tested OK

Let me know if I should try to work some of this up as AutoCombat rules. Some of it requires new coding of course, but a lot of it could probably be done with existing rules. [[User:Spike|Spike]] 13:15, 7 March 2010 (EST)
: I dont plan on any changing to the underlying code yet. Your welcome to make up a new set of rules and testing them out. --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
:: OK added some rules above. I have not tested them yet, some of the syntax might not work. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)
::: Syntax looks good to me. Give them a test and let me know how they go.
::: Just a quick note on how AutoCombat works. First the success percent chance is calculated using the AutoCombat StatStrings, dead and unconscious units dont count. (those that bleed to death are considers alive, need to fix this). If it's below AbortThreshold it aborts. If it's 100-199 then change to 90. 200+ change to 95 (success is never a guarantee.) Aliens roll d100, if over your success chance you lose. If You win. Then average damage by each side is calculated based on Loaded weapon being carried and time units. All aliens are killed or stunned by X-Com unit chosen at random. Each Alien gets a chance to wound an X-Com unit based on Success Percentage. Randomly choose unit using random damage (max is average alien damage) Leave at least one X-Com Unit alive. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)

* It would be nice, in a future version of AutoCombat, to have some way of ORing rules together. Using the U: construct as a 'break' only allows you to have one single OR block per unit type (I think). [[User:Spike|Spike]] 20:57, 16 March 2010 (EDT)

* The battle report screen after AutoCombat does not report the number of Alien Artefacts recovered. This gives score I believe. Is it because it's hard to populate whatever data structure the game reads in order to generate the Artefact count? As I understand it, anything you haven't yet researched is an Artefact, and awards some score for recovering it. Anyway, fixing this would be nice-to-have. [[User:Spike|Spike]] 20:57, 16 March 2010 (EDT)

* It would be nice to compensate for the [[Known_Bugs#Equip_Phase_Ammo_Load_Error|Equip Phase Ammo Load Bug]] [[User:Spike|Spike]] 20:57, 16 March 2010 (EDT)

=== Focused Research Help ===

There is a minor and probably unintended consequence of Research Help from Captured Aliens. Normally when you capture a new alien artefact that opens up a new research project, you start the research project - typically with 0 Scientists - and then immediately sell the artefact. The problem with this for Research Help is that you soon have a huge number of projects underway. Then any Research Help tends to get very widely dispersed across all active projects (since it always goes to the project where the biggest reduction can be made, i.e. the projects furthest from completion). The result is that projects are completed only rarely, and progress is made on a broad front but without delivering much. Currently, to avoid this, it is necessary to keep single alien artefacts around in Stores, waiting for the time when the project they open up becomes a priority. In a way, this is interesting and challenging. In another way, it is a headache and take away vital cash.

You might argue that the trick above is a kind of exploit and should not be done. I don't know, maybe. But it is a common practice.

A solution, hopefully fairly easy to implement, is to only consider Research Help for projects which have actually made some progress, e.g. more than 1 scientist day has been applied to them.

In the meantime, maybe put a warning to players in the XCUSETUP script, to keep their research projects to a smaller number when using Research Help from Aliens. [[User:Spike|Spike]] 21:10, 16 March 2010 (EDT)

== Features for 9.8+ - New features ==

=== TFTD Gauss Tank Research Fix ===
*Have the option to make the Gauss Tank require only Gauss Cannon research - this can make it more distinct than the Sonic Displacer and maybe slightly useful for a while
:*I plan on it. just not this version. --[[User:BladeFireLight|BladeFireLight]] 20:53, 18 January 2010 (EST)

=== Improved Base Comes At Cost ===

The Improved Base is supposed to be a "faster start" option rather than a "make the game easier" option. But it does make the game easier, not least because it gives you a load of free base facility improvements. (Not to mention not having to struggle along the first month with only Small Radar and no Alien Containment) To partly avoid making the game easier, please add a sub-option that subtracts the cost of the extra facilities from your starting cash. This should be the ''full'' cost of the extra facilities, not just the difference between e.g. a Small Radar and a Large Radar.
[[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
: I dont have the offsets to the starting money ranges. so I cant do this. --[[User:BladeFireLight|BladeFireLight]] 19:13, 10 March 2010 (EST)
:: I never realised that the starting money is slightly random, I see ranges from $4,125,000 to $4,153,000, in ten samples. Does not seem to depend on Difficulty or starting base location. That is going to be a hard offset to find. [[User:Spike|Spike]] 20:36, 11 March 2010 (EST)
::: I believe there is no "starting money" anywhere to be found, or rather the starting money is effectively zero but it soon changes: the first thing the game does when you begin a new game is perform a hidden monthly report which grants you money from the funding nations. Only way to decrease it is to lower your rating toward countries (you should be able to hack the starting diplomacy data located at 0x4728F8). Or I could just patch the initial money to be negative instead of zero thus providing lower overall starting money. [[User:Seb76|Seb76]] 15:52, 12 March 2010 (EST)
:::: That makes a lot of sense. The initial money is the same as the initial funding. Doh! I should've realised that. The solution to poke a negative number into the money field, prior to the "hidden funding round", sounds a great idea.
:::: Looking at initial money vs funding, your initial cash is always $1,860,000 less than your initial funding. This $1.86M is probably made up of the first 3 rows (only) of your initial Monthly Costs: $500K transport rental, $1200K Interceptor rental, and $160K salary (not hiring fees) for 8 Soldiers. The salary (and hiring fees) for 10 Scientists and 10 Engineers are ignored. The Base Maintenance costs, $224K for a standard starting base, are also ignored. This generosity saves you at least $774K. Could this be considered a bug? Possibly.
:::: The cash value of the XComUtil Improved Base is a whopping $4.5M. This is $1.6M of facilities (Alien Containment, Large Radar, 2nd Living Quarters) and $2.9M of personnel (+10 Engineers, +40 Scientists). $4.5M would wipe out all starting cash and players would begin the game with a negative balance - quite challenging! For XComUtil, it might be best to break improved Facilities and Extra Starting Personnel into 2 options, with each having a sub-option to pay for the improvements. ''"These extra facilities/staff would cost $1.6M/$2.9M, do you want to deduct that amount from your starting cash?"'' [[User:Spike|Spike]] 20:48, 12 March 2010 (EST)

=== Easier Inventory Management ===
Inventory management is one of the things I hate about the first two X-Coms. I was hired to be a commander, not a supply clerk! A mod which made general stores have 10000 space (like Apoc) would be nice.. [[User:Cesium|Cesium]] 21:39, 9 February 2010 (EST)
: The manager of any facility has to deal with generalities of space issues. The clerk tells you if that fancy new tank you just bought will fit. He has to put it in storage and keep track of what shelf the ammo is on. --[[User:BladeFireLight|BladeFireLight]] 22:27, 9 February 2010 (EST)
:: That's the clerk's problem and if he complains too much I'll have him peel potatoes until his hands drop. In any event, the limit doesn't make any sense:
::* General stores size is 8x8x2 (8x8x3 in TFTD) per base defence map, and should have no problem storing more than 50 items.
::: The items taking up 1 item unit are typically about the size of humanoid body. I think it's not unreasonable to have no more than 50 of those in the area that the General Stores takes up.
:::: I can't find a list on the wiki of storage space requirements for items, so I'm not sure which items take up 1 item unit. Typically the main space wasters are Heavy Plasma ammo/Blaster Bombs/Stun Bombs (late game) and/or HWPs and avalanches (early game). These either are definitely not the size of a human body (ammo/Bombs), or shouldn't be stored in stores at all (HWPs gain nothing, and might as well lay around somewhere else in base).
::* The size of a fully built X-Com base is about the size of a city block (judging by comparison of base defence to terror missions), and should easily be able to hold hundreds of items even in the starting base if it's willing to put some stuff not in the general stores.
::* The space limit makes no sense. Why do Blaster Bombs and Heavy Plasma ammo take so much space whereas in the inventory view it doesn't take any more than normal ammo? Who stores <s>mini tanks</s> HWPs in the same compartment as light weapons? And the way X-Com (probably) stores ammo and explosives is scary...
::: As you suggest, extremely powerful ammunition probably requires a lot more space for safe and secure storage in-base, versus on a tactical mission. Imagine what would happen if a Blaster Bomb exploded in a base? Or was stolen? They probably use nuclear warhead style storage facilities for those. And similarly for Avalanche warheads, alien artifacts, Elerium, etc. Segregating dangerous/explosive items from other items probably uses up a lot of overhead in the construction of the storage space - think armoured, bomb-proof lockers and bulkheads, advanced security systems, airlocks, scanners, etc. This is not just like piling stuff up in your shed! And the Commander who left Elerium or Avalanche warheads lying around in his hanger or corridors would justifiably be sacked on the spot by XCom High Command. [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Well, judging by all the explosives in the hangar during base defence and the X-COM 1.0 Elerium bug, Elerium and explosive warheads ''are'' lying around in the base... And all the equipment in the General Stores is stored in ordinary lockers according to the General Stores map ;-) More to the point, if X-COM wants to store explosives safely (judging by said warheads X-COM doesn't care too much) they need a special facility for this, not to store them in the room which also contains all the base's weapons and priceless alien artifacts.

:::: Furthermore, I expect X-COM to improvise on storage in the interest of actually winning the war. X-COM does do this and ignore the limit when manufacturing stuff in-base or getting loot from missions. All that's needed is that X-COM will improvise for transfers too. I can't imagine a quartermaster informing the commander there isn't any room for the new armour and that the troops should go without. Maybe the reason X-COM doesn't pay quartermasters each month is that they keep getting themselves lynched by enraged X-COM troops...
::* Gameplay wise, inventory micromanagement is just no fun, especially in the late game when you have all the cash you need but still has to sell stuff after each combat (which can be prolonged if you haven't sold for awhile), otherwise you can't transfer items to the base where your main team is at.
::* Maybe this entire "stores" thing is a plot by the CFN to force X-Com to share its technology with them by forcing X-Com to sell sell sell. It's not like they pay X-Com the real worth of the technology anyway. [[User:Cesium|Cesium]] 23:47, 9 February 2010 (EST)
::: I think a lot of people do find the inventory management tedious, or unrealistically low. Personally I think it's about right for large equipment (missiles, tanks, bodies), but too low for small arms and personal equipment. And yes, it only reflects using the General Stores modules, not storing stuff at random points in the base - maybe fair enough. If the right offset to patch can be found, the storage limits could easily be raised. The last few bytes of [[BASE.DAT]] could be a good place to look for this offset. BASE.DAT can store up to 9,999 units of each item per base. The total limit for items per base would need to be found by experiment, but 9,999 might work for those who want to ignore inventory. For those who feel inventory management is OK but the limits set too tight, the capacity of each General Stores could be increased from 50 to 100 - assuming we can find the offset for this to patch it. [[User:Spike|Spike]] 19:50, 10 February 2010 (EST)
::::Maybe you can try there:
.text:00439C85 66 81 C5 F4 01 add bp, 500
::::[[User:Seb76|Seb76]] 13:03, 11 February 2010 (EST)
::::: Yes that works nicely. E.g. patch '''66 81 C5 E8 03''' at that location and you get 100 space per General Stores. Thanks Seb! [[User:Spike|Spike]] 18:21, 13 February 2010 (EST)
:::::: Now if only I had the offsets or search signature so we can add that as an options --[[User:BladeFireLight|BladeFireLight]] 18:24, 13 February 2010 (EST)
::::::: UFO 1.4 dos: offset 143748. TFTD 2.1 dos: offset 178462. TFTD v1 dos: offset 176861. TFTD CE: offset 252795. UFO CE: offset 236680. (all offsets are in decimal and point to the "F4 01" value to be patched).
::::::: Patching to "E8 03" has been tested on dos versions (not on CE) and it works. The "base information" screen will display the correct value, though the values to line length scale is such that the line will max at 250. [[User:Cesium|Cesium]] 05:57, 14 February 2010 (EST)
::::::::Are the preceding bytes the same from TFTD 1 and 2x? --[[User:BladeFireLight|BladeFireLight]] 17:26, 15 February 2010 (EST)
::::::::: Yes they are. '''81 C3 F4 01''' is the add instruction. [[User:Cesium|Cesium]] 17:48, 15 February 2010 (EST)
::::::::: Sig for UFO Dos is '''81 C6 F4 01''' --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
:::::::::: Do you also have the preceding bytes for UFO? with the signatures I can create a patch file for all versions --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
::::::::::: I am not sure I understand your question.. Judging the the two UFO versions I have available (1.3 per xcusetup and 1.4) the common preceding bytes are ''80 78 16 07 75 0C 80 78 3A 00 75 06'' (followed by the sig). You could try to use the sig alone - it exists only once in the file. [[User:Cesium|Cesium]] 19:35, 15 February 2010 (EST)
:::::::::::: Offset Locations are something I'm collecting but also the unique series of bytes to find them for the two geoscape/tactical that I dont have. (UFO Spanish, TFTD Italian) I hope to add a lot more options in the in the future. I do feel this one nerfs the storage system anything to get the game up and going faster is always a plus. --[[User:BladeFireLight|BladeFireLight]] 22:01, 15 February 2010 (EST)
::::::::::::: Well, you may want to add another General Stores to the improved starting base if you want to achieve the faster startup effect without "nerfing" storage system for rest of game (I prefer a "nerf" due to late-game reasons). Also, I suggest you add an message in Xcusetup to ask people to get in contact with you if they use an unknown/unrecognized version. [[User:Cesium|Cesium]] 14:27, 16 February 2010 (EST)
::: Inventory management is just as much a pain in the early game, where you almost always are out of space until your 2nd general stores is built. I like realistic constraints, but not tedium. Maybe upping the space per Stores from 50 units to 100 units would be a generally acceptable approach (now that Seb76 has kindly found the offset)? [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Yeah, that would be a great improvement. [[User:Cesium|Cesium]] 15:45, 13 February 2010 (EST)

:I can confirm Seb76 is correct, as ever. The 2 bytes at offsets '''0x39c88''' and '''0x39c89''' in geoscape.exe code for the capacity of each General Stores. Default value is 500 ('''F4 01''') which equates to 50 in-game internal capacity units. (Smallest item uses 0.1 in game capacity so I guess that is 1 unit in internal units). I am not sure about a signature. From what I can tell, the preceding bytes '''66 81 C5''' are unique in geoscape.exe, which seems pretty odd, so someone else should verify that. [[User:Spike|Spike]] 19:48, 13 February 2010 (EST)
:: Yes it is unique to CE. it does not exist in any DOS EXE, but "F4 01" can be found in 79 places. Trial and error could locate it. --[[User:BladeFireLight|BladeFireLight]] 20:50, 13 February 2010 (EST)

=== AutoCombat ===

==== Firepower Factors ====
You might want to consider replacing the weapon offensive weighting factors for Autocombat with some factors that are (inversely) related to the [[Weapon_Analysis#Quantitative_Analysis|% TUs Per Kill]]. I've tabulated these for each weapon (including tanks) vs each alien race. You would still need to account for Psi, light/darkness, and XCom armour. Plus you would need a similar offensive factor for the aliens' attacks. But I could probably help with that, I have the data that's directly comparable to the % TUs per Kill for XCom weapons. [[User:Spike|Spike]] 22:06, 12 February 2010 (EST)

==== AutoWithdrawal ====

One of the most tedious things you can try to do in XCom is to scavenge the battlefield and retreat to landing craft for an Abort. A great option would be an AutoWithdrawal, similar to an AutoCombat, but with an easier threshold of XCom vs Alien combat power.

Basically it would scavenge all loose equipment off the Battlescape - dropped friendly and alien items, friendly and alien corpses and wounded, all go back into the landing craft. Elerium, Alloys, and UFO Components would not be recovered, as this is (normally) impossible apart from full tactical victory. All friendly troops return to the landing craft. Friendly losses, and equipment recovered, would be proportional to the offensive factor ratios but much more favourable than for AutoCombat. E.g. as long as XCom factors were at least equal to Alien factors, they would be able to scavenge everything and recover without casualties. If the aliens were stronger than XCom, they would only recover part of the scavenged equipment, and risk partial casualties, at say one third the rate of AutoCombat. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

: It's too easy compared to actual game IMHO. Every time a battle went FUBAR for me, it got FUBAR all the way and I was lucky if I could salvage my own team/equipment and maybe a single alien weapon/body. An AutoWithdrawal without salvage might be useful, but perhaps instead we should change AutoCombat failure mode to work better (e.g. Make some X-COM people survive a failed AutoCombat, depending on strength vs aliens). [[User:Cesium|Cesium]] 15:00, 7 March 2010 (EST)

:: Yes fair point. I was not thinking of the FUBAR situations, and you are right about how hairy those are. I was thinking of the situation where you control a certain part of the battlefield, but you either don't want to go on an endless hunt for the last few aliens, or you pretty much know you can't take on the aliens that are left (e.g. in the UFO or some other stronghold) without getting creamed. You can exercise a safe withdrawal, it's just tedious to carry out all the bodies and equipment. But it's pretty hard for an AutoCombat algorithm to detect which of those situations it is - FUBAR, boredom, or tactical withdrawal. I'll have to think about that, there may be no realistic solution at all. And there is the existing "teleport loose items back to base" command line option to XComUtil, maybe that's enough. [[User:Spike|Spike]] 16:08, 7 March 2010 (EST)

=== Tougher UFOs ===

[[Wish_List_(EU)#Tougher_UFOs|Tougher UFOs]]
As this is entirely implemented by patching data and data files it is a good candidate for XComUtil rather than [[UFO Extender]].
: That would definitely make the game harder. 9.7 is about the installer and the bug fixes. This would be a good candidate for 9.8. --[[User:BladeFireLight|BladeFireLight]] 01:38, 19 February 2010 (EST)
:: Cool! [[User:Spike|Spike]] 02:25, 19 February 2010 (EST)

=== Rebalanced Craft Weapons ===

This fits under the "making useless things usefull" category. It would be a 9.8 or later option. The idea is to make the Cannon, Stingray, Laser Cannon and Fusion Ball Launcher useful. Hopefully it breaks up the monotony of Dual Avalanches followed by Dual Plasma Beams, every game.

There is one common element in the approach, and two options. The common element is to fix the stats on the Fusion Ball Launcher. The two options are to use a stat-based approach, or a cost-based approach, to fix the other weapons.

NB This proposal is still a draft and will need tweaking, but I've got it to the point where it is worth discussing. Feedback is welcome!

''(Ultimately, the Plasma Beam still ends up being pretty much the optimum weapon in the end game. To mitigate this, it is a good idea to select the existing Alternate Energy Weapons Manufacturing option in XComUtil.)''

==== Fusion Ball Launcher ====

Increase the ammo capacity from 2 to 3. Don't mess with the damage. Job done.

See [[User:Spike#Fusion_Ball_Launcher]] and discussions linked from there.

==== Cost Based Approach ====

This uses historically realistic costs to restore game balance between different craft weapons. The stand off advantage of Avalanche missiles is now purchased at a price which is significant in terms of XCom budgets and mission yields. Stingrays and Cannons become significantly cheaper alternatives. The Laser Cannon, with similar capabilities to Stingrays but free to operate, also becomes very attractive. Mounting dual launched weapons becomes a very expensive luxury.

*Increase Avalanche missile Purchase cost to $386,000
*Increase Stingray missile Purchase cost to $125,000
*Leave Sell prices unmodified (to avoid creating a cash reservoir at the start of the game)
*Leave Launcher buy/sell prices unmodified

See [[User:Spike#Cost_Based_Rebalancing]]

==== Stat Based Approach ====

This provides a benefit trade-off to shorter range weapons, by increasing their firepower or effectiveness relative to longer range weapons.

*Increase Cannon stats to 15 Damage, 50% hit. Firepower is tripled, slightly ahead of (unmodified) Avalanches launching in Aggressive mode. Increase rearming rate to 200.
*Increase Stingray accuracy to 80%. Decrease Avalanche accuracy to 60%. Stingray now has 50% more firepower relative to Avalanche. Increase Stingray rearming rate to 2, so a full craft can be re-armed in the same time period with either weapon (instead of twice as long for Stingray).
*Increase Laser Cannon stats to 100 Damage, 50% hit. Firepower is doubled, 20% more than (unmodified) Avalanches launching in Aggressive mode, 2/3rds of Plasma Beam firepower.

To avoid advanced XCom aircraft exploiting the extra firepower of the Cannon weapons and disregarding the return fire from UFOs, this is best used alongside the Tougher UFOs option.

See [[User:Spike#Stat_Based_Rebalancing]]

=== Rebalanced Infantry Weapons ===

See [[User:Spike#Balancing_Infantry_Weapons]]

Primarily this means making the Rifle a bit stronger, and probably making the Pistol a bit weaker.

=== Advanced Laser Cannon ===
The "Advance Laser Weapons" option only nerfs the Laser Cannon (raising cost and reducing profitability but not changing any damage/range values. Previously xcomutil modified them unconditionally). I wonder if that's the best result - should damage and/or range be raised to make the cannon useful or to compensate? Most commanders don't use the cannon as is, but maybe it's prejudice... [[User:Cesium|Cesium]] 21:36, 16 March 2010 (EDT)

==See Also==

[[Wish List]]

= Completed Wish List Items =

=== BFG Default To Unchanged ===

Is it possible when using the BattleFieldGenerator, for it to detect the actual conditions for the mission (terrain, enemy craft, and light level) and offer these as defaults? [[User:Spike|Spike]] 08:22, 13 February 2010 (EST)
:Press The esc key at the prompt. (Line 719 in Xcomutil.txt, not that I expect anyone to read the manual :) ) Enter should also work. --[[User:BladeFireLight|BladeFireLight]] 12:34, 13 February 2010 (EST)
:: RTFM eh? My biggest failing. Maybe you could add an explicit prompt "Esc or Enter = [whatever the unmodified value would be]". [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)
::: From what I can see, hitting Escape during BFG makes it continue with ''all'' values reverting to the original conditions. It would be nice to be able to select some but not all original conditions. My main use of this is to turn a night mission into a day mission without the hassle of keeping the landing craft hovering around until the terminator crosses the landing site. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
:::: You could just use the force all daylight option.
:::: After reviewing Scott's code. Esc leaves all setting as-is. Pressing enter or any other key not listed will randomly choose for you. I will see if I can change enter to leave as is. --[[User:BladeFireLight|BladeFireLight]] 11:00, 7 March 2010 (EST)
::::: This has been added --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)

= MISC =

* It's actually quite hard to downgrade to DOSBox 0.72 in Ubuntu. Only 0.73 is offered, there is no ability to Force back to a lower package level with Synaptic Package Manager. Unix guru skilz are required to rollback to 0.72, and I guess 0.74 is not around yet, or not packaged for Ubunut APT? Is there any way to fudge around this, e.g. by providing the command line arguments in an optional text file for xcusetup.bat to parse? Having said that, even with no command line arguments, xcusetup hangs on my 0.73 DOSBox while executing SDUMP. I had to reboot in Windows to run xcusetup.bat - something that is only possible on a dual boot machine / Wubi machine. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
** Try using a different batch interpreter like 4DOS [http://www.4dos.info] to execute xcusetup inside DosBox. I tested this throughly before under DosBox/Linux and it works well with recent 9.7 builds. I suggest running "config -set cpu core=dynamic" and "config -set cpu cycles=max" before xcusetup to speed it up (xcusetup doesn't detect DosBox when 4Dos is run, so it doesn't run these automatically unlike normal DosBox case). [[User:Cesium|Cesium]] 09:48, 7 March 2010 (EST)
** Oh, and downgrading isn't that difficult: Get a dosbox 0.72 deb, and run "dpkg -i" on it, and then do "echo dosbox hold | dpkg --set-selections" to prevent future upgrades. [[User:Cesium|Cesium]] 09:50, 7 March 2010 (EST)
** Another option is to install the dosemu package, and run xcusetup under that. EU/TFTD can be run under that, but it doesn't work as well there. (Oh, and there's no mount command there. UFO/TFTD needs to exist under ~/.dosemu/drive_c which is C:) [[User:Cesium|Cesium]] 11:42, 7 March 2010 (EST)

:Thanks Cesium I will check this out. I still think it would be good to have a solution that works for people who are not knowledgeable with the unix command line though. [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)

:: Why use Linux if you dont know how to use the console? It is a text mode OS with a separate GUI. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)

::: Well Ubuntu is a bit different, as it's supposed to be an OS for the general public, where you never need to touch text mode! Incidentally I can't find any DEB or other packages for 0.72, all that is available on the DOSBox website is the source code. They really don't seem to realise that 0.73 is buggy! So I guess I will need to '''make''' it. Or just wait for 0.74 as I think it's out soon. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)

:::: See [http://archive.ubuntu.com/ubuntu/pool/universe/d/dosbox/] for 0.72 debs. Unlike Windows, package systems in Unix land are centralized, so best location to search is typically a package server mirror or a distro mirror, not a vendor's website. [[User:Cesium|Cesium]] 17:36, 9 March 2010 (EST)

Talk:XcomUtil

2010-03-16T23:08:19Z

BladeFireLight: /* Build 435 */

=XcomUtil 9.7 Beta=

9.7 Beta is available on www.bladefirelight.com

==Release Notes==

This is a Beta, so backup your files before using. And check back often for newer builds.

New in this version.

*Major overhall of the installer (XcuSetup) and the inclusion of 16/32bit exe's to support both DOSBox and Windows Vista/7 x64.
*New subfolders added to hold supporting files making the install cleaner
*New XcuSetup command line arguments were added to XcuSetup allowing for silent install and uninstallation.
*New XcuSetup option for debugging the install (XcuSetup debug) creating XcomUtil\debug.txt.
*New command line argument "nobackup" skips backup only if it has been ran atleast once.
*XcuSetup can now have minimal impact on the game.
**Almost all options default to NO (Only Split Windows EXE set to Yes).
**Almost all changes are now prompted for (skyranger guns, interceptor as transport, Disjointed Base Bug, etc...).
***Items still done by default:
***Copy protection questions set to 0000000 for UFO 1.0-1.3 and X-Com 1.0
***Difficulty bug fixed in UFO 1.0-1.4 and X-Com 1.0-1.4
***Unique names for all maps in TFTD, Used for Hybrid Games
***Placement of X-Com Units on the Battlefield based on XcomUtil.cfg
***MIA Recovery on Won Combat (Units under mind\MC control when last controling alien killed are returned to X-Com control)
*XcomUtil.cfg is now pieced together and overwritten by XcuSetup (see XcomUtil\XcomUtil.txt for how to make permanent changes).
*All game files are restored to the pre-XcomUtil state each time XcuSetup is ran. Any modifications by other utilities will have to be re-applied.
*Vista/Win7 patch now an option for XcuSetup.
**This will fix the blank screen issue.
**Updated to support the split EXE.
**Will set X-Com to use CPU 0.
*XcuSetup attempts to fix UAC issues by resetting folder permissions.
*A number of community made fixes are included and selectable with XcuSetup.
*Support for the DOS/Window STEAM Install.
**Installer will detect STEAM and change steam launcher to start the XcomUtil Steam Menu (can be re-installed with XcomUtil\SteamSetup.bat
*Out of the box support for UFO Extender. XcuSetup will detect it and ask if you want RunXcom to use it.
*XcuSetup can be run from windows and RunXcom run from DosBox
*Hybrid Colors updated based on BombBloke's pallets.
*EQL flag allowed any turn.
*Add Xcom UFO Italian Support.
*Auto Combat will not run on second half of two part using first parts saved data.
*Auto Combat will no longer run if combat was won.
*MIA Recovery on won combat only.
*MIA Recovery no longer recovering units that bleed to death.
*Auto equip no longer triggers on second part of 2 stage missions.
*Combine clips skiped if between stages of 2-3 part missions.
*Updated f0dders ReadMe per his request. (XcomUtil\bugfix-readme.txt)
*Add-on support added. see XcomUtil\XcomUtil.txt and XcomUtil\Addon\Example.txt
*Prompted Terrain in BattleField Generator allows to abort or use of current setting.
*Beta versions include
**XcomUtil\XcomUtil.log includes lots of debug info
**XcomUtil\Debug.txt created by default (Release will need "debug" command argument)

Removed from this versions

*New Desert and Urban terrain. (Will be added once I have a C++ version of the Java Terrain Edit.)
*Expanded capacity Laviathan, Hammerhead and Avenger (maps avalible in XcomUtil\Patches)

NOTE: If you use DosBox, this requires DosBox 0.72 (Does not work on 0.73 due to buffer overflow setting ERRORLVEL)

===Build 435===

Original Sound Effects from UFO were re-sampled to work with 1.4 and CE.

*Add Category to option headers.
*Improve randomness by using current time instead of game date/time in srand()
*Added Option to keep Current terrain/UFO to BFG.
*Original UFO 1.2 Sounds for Geoscape and Tactical added as an option for UFO 1.4 and CE.
*Force Split EXE on STEAM. Fixes issues with setup failing.
*Reset Laser/Gauss craft weapons stats to be default.
*Example addon now uses different flag extension to avoid deletion by XcuSetup
*fix issue with Lab Screen on DosBox always screening

==Beta Disscusion==

===Build 435===
: I hope the improved randomness doesn't apply to the Aliens' d100 during AutoCombat. Otherwise, one could load-scum for success. [[User:Cesium|Cesium]] 06:33, 11 March 2010 (EST)
:: Actually it does. I can see what your getting at, but why do it that way. if you want to win the "WIN" command line option is faster and you get better loot from the UFO. also using the combat date would also swing the other way with an unwindable autocombat with an fully loaded avenger vs a survey ship. --[[User:BladeFireLight|BladeFireLight]] 17:41, 11 March 2010 (EST)
: In the setup question for sound files: "were replace" should be "were replaced". [[User:Cesium|Cesium]] 06:53, 11 March 2010 (EST)

Excellent! For the first time xcusetup.bat completed for me in Dosbox in Ubuntu. Previously the SDUMP commands were hanging it.

For the first time ever, I ran the sound setup utility. It did not response to any cursor keys, enter, tab, etc. The only key that worked was Escape, and I'm not sure what this did.

One point on the xcusetup.bat script - Ctrl C does not seem to work. On all those "press a key to continue" prompts could we also have "or 'q' to quit"?

[[User:Spike|Spike]] 18:41, 13 March 2010 (EST)

: "press a key to continue" is the Pause command. Ctrl + C works fine in Windows. DOSBox does not. The reason for the use of Pause is because an number of new players kept exiting setup early when I gave the option. Aborting early makes a mess and I dont want to have to troubleshoot it for Joe user. --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
:: OK I see, that makes a lot of sense. [[User:Spike|Spike]] 06:52, 14 March 2010 (EDT)

----

I have a strange issue. I succeed in an AutoCombat terror mission (117%) but the mission is resolved partially as if I had actually aborted the mission - all Civilians die, even though I could see 3-4 alive, my 13 soldiers outside the Skyranger go MIA, even the one who was killed by AutoCombat, and only my sergeant standing in the Skyranger makes it back. The problem is repeatable. On one occasion the sergeant was killed randomly by AutoCombat, meaning that the Skyranger flew back by itself, empty. Obviously this should never happen.

I've uploaded the [[Media:MIAoverload.zip|AutoCombat game save file]]. Incidentally this shows how to 'game' the current AutoCombat rules: Take maximum soldiers, no tanks. You give everyone a Rocket Launcher, they only need 1 Lg Rocket in it. Until you get Heavy Lasers, then replace the Rocket Launchers with them. Next replace with Heavy Plasmas. This approach always gives you maximum damage per soldier, and thus maximum chance of getting the +15 bonus for the W:3- rule. [[User:Spike|Spike]] 19:02, 15 March 2010 (EDT)

:: Hmmm. Scott's MIA recovery raised an army of undead from those that died of fatal wounds. Mine only effects mind controlled units. The issue is telling who is dead and who is left behind.

Units from your saved game looked like this(on by Autocombat).

Shuji Okabe: Left behind (Health > 0)
[[UNITPOS.DAT|UnitPos]][0x0A] 1.0.0.0.0.0.0.0
[[UNITREF.DAT|UnitRef]][0x78] 0.0.0.0.0.0.1.0
Yoko Fujimoto: On Craft (Health > 0)
UnitPos[0x0A] 1.1.0.0.0.0.0.0
UnitRef[0x78] 0.0.0.1.0.0.0.0

From Bomb Blokes undead army MIA Test save (won by killing aliens).

Spencer Bryant: Lived (Health > 0)
[[UNITPOS.DAT|UnitPos]][0x0A] 0.1.0.0.0.1.0.0
[[UNITREF.DAT|UnitRef]][0x78] 0.1.0.0.0.0.0.1
Oscar Thompson: Bleed to death (Health > 0)
UnitPos[0x0A] 0.0.0.0.0.1.0.0
UnitRef[0x78] 0.1.0.0.0.0.0.1
Virgil Hudson: Killed by Aliens (Health == 0)
UnitPos[0x0A] 0.0.0.0.0.1.0.0
UnitRef[0x78] 1.1.0.0.0.0.0.1

So right now I'm at a loss of how to detect tell the difference between thoes that are left behind and thoes that are dead.

----

Does the SHP flag still work, after the changes to how XCOMUTIL.CFG is assembled? I just tried it, after rerunning XCUSETUP.BAT (Dosbox 0.72 under Ubuntu). XCOMUTIL SHP produces no output. XCOMUTIL SHP:CFG WRT writes GEOSCAPE.EXE, but nothing seems to change. During XCUSETUP I see the expected "Patch applied, ship data updated from CFG" (or whatever). [[User:Spike|Spike]] 17:40, 16 March 2010 (EDT)
:: Yes it works fine. your mistyping the command. it's "xcomutil ufoexe shp:cfg wrt" Second argument must be the target folder. Line 42 and 1266 of XcommUtil.txt.

==Open Bugs==
*There's no Italian text for the Alternate Laser Weapons option. Applying the patch seems to work, but it displays the text for the default laser weapons.
:*Anyone want to translate the text into Italian? --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
*The number of aliens in the mission report is inconsistent with the number of live aliens captured per research help. See [[Image:Alien_numbers_mismatch.zip]] and [[Image:Dead_alien_count.zip]].
* Morale is random at start of second stage after autocombat of first stage?
:* Actually Morale is used as the clip size and time units as the weapon damage. Don't ask me why. It would take a major re-write of auto combat to fix this. --[[User:BladeFireLight|BladeFireLight]] 19:34, 23 February 2010 (EST)
*RPL bug, when you turn creatures into Gill Men, they are reported as Snakemen
:* Reported how? Is this consistent? The name's used are from xcomutil.cfg. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
::*Sorry. It's reported in morale failure pop up messages. Though maybe this is an original TFTD bug rather than an XComUtil bug. [[User:Spike|Spike]] 19:21, 21 February 2010 (EST)
:::* See this: [http://www.youtube.com/watch?v=uGlSghf7aTU]. In that case, all Gill man (were lobster man before RPL) were reported as snakemen.. [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST)
*RPL bug, when you turn Lobstermen into other creatures (e.g. Gill Men), they are very hard to kill despite having the stats of the creature they turned in to. Possibly they are keeping their damage resistance? Maybe the race is stored in more than one place, for different purposes, and XComUtil misses one of these places?
:: I will look into this --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: The RPL only changes the basics; The race, rank, name, TimeUnits, Health, Energy, Reactions, Armor(front,back,left,right), Strenght and PSI Strenght. All other stats are left as-is. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
:::: I'm not so sure about this. See 05:00 mark at [http://www.youtube.com/watch?v=y-_zLdjhUHI]. The armour doesn't match the one Gill man should have (per UFOpaedia, at least). [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST). See also 04:17 mark at [http://www.youtube.com/watch?v=z5LfzFSkRnI] for reason to suspect resistances aren't always changed. It's possible he just was unlucky though... [[User:Cesium|Cesium]] 19:53, 21 February 2010 (EST)
::::: Actually the function is something like this
<pre>#define UpdateStat(x,y) pur->x = (unsigned char) \
( ( (unsigned int)pur->x \
* (unsigned int)pasTo->y \
) / (unsigned int)pasFrom->y )
UpdateStat( TimeUnits0, TimeUnits );
UpdateStat( Health0, Health );
UpdateStat( Energy0, Energy );
UpdateStat( Reactions0, Reactions );
UpdateStat( AFront0, AFront2 );
UpdateStat( ALeft0, ALeft2 );
UpdateStat( ARight0, ARight2 );
UpdateStat( ARear0, ARear2 );
UpdateStat( AUnder0, AUnder2 );
UpdateStat( Strength, Strength );
UpdateStat( PsiStrength, PsiStrength );
</pre>
::::: the 0's are values at start of tactical.
::::: I read that as Current(from game_x) * Target default(from xcomutil.cfg) / source default (from Xcomutil.cfg) so the stats will be different. --[[User:BladeFireLight|BladeFireLight]] 21:33, 21 February 2010 (EST)
:::::: I'd have expected Current(game_x) == Source default if applied on first turn? This would end up with result == Target default, no? Hmmm... We already saw some compiler multiplication wackiness with the research help bug. Possibly this affected these calculations too?
:::::: As for the code, you're not updating PsiSkill, so non Psi-users can't get Psi after RPL. [[User:Cesium|Cesium]] 22:03, 21 February 2010 (EST)
::::::: I didn't write this. I'm amusing Scott did it this way to adjust for difficulty because XcomUtil.cfg has the beginner level stats. It need's an overhaul to use the full stat entries including the unknowns adjusted correctly for the level. Something for latter. --[[User:BladeFireLight|BladeFireLight]] 22:09, 21 February 2010 (EST)
:::::::: For this specific issue I think you will need to update 0x37 of [[UNITREF.DAT]] which is the Damage Modifier. For the general problem you will need to update the Psi Strength and also Firing Accuracy, energy regen rate, movement class... loads of stuff. And of course LOFTEMPS. So with current RPL not changing LOFTEMPS, changed aliens are the wrong size and shape probably. This would be visible using the LOFTEMPS map viewer I suppose. [[User:Spike|Spike]] 18:39, 9 March 2010 (EST)
*[[Known Bugs#XComUtil Inventory Stacking Bug]]
:* I hope to overcome this but Scott's notes point to a technical limitation. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*Fusion Ball Launcher fixes - detailed discussion moved to [[Talk:Fusion_Ball_Launcher#XComUtil_FBL_Issues]]
** Profitability (inconsistency item) - becomes most profitable item when using Alternate Laser (and Plasma) Tech option. Recommendation - workshop space and Engineer hours x10, 4 Alloys, 20 Elerium. And make it more useful (see below).
** Usefulness ''(wish list item)'' - perceived as being not very useful with standard stats. Recommendation - increase ammo to 3. Leave damage as-is to allow for Tougher UFOs (see Wish List).
*Zrbite lying around in odd places. Objects lying around in odd places in general - these are map modifying errors, probably only occur when customising terrain etc.
:: Will be part of an overhaul of the BFG --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*There is a small problem in editing/customising craft using '''XComUtil.cfg'''. Certain X-Com craft weapon values - the rate of fire value - can't be set. Or more specifically, they can be set (patched) in the executable but it has no effect in the game. To avoid confusion they should perhaps be removed from the format of custom craft, or commented out. (This rate of fire patching ''might'' work on UFOs, haven't tested it).
:: Can you be more specific? --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: There is a section in '''xcomutil.cfg''' which is used for patching XCom craft weapon characteristics. This is where Scott changed values for the Laser Cannon, etc. Probably very few people use these fields. I only used them because I was doing research into the game mechanics. One of the values changed in this section is the reload time. These values are present in the executable, and can be patched, but patching them has no effect (other than to change the UFOPaedia entry). The reload time seems to be hard coded elsewhere in the executable, based (broadly) on the class of weapon. So you might want to comment this column with an a note saying "cannot be modified for combat". On the other hand I could be wrong, or someone still might want to modify these fields. Discussion is at [[Talk:UFO_Interception#Observed_Rates_of_Fire]]. Offsets are at [[Talk:GEOSCAPE.EXE#Craft_weapon_stats]]. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
:::: Or maybe change these display-only values so that they reflect the [[Talk:UFO_Interception#Observed_Rates_of_Fire|observed reload rates]]? I am not yet 100% sure I have got these right, might want to wait until I do some more confirmation tests. [[User:Spike|Spike]] 15:26, 22 February 2010 (EST)
*EQL only works on turn 1 (see discussion above)
::: Added to my to do list. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*Research Help from Captured Aliens awards research help without checking first if you have Alien Containment at the base of origin. Resulting in dead aliens helping you with your enquiries! Possibly only applies to AutoCombat? [[User:Spike|Spike]] 21:05, 14 March 2010 (EDT)
:: Ideally it would not only check for containment but also have a research item for it and check on how many scientist days had been reduced since the last combat and use that as a value for how much you get form the aliens still in containment. But that could just be a pipe dream. Checking for containment for now is a good idea. --[[User:BladeFireLight|BladeFireLight]] 15:35, 16 March 2010 (EDT)

==Fixed Bugs==
*don't prevent patching windows version while running in dosbox, or vice versa
:*Fixed: XcuSetup can be run independantly to the OS RunXcom is used in.
*4DOS and MS-DOS 5 dont like "-" in variable names.
:*Fixed
*Enviroment space reached quickly on most DOS envirments.
:*Partly Fixed: Requirement has been drasticly reduced to to ~1024 use of Command.com /e:xxxx still may be required
*EnvClean.bat has an error in line 172: ser -> set.
:* Fixed in build 204.
*ANSI escape sequences aren't necessarily supported on a real dos environment/emulation
:*Fixed: ANSI only used in DOSBox
*If all the aliens are down (some of them stunned), the last save is named "AutoCombat" and I end turn, XcomUtil may still run "AutoCombat" phase. This may have slightly different results than end of combat would have had
:*Fixed: Autocombat will not run if you have already won.
*A fully loaded Hammerhead's initial deployment has three aquanauts outside the craft.
:*Fixed: the unit placement for the default 12 unit craft has been added to XcomUtil.cfg
*Select terrain: dosent apear untill after I select a terrain in BFG prompting
:*Fixed
*geodata/obdata.dat get's trunkated with slecting any improved weapon.
:*Fixed: This happend because a full backup did not complete but XcuSetup does not detect it. Backup script's changed to avoid xcopy timeout on some versions of DOS. (Backups are required by SDUMP to apply patches)
*I get this error dureing backup "16-bit MS-DOS Subsystem NTVDM has encountered a System Error The handle is invalid."
:*Fixed: All NT based OS's now useing 32bit EXE's
* You can get X-COM MIA if you abort a mission, even if everyone is in the exit. Possibly a second stage bug only? See [[Image:X-COM_MIA.zip]]. Note that this only affects the report - after mission all the X-COM troops are still available.
:*NOT Fixed: This happens even on vanilla TFTD with that save. Given it's TFTD it could be an issue with the mapfiles. --[[User:BladeFireLight|BladeFireLight]] 00:23, 24 February 2010 (EST)
*Various second stage bugs - ammo clip recovery, crashes after autocombat of first stage, etc. Mainly for TFTD, but possibly Cydonia in UFO is also affected.
:*Fixed: Clip recoverty no longer ran between parts of 2-3 part missions. Autocombat only crashes on two part if you are aborting the second stage and the save in slot 10 is from the first stage. Stage comparisons are now done to abort autocmbat if you do this.
*Removal of Small Scout map / Survey Ship map, making it impossible to do these Battlescape missions.
:*Fixed: 9.7 only removes the maps if you use the BFG. I hope to have 9.8 not remove them at all. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*The XcuSetup prompt for the option of less-profitable weapons manufacturing is misleadingly called "new laser weapons".
:*Fixed: Renamed to Alternate Lasor weapons.
* SteamSetup.bat won't run from DOSBox. It says "This needs to be run from Windows". Though, does it make any sense to run SteamSetup.bat under DOSBox (eg for a linux system with no Steam)? [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
:*NOT Fixed: STEAM dosent give access by default to the command prompt. If you know how to add that then you should know enought of DOS not to need the STEAM menu. --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
* '''cfg/ShipDefU.txt''' has the XCU values for improved Laser Cannon (35/35/35), not the original values (21/35/70). Is this correct - is this file supposed to be the original defaults? [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)
:*Fixed: I was unawhare that this had been changed. The weapons are not prompted for any change so they should not be changed. I'm reseting them all to defaults and looking to see if Scott had anything about them in the notes. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
* standalone patches the fix the difficulty bug
:*Partialy Fixed: 9.7 min install is the dificulty patch and changeing Copy protection questions to all 0's.
*Version detection issues with obscure versions (Italian, 1.2a, etc.) causing corruption or lack of patching.
:*Fixed: Added support and patching offsets.
*Various default options make the game easier, not harder (''harder'' being the intent of XComUtil, right?). These should not be defaults. (More discussion at [[Talk:Enemy_Unknown_Extended#Standard_Config_Discussions]]) E.g.
::: 9.7 only has 3 items on by default. Remove copy protection. Fix Difficulty bug and Split EXE (split EXE can be skiped but not the others). All other options are default to NO.
::: As for the intent of XcomUtil. Scott added features to
:::# Increase difficulty.
:::# Make useless items useful.
:::# Get the game Started faster.
::: I have added:
:::# Don't make unwanted changes.
:::# Fix game bugs
:::::Yes all of those are very sensible. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
::::Latter versions of XcomUtil will turn the last two forced items to prompted. with only the Difficulty bug and the split EXE as Default=Yes. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Basic tanks using advanced tank stats
**Improved High Explosive - very powerful in favour of X-Com, especially as alien spawn points and routes aren't set up to cover holes in UFO hulls.
:*Gauss weapons have infinite ammo
::: 9.7 has a second option to just the increase power to closer match UFO.
:*Using fighters as transports (carrying soldiers)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Using transports as fighters (weapon hardpoints)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Improved Heavy Laser / Heavy Gauss. OK, this should maybe be a ''recommended'' option since the unpatched weapons are nearly pointless. But, it does make the game easier. [[User:Spike|Spike]] 20:12, 7 February 2010 (EST)
*FreeDOS breaks horribly dering Setup
:*This is most likely an issue with the limits of FreeDOS.
:** Actually, this seems to work well for the latest builds (tested with FreeCOM 0.84 under dosemu). [[User:Cesium|Cesium]] 18:07, 14 March 2010 (EDT)

=XComUtil Wish List=
Things that are not bugs or inconsistencies in XComUtil but would be Nice To Have

== Features for 9.7 - Interface, consistency and bug fixes ==

=== Categorise Config Options ===

For each option, in the prompt, note which category of option this is, according your list above. E.g. faster start, making the game harder, making useless items useful, bug fix, variant game, etc. [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)

:Actually it might be even better to organise the options questions into sections, thematically grouped by these categories. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

:: Items are currently sorted like this.
* Windows EXE
* Game Fixes
* Game Mods
** Sound
** Craft
** Base
** Equipment
** Research
** Units
** Battlefield
** Alien Craft
** Misc
--[[User:BladeFireLight|BladeFireLight]] 19:25, 10 March 2010 (EST)

=== Improved Pistol Modification ===
*Remove 3rd burst for Pistol
Detailed discussion moved to [[Talk:Pistol#XComUtil_Burst_Mode_Pistol]] to de-clutter this page. Summarised recommendations will be posted back here based on whatever consensus emerges.

Current recommendation: Reduce auto accuracy from 60% to 20%, with the same TUs (54%).When prompting, point out that no improvements are required to the Pistol to make it useful. [[User:Spike|Spike]] 08:12, 14 March 2010 (EDT)

* Dart Gun

On the other hand, the Dart Gun really is useless, even as a last ditch personal defence weapon. Auto mode, with very low accuracy (10%?), would at least give it some value as a defensive sidearm for medics, heavy weapons troops, etc. Scouts and others carrying a scanner or grenade in the other hand would still be better off using a Jet Harpoon, or even an AP HydroJet Cannon, one-handed. [[User:Spike|Spike]] 03:47, 16 March 2010 (EDT)

=== Fusion weapons inconsistently exempted from Alternate Laser Tech ===
* Fusion weapons inconsistently exempted from the "more difficult" energy weapons manufacturing option ("alternate laser Tech"). Blaster Bombs and Blaster Launchers, Fusion hovertanks and ammo, and Fusion Balls and Fusion Ball Launchers - none of these are harder to build or use with the "alternate Tech" option. Why make laser weapons/tanks and plasma weapons/tanks harder but not Fusion weapons? It's not consistent. I wonder if Scott didn't look at these because he never used Blaster Launchers or Fusion Hovertanks, as he considered them to unbalancing already? And ignored FBLs because, well, most people ignore them? But this should be consistent. Or, the "harder weapons" option could be broken down into sub options, e.g. for each weapon technology:
** Much more expensive (typically: add some exotic materials, 10x workshop space and 10x Engineer hours)
** Can/can't manufacture the battlescape weapons/tanks (pure alien weapons only)
** Can/can't manufacture the ammo (pure alien weapons only)
:Personally I would prefer it to be all-or-nothing but include the Fusion weapons as being more difficult to make and use. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
* In the meantime (ahead of introducing any changes), maybe change the prompt to "Alternate Laser and Plasma Tech"/"Alternate Gauss and Sonic Tech", and/or point out explicitly that the changes don't affect any Fusion/Blaster/Pulse Wave weapons. [[User:Spike|Spike]] 08:15, 14 March 2010 (EDT)

=== AutoCombat issues ===
* All Civilians are dead if AutoCombat is used to end a Terror mission. It's too not much of a problem, since score is likely to be positive anyway. It would possibly be an improvement to assume all civs from first stage are dead (if ran at second stage) and get a random number (using mission seed) for dead civs at current stage? [[User:Cesium|Cesium]] 07:00, 22 February 2010 (EST)
:* This is odd. Autocombat is supposed to skip over civilians when using the kill function. --[[User:BladeFireLight|BladeFireLight]] 00:18, 24 February 2010 (EST)
::*Maybe kill civilians (or not) according to the force ratios. If XCom has only enough force to win the mission, all Civilians are dead. If XCom bring a certain amount of "excessive force", all or nearly all Civilians are saved. By the way I love AutoCombat, it is great for avoiding repetitive combat and only playing the new, interesting bits. [[User:Spike|Spike]] 15:53, 22 February 2010 (EST)
:::* Thinking about this, I recalled the scenario where someone fights the mission and uses AutoCombat to hunt the last aliens (another reason AutoCombat is great). Spike's suggestion is better from pure RNG, since in this case probably all civs that were at risk already died. So lets see what we suggest XcomUtil do:
:::# Count civs from first stage if there was one as dead (since IIRC XcomUtil has no memory of first stage when exiting second stage, so we can't take them into account?).
:::# Deduct dead civs from current stage.
:::# Calculate extra dead civs using force ratio to bias the RNG (I prefer merely biasing the RNG rather than precluding results, since Xcom in general has a large variance in almost every gameplay mechanic). [[User:Cesium|Cesium]] 18:27, 22 February 2010 (EST)
* Day vs Night
** The Day/night algorithm breaks. For example, at any point when XCom has more than twice as many flare-carrying soldiers than there are remaining aliens, XCom is actually ''stronger'' in darkness than it would be in full daylight. Toward the end of a battle this is a very common situation. But fixing the algorithm is tricky. What might work is to give -10 for each Soldier in darkness, reduce from -20 to -10 for each Alien in darkness, then add back +10 for every soldier with a light source. Thus there is no way XCom can go 'net positive' from light sources.
:: If you have more units then they do you can see more of the battle field. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:::It never makes sense for XCom to be stronger at night, than during the day, for the same force ratio. But that is what happens. An example. 10 XCom soldiers with flares and 3 aliens. At night there is an extra -30 modifier for the aliens, but a +100 modifier for XCom, net +70. The same 10 soldiers against the same 3 aliens are +70 ''more'' effective in darkness than they would be in daylight. It does not make any sense. [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
** The definition of a light source should be expanded to include a Flare ''or'' an Incendiary weapon. In fact, one Incendiary-capable weapon of any type (AC/HC/HjC/GC), with appropriate Incendiary rounds carried, should be enough for the entire squad to be considered as having a light source. But this may be hard to implement without a special flag and a special pre-search for a valid Incendiary weapon, since AutoCombat normally scores by individual soldiers, not by whole squads.
:: This would take a rewrite. currently the ammo is not used by W: --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
** To be honest I would prefer that each soldier without a light source in darkness is 50% effective, each soldier with a light source (personal or squad), is 75% effective. Meanwhile how about this:

//Darkness
-10 L:-9 u:-2 // Human in Darkness

+10 L:-9 u:-2 W:-27 U:- // Human in Darkness w/Flare -OR-
+10 L:-9 u:-2 W:-4 W:-7 U:- // Human in Darkness w/In ammo and launcher HC/GC-IN -OR-
+10 L:-9 u:-2 W:-8 W:-11 U:- // Human in Darkness w/In ammo and launcher AC/HjC-IN -OR-
+10 L:-9 u:-2 W:-12 W:-15 U:- // Human in Darkness w/In ammo and launcher IN Rkt/Torp

-10 L:-9 u:4-14 // Alien in Darkness
:: Only thing I see is that this ''must'' come at the end. The U:- removes the unit from further consideration. --[[User:BladeFireLight|BladeFireLight]] 19:58, 9 March 2010 (EST)
::: Yes, to use the U: flag for this "OR" function, it must come at the end of the section for humans. That's how I have it my updated AutCombt.txt, these fragments are a bit out of context. It's not critical to have the "OR", it's just nice-to-have as it stops someone cheating by having a flare and one of each loaded incendiary launcher weapon in each hand and in their backpack, to get quadruple score. But hopefully people are unlikely to cheat at AutoCombat, there are easier ways such as the WIN flag. [[User:Spike|Spike]] 20:39, 9 March 2010 (EST)
* The Zombie is rated the same as a tank, a Chrysallid/Tentaculat or an effective Psi alien (-50). I think this is too high, as Zombies are much weaker than those units. A Zombie should be maybe -25.
: Disagree. the zombie should be slightly higher then a Chrysallid/Tentaculat as it will become one and you have to kill it twice. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:: OK good point! [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
* Area effect weapons (HE, IN, Small Launcher) should have at least the same bonus as effective-on-Auto weapons (+5). This is because they can damage/kill multiple targets. (The AC/HjC should not get both bonuses however.)

//Area Weapons. ToDo: compensating bonus for aliens. should not be cumulative. check if "effective?"
+5 u:-2 W:-4 W:-6 // Human w/HE ammo and launcher HC/GC-HE
+5 u:-2 W:-8 W:-10 // Human w/HE ammo and launcher AC/HjC-HE
+10 u:-2 W:-12 W:-13 // Human w/HE ammo and launcher Sm HE Rkt/Torp
+10 u:-2 W:-12 W:-13 // Human w/HE ammo and launcher Lg HE Rkt/Torp
+10 u:-2 W:-42 W:-43 // Human w/ Stun/Shok Launcher and ammo
+25 u:-2 W:-40 W:-41 // Human w/ Blaster/DP Launcher and ammo

-10 u:4-14 W:-42 W:-43 // Alien w/ Stun/Shok Launcher and ammo
-25 u:4-14 W:-40 W:-41 // Alien w/ Blaster/DP Launcher and ammo

::Having tested the first 2 rules, the first rule (HC-HE) does not work unless you remove the ammo specifier W:-6, making it just a test for an HC. But weirdly the second rule (AC-HE) works fine with its ammo specifier in place. Odd. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
::: The problem was due to [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Ammo loaded into a weapon by the game automatically prior to the equip phase is not caught by the W: function. When the ammo is loaded manually, both rules works fine. [[User:Spike|Spike]] 18:16, 13 March 2010 (EST)

* Pistols with the burst mode option should not count as Auto weapons (maybe they don't).
: Burst and snap are based on default stats --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
* Blaster Launchers / DPLs (with ammo) should be worth as much as a tank, e.g. +/- 50 (including the single shot effective bonus it should already get - see suggested rule above under area weapons)
* Should distinguish between tanks. Even with improved armour, a Tank/Cannon is not the same as a Fusion Hovertank. I would suggest a range of 25 for a Tank/Cannon to 75 for a Hovertank/Fusion. Maybe 40 for a Tank/Rocket, 50 for Tank/Laser, 60 for a Hovertank/Plasma?
:This does not seem to be possible with the existing ruleset as all Tanks are unit type 3
::Hmm, byte 42 of [[UNITREF.DAT]] is Rank but also Tank chassis. So this ''might'' allow distinguishing tracked tanks from hover tanks, at least. An alternative approach would be to pick some stat (that has a StatStrings statid) and set it to a different unique value for each tank type. [[User:Spike|Spike]] 18:32, 9 March 2010 (EST)
::This rule set might work:

// Tanks - distinguish chassis types.
+40 u:3-3 R:0-0 // Tank, Tracked (Cannon, Rocket, Laser)//To Test
+60 u:3-3 R:1-1 // Tank, Hover (Plasma, Fusion) //To Test

* Flying units (either side) should be worth say +/- 5
:Not possible for XCom as no statid makes a distinction between Power Suit and Flying Suit. Would be possible for aliens eg:

-5 T:0- u:6-6 // Flying Alien - Ethereal
-5 T:0- u:8-8 // Flying Alien - Floater
-5 T:1- u:13-13 // "Flying" Alien - Hallucinoid
-5 T:1- u:11-11 // "Flying" Alien - Tentaculat

* If the squad is carrying some Smoke or Dye that should be worth maybe +5 - +10. But since the aliens don't ever carry that, you need some balancing factor for them.

+1 u:-2 W:-20 // +1 per human with smoke grenade(s) (hopefully not +1 per grenade!)

* Effective melee weapons should be counted. This is particularly important in TFTD when ranged weapons may be ineffective, e.g. vs Lobstermen.
* Similarly if the enemy are in heavy armour and therefore a soldier/alien does not have an effective weapon, any HE Pack / Alien Grenade / Sonic Pulser should be counted for something (if it is "effective").

//Melee weapons
+5 u:-2 W:1- W:-26 // Human w/o effective ranged weapon but w/ Stun Rod
<s>+5 u:-2 W:3-26 // Human w/ effective Stun Rod (cumulative to above)</s>

::The second rule doesn't work at all, it looks like it counts all items of types 3-6. The "superiority" function (first value before the hyphen) does not seem to operate, probably because it is a melee weapon. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
::: did you try W:255-26 ? not that I know if it would work. AutoCombat doesn't recognize stun rods as weapons when applying damage.--[[User:BladeFireLight|BladeFireLight]] 21:01, 9 March 2010 (EST)
:::: OK, if AutoCombat rates stun rods as doing no damage, the lower range of the W: function ("superiority") will likely never work. So we can't tell whether or not a Stun Rod is "effective" vs the current enemy. In general, the Stun Rod is a pretty effective weapon. So instead we generalise and just use something like this rule set:

//Melee weapons
+5 u:-2 W:1- W:-26 // Human w/o effective ranged weapon but w/ Stun Rod
+5 u:-2 W:-26 // Human w/ effective Stun Rod (cumulative to above)

//It would be nice if AutoCombat checked for the presence of Stun Rods and used them to increase the chance of an alien casualty being stunned rather than killed.

//To Do: check if TFTD melee weapons are included in "effective" weapons by the W: statid.

//Grenades
+5 u:-2 W:1- W:-19 // Human w/o effective ranged weapon but w/ effective grenade(s)
+5 u:-2 W:1- W:-21 // Human w/o effective ranged weapon but w/ effective prox grenade(s)
+5 u:-2 W:1- W:-22 // Human w/o effective ranged weapon but w/ effective HE pack(s)
+5 u:-2 W:1- W:-44 // Human w/o effective ranged weapon but w/ effective Alien grenade(s)

-5 u:4-14 W:3-44 // -5 per Alien with effective Alien Grenade(s) (hope not -5 per grenade!)
:: Only one per unit. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)
::: Tested ok too! [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
* AutoCombat victories should award all UFO Components, not just some Navigation, Elerium and Alloys.
* Every Civilian on the map should be a penalty to XCom of maybe -5, due to the distraction effects of trying to save them / avoid killing them.

-5 u:15-16 U:- // Civilian distraction effect, no further effect

Let me know if I should try to work some of this up as AutoCombat rules. Some of it requires new coding of course, but a lot of it could probably be done with existing rules. [[User:Spike|Spike]] 13:15, 7 March 2010 (EST)
: I dont plan on any changing to the underlying code yet. Your welcome to make up a new set of rules and testing them out. --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
:: OK added some rules above. I have not tested them yet, some of the syntax might not work. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)
::: Syntax looks good to me. Give them a test and let me know how they go.
::: Just a quick note on how AutoCombat works. First the success percent chance is calculated using the AutoCombat StatStrings, dead and unconscious units dont count. (those that bleed to death are considers alive, need to fix this). If it's below AbortThreshold it aborts. If it's 100-199 then change to 90. 200+ change to 95 (success is never a guarantee.) Aliens roll d100, if over your success chance you lose. If You win. Then average damage by each side is calculated based on Loaded weapon being carried and time units. All aliens are killed or stunned by X-Com unit chosen at random. Each Alien gets a chance to wound an X-Com unit based on Success Percentage. Randomly choose unit using random damage (max is average alien damage) Leave at least one X-Com Unit alive. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)

== Features for 9.8+ - New features ==

=== TFTD Gause Tank Research Fix ===
*Have the option to make the Gauss Tank require only Gauss Cannon research - this can make it more distinct than the Sonic Displacer and maybe slightly useful for a while
:*I plan on it. just not this version. --[[User:BladeFireLight|BladeFireLight]] 20:53, 18 January 2010 (EST)

=== Improved Base Comes At Cost ===

The Improved Base is supposed to be a "faster start" option rather than a "make the game easier" option. But it does make the game easier, not least because it gives you a load of free base facility improvements. (Not to mention not having to struggle along the first month with only Small Radar and no Alien Containment) To partly avoid making the game easier, please add a sub-option that subtracts the cost of the extra facilities from your starting cash. This should be the ''full'' cost of the extra facilities, not just the difference between e.g. a Small Radar and a Large Radar.
[[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
: I dont have the offsets to the starting money ranges. so I cant do this. --[[User:BladeFireLight|BladeFireLight]] 19:13, 10 March 2010 (EST)
:: I never realised that the starting money is slightly random, I see ranges from $4,125,000 to $4,153,000, in ten samples. Does not seem to depend on Difficulty or starting base location. That is going to be a hard offset to find. [[User:Spike|Spike]] 20:36, 11 March 2010 (EST)
::: I believe there is no "starting money" anywhere to be found, or rather the starting money is effectively zero but it soon changes: the first thing the game does when you begin a new game is perform a hidden monthly report which grants you money from the funding nations. Only way to decrease it is to lower your rating toward countries (you should be able to hack the starting diplomacy data located at 0x4728F8). Or I could just patch the initial money to be negative instead of zero thus providing lower overall starting money. [[User:Seb76|Seb76]] 15:52, 12 March 2010 (EST)
:::: That makes a lot of sense. The initial money is the same as the initial funding. Doh! I should've realised that. The solution to poke a negative number into the money field, prior to the "hidden funding round", sounds a great idea.
:::: Looking at initial money vs funding, your initial cash is always $1,860,000 less than your initial funding. This $1.86M is probably made up of the first 3 rows (only) of your initial Monthly Costs: $500K transport rental, $1200K Interceptor rental, and $160K salary (not hiring fees) for 8 Soldiers. The salary (and hiring fees) for 10 Scientists and 10 Engineers are ignored. The Base Maintenance costs, $224K for a standard starting base, are also ignored. This generosity saves you at least $774K. Could this be considered a bug? Possibly.
:::: The cash value of the XComUtil Improved Base is a whopping $4.5M. This is $1.6M of facilities (Alien Containment, Large Radar, 2nd Living Quarters) and $2.9M of personnel (+10 Engineers, +40 Scientists). $4.5M would wipe out all starting cash and players would begin the game with a negative balance - quite challenging! For XComUtil, it might be best to break improved Facilities and Extra Starting Personnel into 2 options, with each having a sub-option to pay for the improvements. ''"These extra facilities/staff would cost $1.6M/$2.9M, do you want to deduct that amount from your starting cash?"'' [[User:Spike|Spike]] 20:48, 12 March 2010 (EST)

=== Easier Inventory Management ===
Inventory management is one of the things I hate about the first two X-Coms. I was hired to be a commander, not a supply clerk! A mod which made general stores have 10000 space (like Apoc) would be nice.. [[User:Cesium|Cesium]] 21:39, 9 February 2010 (EST)
: The manager of any facility has to deal with generalities of space issues. The clerk tells you if that fancy new tank you just bought will fit. He has to put it in storage and keep track of what shelf the ammo is on. --[[User:BladeFireLight|BladeFireLight]] 22:27, 9 February 2010 (EST)
:: That's the clerk's problem and if he complains too much I'll have him peel potatoes until his hands drop. In any event, the limit doesn't make any sense:
::* General stores size is 8x8x2 (8x8x3 in TFTD) per base defence map, and should have no problem storing more than 50 items.
::: The items taking up 1 item unit are typically about the size of humanoid body. I think it's not unreasonable to have no more than 50 of those in the area that the General Stores takes up.
:::: I can't find a list on the wiki of storage space requirements for items, so I'm not sure which items take up 1 item unit. Typically the main space wasters are Heavy Plasma ammo/Blaster Bombs/Stun Bombs (late game) and/or HWPs and avalanches (early game). These either are definitely not the size of a human body (ammo/Bombs), or shouldn't be stored in stores at all (HWPs gain nothing, and might as well lay around somewhere else in base).
::* The size of a fully built X-Com base is about the size of a city block (judging by comparison of base defence to terror missions), and should easily be able to hold hundreds of items even in the starting base if it's willing to put some stuff not in the general stores.
::* The space limit makes no sense. Why do Blaster Bombs and Heavy Plasma ammo take so much space whereas in the inventory view it doesn't take any more than normal ammo? Who stores <s>mini tanks</s> HWPs in the same compartment as light weapons? And the way X-Com (probably) stores ammo and explosives is scary...
::: As you suggest, extremely powerful ammunition probably requires a lot more space for safe and secure storage in-base, versus on a tactical mission. Imagine what would happen if a Blaster Bomb exploded in a base? Or was stolen? They probably use nuclear warhead style storage facilities for those. And similarly for Avalanche warheads, alien artifacts, Elerium, etc. Segregating dangerous/explosive items from other items probably uses up a lot of overhead in the construction of the storage space - think armoured, bomb-proof lockers and bulkheads, advanced security systems, airlocks, scanners, etc. This is not just like piling stuff up in your shed! And the Commander who left Elerium or Avalanche warheads lying around in his hanger or corridors would justifiably be sacked on the spot by XCom High Command. [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Well, judging by all the explosives in the hangar during base defence and the X-COM 1.0 Elerium bug, Elerium and explosive warheads ''are'' lying around in the base... And all the equipment in the General Stores is stored in ordinary lockers according to the General Stores map ;-) More to the point, if X-COM wants to store explosives safely (judging by said warheads X-COM doesn't care too much) they need a special facility for this, not to store them in the room which also contains all the base's weapons and priceless alien artifacts.

:::: Furthermore, I expect X-COM to improvise on storage in the interest of actually winning the war. X-COM does do this and ignore the limit when manufacturing stuff in-base or getting loot from missions. All that's needed is that X-COM will improvise for transfers too. I can't imagine a quartermaster informing the commander there isn't any room for the new armour and that the troops should go without. Maybe the reason X-COM doesn't pay quartermasters each month is that they keep getting themselves lynched by enraged X-COM troops...
::* Gameplay wise, inventory micromanagement is just no fun, especially in the late game when you have all the cash you need but still has to sell stuff after each combat (which can be prolonged if you haven't sold for awhile), otherwise you can't transfer items to the base where your main team is at.
::* Maybe this entire "stores" thing is a plot by the CFN to force X-Com to share its technology with them by forcing X-Com to sell sell sell. It's not like they pay X-Com the real worth of the technology anyway. [[User:Cesium|Cesium]] 23:47, 9 February 2010 (EST)
::: I think a lot of people do find the inventory management tedious, or unrealistically low. Personally I think it's about right for large equipment (missiles, tanks, bodies), but too low for small arms and personal equipment. And yes, it only reflects using the General Stores modules, not storing stuff at random points in the base - maybe fair enough. If the right offset to patch can be found, the storage limits could easily be raised. The last few bytes of [[BASE.DAT]] could be a good place to look for this offset. BASE.DAT can store up to 9,999 units of each item per base. The total limit for items per base would need to be found by experiment, but 9,999 might work for those who want to ignore inventory. For those who feel inventory management is OK but the limits set too tight, the capacity of each General Stores could be increased from 50 to 100 - assuming we can find the offset for this to patch it. [[User:Spike|Spike]] 19:50, 10 February 2010 (EST)
::::Maybe you can try there:
.text:00439C85 66 81 C5 F4 01 add bp, 500
::::[[User:Seb76|Seb76]] 13:03, 11 February 2010 (EST)
::::: Yes that works nicely. E.g. patch '''66 81 C5 E8 03''' at that location and you get 100 space per General Stores. Thanks Seb! [[User:Spike|Spike]] 18:21, 13 February 2010 (EST)
:::::: Now if only I had the offsets or search signature so we can add that as an options --[[User:BladeFireLight|BladeFireLight]] 18:24, 13 February 2010 (EST)
::::::: UFO 1.4 dos: offset 143748. TFTD 2.1 dos: offset 178462. TFTD v1 dos: offset 176861. TFTD CE: offset 252795. UFO CE: offset 236680. (all offsets are in decimal and point to the "F4 01" value to be patched).
::::::: Patching to "E8 03" has been tested on dos versions (not on CE) and it works. The "base information" screen will display the correct value, though the values to line length scale is such that the line will max at 250. [[User:Cesium|Cesium]] 05:57, 14 February 2010 (EST)
::::::::Are the preceding bytes the same from TFTD 1 and 2x? --[[User:BladeFireLight|BladeFireLight]] 17:26, 15 February 2010 (EST)
::::::::: Yes they are. '''81 C3 F4 01''' is the add instruction. [[User:Cesium|Cesium]] 17:48, 15 February 2010 (EST)
::::::::: Sig for UFO Dos is '''81 C6 F4 01''' --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
:::::::::: Do you also have the preceding bytes for UFO? with the signatures I can create a patch file for all versions --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
::::::::::: I am not sure I understand your question.. Judging the the two UFO versions I have available (1.3 per xcusetup and 1.4) the common preceding bytes are ''80 78 16 07 75 0C 80 78 3A 00 75 06'' (followed by the sig). You could try to use the sig alone - it exists only once in the file. [[User:Cesium|Cesium]] 19:35, 15 February 2010 (EST)
:::::::::::: Offset Locations are something I'm collecting but also the unique series of bytes to find them for the two geoscape/tactical that I dont have. (UFO Spanish, TFTD Italian) I hope to add a lot more options in the in the future. I do feel this one nerfs the storage system anything to get the game up and going faster is always a plus. --[[User:BladeFireLight|BladeFireLight]] 22:01, 15 February 2010 (EST)
::::::::::::: Well, you may want to add another General Stores to the improved starting base if you want to achieve the faster startup effect without "nerfing" storage system for rest of game (I prefer a "nerf" due to late-game reasons). Also, I suggest you add an message in Xcusetup to ask people to get in contact with you if they use an unknown/unrecognized version. [[User:Cesium|Cesium]] 14:27, 16 February 2010 (EST)
::: Inventory management is just as much a pain in the early game, where you almost always are out of space until your 2nd general stores is built. I like realistic constraints, but not tedium. Maybe upping the space per Stores from 50 units to 100 units would be a generally acceptable approach (now that Seb76 has kindly found the offset)? [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Yeah, that would be a great improvement. [[User:Cesium|Cesium]] 15:45, 13 February 2010 (EST)

:I can confirm Seb76 is correct, as ever. The 2 bytes at offsets '''0x39c88''' and '''0x39c89''' in geoscape.exe code for the capacity of each General Stores. Default value is 500 ('''F4 01''') which equates to 50 in-game internal capacity units. (Smallest item uses 0.1 in game capacity so I guess that is 1 unit in internal units). I am not sure about a signature. From what I can tell, the preceding bytes '''66 81 C5''' are unique in geoscape.exe, which seems pretty odd, so someone else should verify that. [[User:Spike|Spike]] 19:48, 13 February 2010 (EST)
:: Yes it is unique to CE. it does not exist in any DOS EXE, but "F4 01" can be found in 79 places. Trial and error could locate it. --[[User:BladeFireLight|BladeFireLight]] 20:50, 13 February 2010 (EST)

=== AutoCombat ===

==== Firepower Factors ====
You might want to consider replacing the weapon offensive weighting factors for Autocombat with some factors that are (inversely) related to the [[Weapon_Analysis#Quantitative_Analysis|% TUs Per Kill]]. I've tabulated these for each weapon (including tanks) vs each alien race. You would still need to account for Psi, light/darkness, and XCom armour. Plus you would need a similar offensive factor for the aliens' attacks. But I could probably help with that, I have the data that's directly comparable to the % TUs per Kill for XCom weapons. [[User:Spike|Spike]] 22:06, 12 February 2010 (EST)

==== AutoWithdrawal ====

One of the most tedious things you can try to do in XCom is to scavenge the battlefield and retreat to landing craft for an Abort. A great option would be an AutoWithdrawal, similar to an AutoCombat, but with an easier threshold of XCom vs Alien combat power.

Basically it would scavenge all loose equipment off the Battlescape - dropped friendly and alien items, friendly and alien corpses and wounded, all go back into the landing craft. Elerium, Alloys, and UFO Components would not be recovered, as this is (normally) impossible apart from full tactical victory. All friendly troops return to the landing craft. Friendly losses, and equipment recovered, would be proportional to the offensive factor ratios but much more favourable than for AutoCombat. E.g. as long as XCom factors were at least equal to Alien factors, they would be able to scavenge everything and recover without casualties. If the aliens were stronger than XCom, they would only recover part of the scavenged equipment, and risk partial casualties, at say one third the rate of AutoCombat. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

: It's too easy compared to actual game IMHO. Every time a battle went FUBAR for me, it got FUBAR all the way and I was lucky if I could salvage my own team/equipment and maybe a single alien weapon/body. An AutoWithdrawal without salvage might be useful, but perhaps instead we should change AutoCombat failure mode to work better (e.g. Make some X-COM people survive a failed AutoCombat, depending on strength vs aliens). [[User:Cesium|Cesium]] 15:00, 7 March 2010 (EST)

:: Yes fair point. I was not thinking of the FUBAR situations, and you are right about how hairy those are. I was thinking of the situation where you control a certain part of the battlefield, but you either don't want to go on an endless hunt for the last few aliens, or you pretty much know you can't take on the aliens that are left (e.g. in the UFO or some other stronghold) without getting creamed. You can exercise a safe withdrawal, it's just tedious to carry out all the bodies and equipment. But it's pretty hard for an AutoCombat algorithm to detect which of those situations it is - FUBAR, boredom, or tactical withdrawal. I'll have to think about that, there may be no realistic solution at all. And there is the existing "teleport loose items back to base" command line option to XComUtil, maybe that's enough. [[User:Spike|Spike]] 16:08, 7 March 2010 (EST)

=== Tougher UFOs ===

[[Wish_List_(EU)#Tougher_UFOs|Tougher UFOs]]
As this is entirely implemented by patching data and data files it is a good candidate for XComUtil rather than [[UFO Extender]].
: That would definitely make the game harder. 9.7 is about the installer and the bug fixes. This would be a good candidate for 9.8. --[[User:BladeFireLight|BladeFireLight]] 01:38, 19 February 2010 (EST)
:: Cool! [[User:Spike|Spike]] 02:25, 19 February 2010 (EST)

=== Rebalanced Craft Weapons ===

This fits under the "making useless things usefull" category. It would be a 9.8 or later option. The idea is to make the Cannon, Stingray, Laser Cannon and Fusion Ball Launcher useful. Hopefully it breaks up the monotony of Dual Avalanches followed by Dual Plasma Beams, every game.

There is one common element in the approach, and two options. The common element is to fix the stats on the Fusion Ball Launcher. The two options are to use a stat-based approach, or a cost-based approach, to fix the other weapons.

NB This proposal is still a draft and will need tweaking, but I've got it to the point where it is worth discussing. Feedback is welcome!

''(Ultimately, the Plasma Beam still ends up being pretty much the optimum weapon in the end game. To mitigate this, it is a good idea to select the existing Alternate Energy Weapons Manufacturing option in XComUtil.)''

==== Fusion Ball Launcher ====

Increase the ammo capacity from 2 to 3. Don't mess with the damage. Job done.

See [[User:Spike#Fusion_Ball_Launcher]] and discussions linked from there.

==== Cost Based Approach ====

This uses historically realistic costs to restore game balance between different craft weapons. The stand off advantage of Avalanche missiles is now purchased at a price which is significant in terms of XCom budgets and mission yields. Stingrays and Cannons become significantly cheaper alternatives. The Laser Cannon, with similar capabilities to Stingrays but free to operate, also becomes very attractive. Mounting dual launched weapons becomes a very expensive luxury.

*Increase Avalanche missile Purchase cost to $386,000
*Increase Stingray missile Purchase cost to $125,000
*Leave Sell prices unmodified (to avoid creating a cash reservoir at the start of the game)
*Leave Launcher buy/sell prices unmodified

See [[User:Spike#Cost_Based_Rebalancing]]

==== Stat Based Approach ====

This provides a benefit trade-off to shorter range weapons, by increasing their firepower or effectiveness relative to longer range weapons.

*Increase Cannon stats to 15 Damage, 50% hit. Firepower is tripled, slightly ahead of (unmodified) Avalanches launching in Aggressive mode. Increase rearming rate to 200.
*Increase Stingray accuracy to 80%. Decrease Avalanche accuracy to 60%. Stingray now has 50% more firepower relative to Avalanche. Increase Stingray rearming rate to 2, so a full craft can be re-armed in the same time period with either weapon (instead of twice as long for Stingray).
*Increase Laser Cannon stats to 100 Damage, 50% hit. Firepower is doubled, 20% more than (unmodified) Avalanches launching in Aggressive mode, 2/3rds of Plasma Beam firepower.

To avoid advanced XCom aircraft exploiting the extra firepower of the Cannon weapons and disregarding the return fire from UFOs, this is best used alongside the Tougher UFOs option.

See [[User:Spike#Stat_Based_Rebalancing]]

=== Rebalanced Infantry Weapons ===

See [[User:Spike#Balancing_Infantry_Weapons]]

Primarily this means making the Rifle a bit stronger, and probably making the Pistol a bit weaker.

==See Also==

[[Wish List]]

= Completed Wish List Items =

=== BFG Default To Unchanged ===

Is it possible when using the BattleFieldGenerator, for it to detect the actual conditions for the mission (terrain, enemy craft, and light level) and offer these as defaults? [[User:Spike|Spike]] 08:22, 13 February 2010 (EST)
:Press The esc key at the prompt. (Line 719 in Xcomutil.txt, not that I expect anyone to read the manual :) ) Enter should also work. --[[User:BladeFireLight|BladeFireLight]] 12:34, 13 February 2010 (EST)
:: RTFM eh? My biggest failing. Maybe you could add an explicit prompt "Esc or Enter = [whatever the unmodified value would be]". [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)
::: From what I can see, hitting Escape during BFG makes it continue with ''all'' values reverting to the original conditions. It would be nice to be able to select some but not all original conditions. My main use of this is to turn a night mission into a day mission without the hassle of keeping the landing craft hovering around until the terminator crosses the landing site. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
:::: You could just use the force all daylight option.
:::: After reviewing Scott's code. Esc leaves all setting as-is. Pressing enter or any other key not listed will randomly choose for you. I will see if I can change enter to leave as is. --[[User:BladeFireLight|BladeFireLight]] 11:00, 7 March 2010 (EST)
::::: This has been added --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)

= MISC =

* It's actually quite hard to downgrade to DOSBox 0.72 in Ubuntu. Only 0.73 is offered, there is no ability to Force back to a lower package level with Synaptic Package Manager. Unix guru skilz are required to rollback to 0.72, and I guess 0.74 is not around yet, or not packaged for Ubunut APT? Is there any way to fudge around this, e.g. by providing the command line arguments in an optional text file for xcusetup.bat to parse? Having said that, even with no command line arguments, xcusetup hangs on my 0.73 DOSBox while executing SDUMP. I had to reboot in Windows to run xcusetup.bat - something that is only possible on a dual boot machine / Wubi machine. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
** Try using a different batch interpreter like 4DOS [http://www.4dos.info] to execute xcusetup inside DosBox. I tested this throughly before under DosBox/Linux and it works well with recent 9.7 builds. I suggest running "config -set cpu core=dynamic" and "config -set cpu cycles=max" before xcusetup to speed it up (xcusetup doesn't detect DosBox when 4Dos is run, so it doesn't run these automatically unlike normal DosBox case). [[User:Cesium|Cesium]] 09:48, 7 March 2010 (EST)
** Oh, and downgrading isn't that difficult: Get a dosbox 0.72 deb, and run "dpkg -i" on it, and then do "echo dosbox hold | dpkg --set-selections" to prevent future upgrades. [[User:Cesium|Cesium]] 09:50, 7 March 2010 (EST)
** Another option is to install the dosemu package, and run xcusetup under that. EU/TFTD can be run under that, but it doesn't work as well there. (Oh, and there's no mount command there. UFO/TFTD needs to exist under ~/.dosemu/drive_c which is C:) [[User:Cesium|Cesium]] 11:42, 7 March 2010 (EST)

:Thanks Cesium I will check this out. I still think it would be good to have a solution that works for people who are not knowledgeable with the unix command line though. [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)

:: Why use Linux if you dont know how to use the console? It is a text mode OS with a separate GUI. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)

::: Well Ubuntu is a bit different, as it's supposed to be an OS for the general public, where you never need to touch text mode! Incidentally I can't find any DEB or other packages for 0.72, all that is available on the DOSBox website is the source code. They really don't seem to realise that 0.73 is buggy! So I guess I will need to '''make''' it. Or just wait for 0.74 as I think it's out soon. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)

:::: See [http://archive.ubuntu.com/ubuntu/pool/universe/d/dosbox/] for 0.72 debs. Unlike Windows, package systems in Unix land are centralized, so best location to search is typically a package server mirror or a distro mirror, not a vendor's website. [[User:Cesium|Cesium]] 17:36, 9 March 2010 (EST)

Talk:XcomUtil

2010-03-16T22:26:11Z

BladeFireLight: /* Build 435 */ Problem detecting Death.

=XcomUtil 9.7 Beta=

9.7 Beta is available on www.bladefirelight.com

==Release Notes==

This is a Beta, so backup your files before using. And check back often for newer builds.

New in this version.

*Major overhall of the installer (XcuSetup) and the inclusion of 16/32bit exe's to support both DOSBox and Windows Vista/7 x64.
*New subfolders added to hold supporting files making the install cleaner
*New XcuSetup command line arguments were added to XcuSetup allowing for silent install and uninstallation.
*New XcuSetup option for debugging the install (XcuSetup debug) creating XcomUtil\debug.txt.
*New command line argument "nobackup" skips backup only if it has been ran atleast once.
*XcuSetup can now have minimal impact on the game.
**Almost all options default to NO (Only Split Windows EXE set to Yes).
**Almost all changes are now prompted for (skyranger guns, interceptor as transport, Disjointed Base Bug, etc...).
***Items still done by default:
***Copy protection questions set to 0000000 for UFO 1.0-1.3 and X-Com 1.0
***Difficulty bug fixed in UFO 1.0-1.4 and X-Com 1.0-1.4
***Unique names for all maps in TFTD, Used for Hybrid Games
***Placement of X-Com Units on the Battlefield based on XcomUtil.cfg
***MIA Recovery on Won Combat (Units under mind\MC control when last controling alien killed are returned to X-Com control)
*XcomUtil.cfg is now pieced together and overwritten by XcuSetup (see XcomUtil\XcomUtil.txt for how to make permanent changes).
*All game files are restored to the pre-XcomUtil state each time XcuSetup is ran. Any modifications by other utilities will have to be re-applied.
*Vista/Win7 patch now an option for XcuSetup.
**This will fix the blank screen issue.
**Updated to support the split EXE.
**Will set X-Com to use CPU 0.
*XcuSetup attempts to fix UAC issues by resetting folder permissions.
*A number of community made fixes are included and selectable with XcuSetup.
*Support for the DOS/Window STEAM Install.
**Installer will detect STEAM and change steam launcher to start the XcomUtil Steam Menu (can be re-installed with XcomUtil\SteamSetup.bat
*Out of the box support for UFO Extender. XcuSetup will detect it and ask if you want RunXcom to use it.
*XcuSetup can be run from windows and RunXcom run from DosBox
*Hybrid Colors updated based on BombBloke's pallets.
*EQL flag allowed any turn.
*Add Xcom UFO Italian Support.
*Auto Combat will not run on second half of two part using first parts saved data.
*Auto Combat will no longer run if combat was won.
*MIA Recovery on won combat only.
*MIA Recovery no longer recovering units that bleed to death.
*Auto equip no longer triggers on second part of 2 stage missions.
*Combine clips skiped if between stages of 2-3 part missions.
*Updated f0dders ReadMe per his request. (XcomUtil\bugfix-readme.txt)
*Add-on support added. see XcomUtil\XcomUtil.txt and XcomUtil\Addon\Example.txt
*Prompted Terrain in BattleField Generator allows to abort or use of current setting.
*Beta versions include
**XcomUtil\XcomUtil.log includes lots of debug info
**XcomUtil\Debug.txt created by default (Release will need "debug" command argument)

Removed from this versions

*New Desert and Urban terrain. (Will be added once I have a C++ version of the Java Terrain Edit.)
*Expanded capacity Laviathan, Hammerhead and Avenger (maps avalible in XcomUtil\Patches)

NOTE: If you use DosBox, this requires DosBox 0.72 (Does not work on 0.73 due to buffer overflow setting ERRORLVEL)

===Build 435===

Original Sound Effects from UFO were re-sampled to work with 1.4 and CE.

*Add Category to option headers.
*Improve randomness by using current time instead of game date/time in srand()
*Added Option to keep Current terrain/UFO to BFG.
*Original UFO 1.2 Sounds for Geoscape and Tactical added as an option for UFO 1.4 and CE.
*Force Split EXE on STEAM. Fixes issues with setup failing.
*Reset Laser/Gauss craft weapons stats to be default.
*Example addon now uses different flag extension to avoid deletion by XcuSetup
*fix issue with Lab Screen on DosBox always screening

==Beta Disscusion==

===Build 435===
: I hope the improved randomness doesn't apply to the Aliens' d100 during AutoCombat. Otherwise, one could load-scum for success. [[User:Cesium|Cesium]] 06:33, 11 March 2010 (EST)
:: Actually it does. I can see what your getting at, but why do it that way. if you want to win the "WIN" command line option is faster and you get better loot from the UFO. also using the combat date would also swing the other way with an unwindable autocombat with an fully loaded avenger vs a survey ship. --[[User:BladeFireLight|BladeFireLight]] 17:41, 11 March 2010 (EST)
: In the setup question for sound files: "were replace" should be "were replaced". [[User:Cesium|Cesium]] 06:53, 11 March 2010 (EST)

Excellent! For the first time xcusetup.bat completed for me in Dosbox in Ubuntu. Previously the SDUMP commands were hanging it.

For the first time ever, I ran the sound setup utility. It did not response to any cursor keys, enter, tab, etc. The only key that worked was Escape, and I'm not sure what this did.

One point on the xcusetup.bat script - Ctrl C does not seem to work. On all those "press a key to continue" prompts could we also have "or 'q' to quit"?

[[User:Spike|Spike]] 18:41, 13 March 2010 (EST)

: "press a key to continue" is the Pause command. Ctrl + C works fine in Windows. DOSBox does not. The reason for the use of Pause is because an number of new players kept exiting setup early when I gave the option. Aborting early makes a mess and I dont want to have to troubleshoot it for Joe user. --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
:: OK I see, that makes a lot of sense. [[User:Spike|Spike]] 06:52, 14 March 2010 (EDT)

----

I have a strange issue. I succeed in an AutoCombat terror mission (117%) but the mission is resolved partially as if I had actually aborted the mission - all Civilians die, even though I could see 3-4 alive, my 13 soldiers outside the Skyranger go MIA, even the one who was killed by AutoCombat, and only my sergeant standing in the Skyranger makes it back. The problem is repeatable. On one occasion the sergeant was killed randomly by AutoCombat, meaning that the Skyranger flew back by itself, empty. Obviously this should never happen.

I've uploaded the [[Media:MIAoverload.zip|AutoCombat game save file]]. Incidentally this shows how to 'game' the current AutoCombat rules: Take maximum soldiers, no tanks. You give everyone a Rocket Launcher, they only need 1 Lg Rocket in it. Until you get Heavy Lasers, then replace the Rocket Launchers with them. Next replace with Heavy Plasmas. This approach always gives you maximum damage per soldier, and thus maximum chance of getting the +15 bonus for the W:3- rule. [[User:Spike|Spike]] 19:02, 15 March 2010 (EDT)

:: Hmmm. Scott's MIA recovery raised an army of undead from those that died of fatal wounds. Mine only effects mind controlled units. The issue is finding telling who is dead and who is left behind.

Units from your saved game looked like this(on by Autocombat).

Shuji Okabe: Left behind (Health > 0)
UnitPos[0x0A] 1.0.0.0.0.0.0.0
UnitRef[0x78] 0.0.0.0.0.0.1.0
Yoko Fujimoto: On Craft (Health > 0)
UnitPos[0x0A] 1.1.0.0.0.0.0.0
UnitRef[0x78] 0.0.0.1.0.0.0.0

From Bomb Blokes undead army MIA Test save (won by killing aliens).

Spencer Bryant: Lived (Health > 0)
UnitPos[0x0A] 0.1.0.0.0.1.0.0
UnitRef[0x78] 0.1.0.0.0.0.0.1
Oscar Thompson: Bleed to death (Health > 0)
UnitPos[0x0A] 0.0.0.0.0.1.0.0
UnitRef[0x78] 0.1.0.0.0.0.0.1
Virgil Hudson: Killed by Aliens (Health == 0)
UnitPos[0x0A] 0.0.0.0.0.1.0.0
UnitRef[0x78] 1.1.0.0.0.0.0.1

So right now I'm at a loss of how to detect tell the difference between thoes that are left behind and thoes that are dead.

----

Does the SHP flag still work, after the changes to how XCOMUTIL.CFG is assembled? I just tried it, after rerunning XCUSETUP.BAT (Dosbox 0.72 under Ubuntu). XCOMUTIL SHP produces no output. XCOMUTIL SHP:CFG WRT writes GEOSCAPE.EXE, but nothing seems to change. During XCUSETUP I see the expected "Patch applied, ship data updated from CFG" (or whatever). [[User:Spike|Spike]] 17:40, 16 March 2010 (EDT)
:: Yes it works fine. your mistyping the command. it's "xcomutil ufoexe shp:cfg wrt" Second argument must be the target folder. Line 42 and 1266 of XcommUtil.txt.

==Open Bugs==
*There's no Italian text for the Alternate Laser Weapons option. Applying the patch seems to work, but it displays the text for the default laser weapons.
:*Anyone want to translate the text into Italian? --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
*The number of aliens in the mission report is inconsistent with the number of live aliens captured per research help. See [[Image:Alien_numbers_mismatch.zip]] and [[Image:Dead_alien_count.zip]].
* Morale is random at start of second stage after autocombat of first stage?
:* Actually Morale is used as the clip size and time units as the weapon damage. Don't ask me why. It would take a major re-write of auto combat to fix this. --[[User:BladeFireLight|BladeFireLight]] 19:34, 23 February 2010 (EST)
*RPL bug, when you turn creatures into Gill Men, they are reported as Snakemen
:* Reported how? Is this consistent? The name's used are from xcomutil.cfg. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
::*Sorry. It's reported in morale failure pop up messages. Though maybe this is an original TFTD bug rather than an XComUtil bug. [[User:Spike|Spike]] 19:21, 21 February 2010 (EST)
:::* See this: [http://www.youtube.com/watch?v=uGlSghf7aTU]. In that case, all Gill man (were lobster man before RPL) were reported as snakemen.. [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST)
*RPL bug, when you turn Lobstermen into other creatures (e.g. Gill Men), they are very hard to kill despite having the stats of the creature they turned in to. Possibly they are keeping their damage resistance? Maybe the race is stored in more than one place, for different purposes, and XComUtil misses one of these places?
:: I will look into this --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: The RPL only changes the basics; The race, rank, name, TimeUnits, Health, Energy, Reactions, Armor(front,back,left,right), Strenght and PSI Strenght. All other stats are left as-is. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
:::: I'm not so sure about this. See 05:00 mark at [http://www.youtube.com/watch?v=y-_zLdjhUHI]. The armour doesn't match the one Gill man should have (per UFOpaedia, at least). [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST). See also 04:17 mark at [http://www.youtube.com/watch?v=z5LfzFSkRnI] for reason to suspect resistances aren't always changed. It's possible he just was unlucky though... [[User:Cesium|Cesium]] 19:53, 21 February 2010 (EST)
::::: Actually the function is something like this
<pre>#define UpdateStat(x,y) pur->x = (unsigned char) \
( ( (unsigned int)pur->x \
* (unsigned int)pasTo->y \
) / (unsigned int)pasFrom->y )
UpdateStat( TimeUnits0, TimeUnits );
UpdateStat( Health0, Health );
UpdateStat( Energy0, Energy );
UpdateStat( Reactions0, Reactions );
UpdateStat( AFront0, AFront2 );
UpdateStat( ALeft0, ALeft2 );
UpdateStat( ARight0, ARight2 );
UpdateStat( ARear0, ARear2 );
UpdateStat( AUnder0, AUnder2 );
UpdateStat( Strength, Strength );
UpdateStat( PsiStrength, PsiStrength );
</pre>
::::: the 0's are values at start of tactical.
::::: I read that as Current(from game_x) * Target default(from xcomutil.cfg) / source default (from Xcomutil.cfg) so the stats will be different. --[[User:BladeFireLight|BladeFireLight]] 21:33, 21 February 2010 (EST)
:::::: I'd have expected Current(game_x) == Source default if applied on first turn? This would end up with result == Target default, no? Hmmm... We already saw some compiler multiplication wackiness with the research help bug. Possibly this affected these calculations too?
:::::: As for the code, you're not updating PsiSkill, so non Psi-users can't get Psi after RPL. [[User:Cesium|Cesium]] 22:03, 21 February 2010 (EST)
::::::: I didn't write this. I'm amusing Scott did it this way to adjust for difficulty because XcomUtil.cfg has the beginner level stats. It need's an overhaul to use the full stat entries including the unknowns adjusted correctly for the level. Something for latter. --[[User:BladeFireLight|BladeFireLight]] 22:09, 21 February 2010 (EST)
:::::::: For this specific issue I think you will need to update 0x37 of [[UNITREF.DAT]] which is the Damage Modifier. For the general problem you will need to update the Psi Strength and also Firing Accuracy, energy regen rate, movement class... loads of stuff. And of course LOFTEMPS. So with current RPL not changing LOFTEMPS, changed aliens are the wrong size and shape probably. This would be visible using the LOFTEMPS map viewer I suppose. [[User:Spike|Spike]] 18:39, 9 March 2010 (EST)
*[[Known Bugs#XComUtil Inventory Stacking Bug]]
:* I hope to overcome this but Scott's notes point to a technical limitation. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*Fusion Ball Launcher fixes - detailed discussion moved to [[Talk:Fusion_Ball_Launcher#XComUtil_FBL_Issues]]
** Profitability (inconsistency item) - becomes most profitable item when using Alternate Laser (and Plasma) Tech option. Recommendation - workshop space and Engineer hours x10, 4 Alloys, 20 Elerium. And make it more useful (see below).
** Usefulness ''(wish list item)'' - perceived as being not very useful with standard stats. Recommendation - increase ammo to 3. Leave damage as-is to allow for Tougher UFOs (see Wish List).
*Zrbite lying around in odd places. Objects lying around in odd places in general - these are map modifying errors, probably only occur when customising terrain etc.
:: Will be part of an overhaul of the BFG --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*There is a small problem in editing/customising craft using '''XComUtil.cfg'''. Certain X-Com craft weapon values - the rate of fire value - can't be set. Or more specifically, they can be set (patched) in the executable but it has no effect in the game. To avoid confusion they should perhaps be removed from the format of custom craft, or commented out. (This rate of fire patching ''might'' work on UFOs, haven't tested it).
:: Can you be more specific? --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: There is a section in '''xcomutil.cfg''' which is used for patching XCom craft weapon characteristics. This is where Scott changed values for the Laser Cannon, etc. Probably very few people use these fields. I only used them because I was doing research into the game mechanics. One of the values changed in this section is the reload time. These values are present in the executable, and can be patched, but patching them has no effect (other than to change the UFOPaedia entry). The reload time seems to be hard coded elsewhere in the executable, based (broadly) on the class of weapon. So you might want to comment this column with an a note saying "cannot be modified for combat". On the other hand I could be wrong, or someone still might want to modify these fields. Discussion is at [[Talk:UFO_Interception#Observed_Rates_of_Fire]]. Offsets are at [[Talk:GEOSCAPE.EXE#Craft_weapon_stats]]. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
:::: Or maybe change these display-only values so that they reflect the [[Talk:UFO_Interception#Observed_Rates_of_Fire|observed reload rates]]? I am not yet 100% sure I have got these right, might want to wait until I do some more confirmation tests. [[User:Spike|Spike]] 15:26, 22 February 2010 (EST)
*EQL only works on turn 1 (see discussion above)
::: Added to my to do list. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*Research Help from Captured Aliens awards research help without checking first if you have Alien Containment at the base of origin. Resulting in dead aliens helping you with your enquiries! Possibly only applies to AutoCombat? [[User:Spike|Spike]] 21:05, 14 March 2010 (EDT)
:: Ideally it would not only check for containment but also have a research item for it and check on how many scientist days had been reduced since the last combat and use that as a value for how much you get form the aliens still in containment. But that could just be a pipe dream. Checking for containment for now is a good idea. --[[User:BladeFireLight|BladeFireLight]] 15:35, 16 March 2010 (EDT)

==Fixed Bugs==
*don't prevent patching windows version while running in dosbox, or vice versa
:*Fixed: XcuSetup can be run independantly to the OS RunXcom is used in.
*4DOS and MS-DOS 5 dont like "-" in variable names.
:*Fixed
*Enviroment space reached quickly on most DOS envirments.
:*Partly Fixed: Requirement has been drasticly reduced to to ~1024 use of Command.com /e:xxxx still may be required
*EnvClean.bat has an error in line 172: ser -> set.
:* Fixed in build 204.
*ANSI escape sequences aren't necessarily supported on a real dos environment/emulation
:*Fixed: ANSI only used in DOSBox
*If all the aliens are down (some of them stunned), the last save is named "AutoCombat" and I end turn, XcomUtil may still run "AutoCombat" phase. This may have slightly different results than end of combat would have had
:*Fixed: Autocombat will not run if you have already won.
*A fully loaded Hammerhead's initial deployment has three aquanauts outside the craft.
:*Fixed: the unit placement for the default 12 unit craft has been added to XcomUtil.cfg
*Select terrain: dosent apear untill after I select a terrain in BFG prompting
:*Fixed
*geodata/obdata.dat get's trunkated with slecting any improved weapon.
:*Fixed: This happend because a full backup did not complete but XcuSetup does not detect it. Backup script's changed to avoid xcopy timeout on some versions of DOS. (Backups are required by SDUMP to apply patches)
*I get this error dureing backup "16-bit MS-DOS Subsystem NTVDM has encountered a System Error The handle is invalid."
:*Fixed: All NT based OS's now useing 32bit EXE's
* You can get X-COM MIA if you abort a mission, even if everyone is in the exit. Possibly a second stage bug only? See [[Image:X-COM_MIA.zip]]. Note that this only affects the report - after mission all the X-COM troops are still available.
:*NOT Fixed: This happens even on vanilla TFTD with that save. Given it's TFTD it could be an issue with the mapfiles. --[[User:BladeFireLight|BladeFireLight]] 00:23, 24 February 2010 (EST)
*Various second stage bugs - ammo clip recovery, crashes after autocombat of first stage, etc. Mainly for TFTD, but possibly Cydonia in UFO is also affected.
:*Fixed: Clip recoverty no longer ran between parts of 2-3 part missions. Autocombat only crashes on two part if you are aborting the second stage and the save in slot 10 is from the first stage. Stage comparisons are now done to abort autocmbat if you do this.
*Removal of Small Scout map / Survey Ship map, making it impossible to do these Battlescape missions.
:*Fixed: 9.7 only removes the maps if you use the BFG. I hope to have 9.8 not remove them at all. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*The XcuSetup prompt for the option of less-profitable weapons manufacturing is misleadingly called "new laser weapons".
:*Fixed: Renamed to Alternate Lasor weapons.
* SteamSetup.bat won't run from DOSBox. It says "This needs to be run from Windows". Though, does it make any sense to run SteamSetup.bat under DOSBox (eg for a linux system with no Steam)? [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
:*NOT Fixed: STEAM dosent give access by default to the command prompt. If you know how to add that then you should know enought of DOS not to need the STEAM menu. --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
* '''cfg/ShipDefU.txt''' has the XCU values for improved Laser Cannon (35/35/35), not the original values (21/35/70). Is this correct - is this file supposed to be the original defaults? [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)
:*Fixed: I was unawhare that this had been changed. The weapons are not prompted for any change so they should not be changed. I'm reseting them all to defaults and looking to see if Scott had anything about them in the notes. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
* standalone patches the fix the difficulty bug
:*Partialy Fixed: 9.7 min install is the dificulty patch and changeing Copy protection questions to all 0's.
*Version detection issues with obscure versions (Italian, 1.2a, etc.) causing corruption or lack of patching.
:*Fixed: Added support and patching offsets.
*Various default options make the game easier, not harder (''harder'' being the intent of XComUtil, right?). These should not be defaults. (More discussion at [[Talk:Enemy_Unknown_Extended#Standard_Config_Discussions]]) E.g.
::: 9.7 only has 3 items on by default. Remove copy protection. Fix Difficulty bug and Split EXE (split EXE can be skiped but not the others). All other options are default to NO.
::: As for the intent of XcomUtil. Scott added features to
:::# Increase difficulty.
:::# Make useless items useful.
:::# Get the game Started faster.
::: I have added:
:::# Don't make unwanted changes.
:::# Fix game bugs
:::::Yes all of those are very sensible. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
::::Latter versions of XcomUtil will turn the last two forced items to prompted. with only the Difficulty bug and the split EXE as Default=Yes. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Basic tanks using advanced tank stats
**Improved High Explosive - very powerful in favour of X-Com, especially as alien spawn points and routes aren't set up to cover holes in UFO hulls.
:*Gauss weapons have infinite ammo
::: 9.7 has a second option to just the increase power to closer match UFO.
:*Using fighters as transports (carrying soldiers)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Using transports as fighters (weapon hardpoints)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Improved Heavy Laser / Heavy Gauss. OK, this should maybe be a ''recommended'' option since the unpatched weapons are nearly pointless. But, it does make the game easier. [[User:Spike|Spike]] 20:12, 7 February 2010 (EST)
*FreeDOS breaks horribly dering Setup
:*This is most likely an issue with the limits of FreeDOS.
:** Actually, this seems to work well for the latest builds (tested with FreeCOM 0.84 under dosemu). [[User:Cesium|Cesium]] 18:07, 14 March 2010 (EDT)

=XComUtil Wish List=
Things that are not bugs or inconsistencies in XComUtil but would be Nice To Have

== Features for 9.7 - Interface, consistency and bug fixes ==

=== Categorise Config Options ===

For each option, in the prompt, note which category of option this is, according your list above. E.g. faster start, making the game harder, making useless items useful, bug fix, variant game, etc. [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)

:Actually it might be even better to organise the options questions into sections, thematically grouped by these categories. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

:: Items are currently sorted like this.
* Windows EXE
* Game Fixes
* Game Mods
** Sound
** Craft
** Base
** Equipment
** Research
** Units
** Battlefield
** Alien Craft
** Misc
--[[User:BladeFireLight|BladeFireLight]] 19:25, 10 March 2010 (EST)

=== Improved Pistol Modification ===
*Remove 3rd burst for Pistol
Detailed discussion moved to [[Talk:Pistol#XComUtil_Burst_Mode_Pistol]] to de-clutter this page. Summarised recommendations will be posted back here based on whatever consensus emerges.

Current recommendation: Reduce auto accuracy from 60% to 20%, with the same TUs (54%).When prompting, point out that no improvements are required to the Pistol to make it useful. [[User:Spike|Spike]] 08:12, 14 March 2010 (EDT)

* Dart Gun

On the other hand, the Dart Gun really is useless, even as a last ditch personal defence weapon. Auto mode, with very low accuracy (10%?), would at least give it some value as a defensive sidearm for medics, heavy weapons troops, etc. Scouts and others carrying a scanner or grenade in the other hand would still be better off using a Jet Harpoon, or even an AP HydroJet Cannon, one-handed. [[User:Spike|Spike]] 03:47, 16 March 2010 (EDT)

=== Fusion weapons inconsistently exempted from Alternate Laser Tech ===
* Fusion weapons inconsistently exempted from the "more difficult" energy weapons manufacturing option ("alternate laser Tech"). Blaster Bombs and Blaster Launchers, Fusion hovertanks and ammo, and Fusion Balls and Fusion Ball Launchers - none of these are harder to build or use with the "alternate Tech" option. Why make laser weapons/tanks and plasma weapons/tanks harder but not Fusion weapons? It's not consistent. I wonder if Scott didn't look at these because he never used Blaster Launchers or Fusion Hovertanks, as he considered them to unbalancing already? And ignored FBLs because, well, most people ignore them? But this should be consistent. Or, the "harder weapons" option could be broken down into sub options, e.g. for each weapon technology:
** Much more expensive (typically: add some exotic materials, 10x workshop space and 10x Engineer hours)
** Can/can't manufacture the battlescape weapons/tanks (pure alien weapons only)
** Can/can't manufacture the ammo (pure alien weapons only)
:Personally I would prefer it to be all-or-nothing but include the Fusion weapons as being more difficult to make and use. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
* In the meantime (ahead of introducing any changes), maybe change the prompt to "Alternate Laser and Plasma Tech"/"Alternate Gauss and Sonic Tech", and/or point out explicitly that the changes don't affect any Fusion/Blaster/Pulse Wave weapons. [[User:Spike|Spike]] 08:15, 14 March 2010 (EDT)

=== AutoCombat issues ===
* All Civilians are dead if AutoCombat is used to end a Terror mission. It's too not much of a problem, since score is likely to be positive anyway. It would possibly be an improvement to assume all civs from first stage are dead (if ran at second stage) and get a random number (using mission seed) for dead civs at current stage? [[User:Cesium|Cesium]] 07:00, 22 February 2010 (EST)
:* This is odd. Autocombat is supposed to skip over civilians when using the kill function. --[[User:BladeFireLight|BladeFireLight]] 00:18, 24 February 2010 (EST)
::*Maybe kill civilians (or not) according to the force ratios. If XCom has only enough force to win the mission, all Civilians are dead. If XCom bring a certain amount of "excessive force", all or nearly all Civilians are saved. By the way I love AutoCombat, it is great for avoiding repetitive combat and only playing the new, interesting bits. [[User:Spike|Spike]] 15:53, 22 February 2010 (EST)
:::* Thinking about this, I recalled the scenario where someone fights the mission and uses AutoCombat to hunt the last aliens (another reason AutoCombat is great). Spike's suggestion is better from pure RNG, since in this case probably all civs that were at risk already died. So lets see what we suggest XcomUtil do:
:::# Count civs from first stage if there was one as dead (since IIRC XcomUtil has no memory of first stage when exiting second stage, so we can't take them into account?).
:::# Deduct dead civs from current stage.
:::# Calculate extra dead civs using force ratio to bias the RNG (I prefer merely biasing the RNG rather than precluding results, since Xcom in general has a large variance in almost every gameplay mechanic). [[User:Cesium|Cesium]] 18:27, 22 February 2010 (EST)
* Day vs Night
** The Day/night algorithm breaks. For example, at any point when XCom has more than twice as many flare-carrying soldiers than there are remaining aliens, XCom is actually ''stronger'' in darkness than it would be in full daylight. Toward the end of a battle this is a very common situation. But fixing the algorithm is tricky. What might work is to give -10 for each Soldier in darkness, reduce from -20 to -10 for each Alien in darkness, then add back +10 for every soldier with a light source. Thus there is no way XCom can go 'net positive' from light sources.
:: If you have more units then they do you can see more of the battle field. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:::It never makes sense for XCom to be stronger at night, than during the day, for the same force ratio. But that is what happens. An example. 10 XCom soldiers with flares and 3 aliens. At night there is an extra -30 modifier for the aliens, but a +100 modifier for XCom, net +70. The same 10 soldiers against the same 3 aliens are +70 ''more'' effective in darkness than they would be in daylight. It does not make any sense. [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
** The definition of a light source should be expanded to include a Flare ''or'' an Incendiary weapon. In fact, one Incendiary-capable weapon of any type (AC/HC/HjC/GC), with appropriate Incendiary rounds carried, should be enough for the entire squad to be considered as having a light source. But this may be hard to implement without a special flag and a special pre-search for a valid Incendiary weapon, since AutoCombat normally scores by individual soldiers, not by whole squads.
:: This would take a rewrite. currently the ammo is not used by W: --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
** To be honest I would prefer that each soldier without a light source in darkness is 50% effective, each soldier with a light source (personal or squad), is 75% effective. Meanwhile how about this:

//Darkness
-10 L:-9 u:-2 // Human in Darkness

+10 L:-9 u:-2 W:-27 U:- // Human in Darkness w/Flare -OR-
+10 L:-9 u:-2 W:-4 W:-7 U:- // Human in Darkness w/In ammo and launcher HC/GC-IN -OR-
+10 L:-9 u:-2 W:-8 W:-11 U:- // Human in Darkness w/In ammo and launcher AC/HjC-IN -OR-
+10 L:-9 u:-2 W:-12 W:-15 U:- // Human in Darkness w/In ammo and launcher IN Rkt/Torp

-10 L:-9 u:4-14 // Alien in Darkness
:: Only thing I see is that this ''must'' come at the end. The U:- removes the unit from further consideration. --[[User:BladeFireLight|BladeFireLight]] 19:58, 9 March 2010 (EST)
::: Yes, to use the U: flag for this "OR" function, it must come at the end of the section for humans. That's how I have it my updated AutCombt.txt, these fragments are a bit out of context. It's not critical to have the "OR", it's just nice-to-have as it stops someone cheating by having a flare and one of each loaded incendiary launcher weapon in each hand and in their backpack, to get quadruple score. But hopefully people are unlikely to cheat at AutoCombat, there are easier ways such as the WIN flag. [[User:Spike|Spike]] 20:39, 9 March 2010 (EST)
* The Zombie is rated the same as a tank, a Chrysallid/Tentaculat or an effective Psi alien (-50). I think this is too high, as Zombies are much weaker than those units. A Zombie should be maybe -25.
: Disagree. the zombie should be slightly higher then a Chrysallid/Tentaculat as it will become one and you have to kill it twice. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:: OK good point! [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
* Area effect weapons (HE, IN, Small Launcher) should have at least the same bonus as effective-on-Auto weapons (+5). This is because they can damage/kill multiple targets. (The AC/HjC should not get both bonuses however.)

//Area Weapons. ToDo: compensating bonus for aliens. should not be cumulative. check if "effective?"
+5 u:-2 W:-4 W:-6 // Human w/HE ammo and launcher HC/GC-HE
+5 u:-2 W:-8 W:-10 // Human w/HE ammo and launcher AC/HjC-HE
+10 u:-2 W:-12 W:-13 // Human w/HE ammo and launcher Sm HE Rkt/Torp
+10 u:-2 W:-12 W:-13 // Human w/HE ammo and launcher Lg HE Rkt/Torp
+10 u:-2 W:-42 W:-43 // Human w/ Stun/Shok Launcher and ammo
+25 u:-2 W:-40 W:-41 // Human w/ Blaster/DP Launcher and ammo

-10 u:4-14 W:-42 W:-43 // Alien w/ Stun/Shok Launcher and ammo
-25 u:4-14 W:-40 W:-41 // Alien w/ Blaster/DP Launcher and ammo

::Having tested the first 2 rules, the first rule (HC-HE) does not work unless you remove the ammo specifier W:-6, making it just a test for an HC. But weirdly the second rule (AC-HE) works fine with its ammo specifier in place. Odd. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
::: The problem was due to [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Ammo loaded into a weapon by the game automatically prior to the equip phase is not caught by the W: function. When the ammo is loaded manually, both rules works fine. [[User:Spike|Spike]] 18:16, 13 March 2010 (EST)

* Pistols with the burst mode option should not count as Auto weapons (maybe they don't).
: Burst and snap are based on default stats --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
* Blaster Launchers / DPLs (with ammo) should be worth as much as a tank, e.g. +/- 50 (including the single shot effective bonus it should already get - see suggested rule above under area weapons)
* Should distinguish between tanks. Even with improved armour, a Tank/Cannon is not the same as a Fusion Hovertank. I would suggest a range of 25 for a Tank/Cannon to 75 for a Hovertank/Fusion. Maybe 40 for a Tank/Rocket, 50 for Tank/Laser, 60 for a Hovertank/Plasma?
:This does not seem to be possible with the existing ruleset as all Tanks are unit type 3
::Hmm, byte 42 of [[UNITREF.DAT]] is Rank but also Tank chassis. So this ''might'' allow distinguishing tracked tanks from hover tanks, at least. An alternative approach would be to pick some stat (that has a StatStrings statid) and set it to a different unique value for each tank type. [[User:Spike|Spike]] 18:32, 9 March 2010 (EST)
::This rule set might work:

// Tanks - distinguish chassis types.
+40 u:3-3 R:0-0 // Tank, Tracked (Cannon, Rocket, Laser)//To Test
+60 u:3-3 R:1-1 // Tank, Hover (Plasma, Fusion) //To Test

* Flying units (either side) should be worth say +/- 5
:Not possible for XCom as no statid makes a distinction between Power Suit and Flying Suit. Would be possible for aliens eg:

-5 T:0- u:6-6 // Flying Alien - Ethereal
-5 T:0- u:8-8 // Flying Alien - Floater
-5 T:1- u:13-13 // "Flying" Alien - Hallucinoid
-5 T:1- u:11-11 // "Flying" Alien - Tentaculat

* If the squad is carrying some Smoke or Dye that should be worth maybe +5 - +10. But since the aliens don't ever carry that, you need some balancing factor for them.

+1 u:-2 W:-20 // +1 per human with smoke grenade(s) (hopefully not +1 per grenade!)

* Effective melee weapons should be counted. This is particularly important in TFTD when ranged weapons may be ineffective, e.g. vs Lobstermen.
* Similarly if the enemy are in heavy armour and therefore a soldier/alien does not have an effective weapon, any HE Pack / Alien Grenade / Sonic Pulser should be counted for something (if it is "effective").

//Melee weapons
+5 u:-2 W:1- W:-26 // Human w/o effective ranged weapon but w/ Stun Rod
<s>+5 u:-2 W:3-26 // Human w/ effective Stun Rod (cumulative to above)</s>

::The second rule doesn't work at all, it looks like it counts all items of types 3-6. The "superiority" function (first value before the hyphen) does not seem to operate, probably because it is a melee weapon. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
::: did you try W:255-26 ? not that I know if it would work. AutoCombat doesn't recognize stun rods as weapons when applying damage.--[[User:BladeFireLight|BladeFireLight]] 21:01, 9 March 2010 (EST)
:::: OK, if AutoCombat rates stun rods as doing no damage, the lower range of the W: function ("superiority") will likely never work. So we can't tell whether or not a Stun Rod is "effective" vs the current enemy. In general, the Stun Rod is a pretty effective weapon. So instead we generalise and just use something like this rule set:

//Melee weapons
+5 u:-2 W:1- W:-26 // Human w/o effective ranged weapon but w/ Stun Rod
+5 u:-2 W:-26 // Human w/ effective Stun Rod (cumulative to above)

//It would be nice if AutoCombat checked for the presence of Stun Rods and used them to increase the chance of an alien casualty being stunned rather than killed.

//To Do: check if TFTD melee weapons are included in "effective" weapons by the W: statid.

//Grenades
+5 u:-2 W:1- W:-19 // Human w/o effective ranged weapon but w/ effective grenade(s)
+5 u:-2 W:1- W:-21 // Human w/o effective ranged weapon but w/ effective prox grenade(s)
+5 u:-2 W:1- W:-22 // Human w/o effective ranged weapon but w/ effective HE pack(s)
+5 u:-2 W:1- W:-44 // Human w/o effective ranged weapon but w/ effective Alien grenade(s)

-5 u:4-14 W:3-44 // -5 per Alien with effective Alien Grenade(s) (hope not -5 per grenade!)
:: Only one per unit. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)
::: Tested ok too! [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
* AutoCombat victories should award all UFO Components, not just some Navigation, Elerium and Alloys.
* Every Civilian on the map should be a penalty to XCom of maybe -5, due to the distraction effects of trying to save them / avoid killing them.

-5 u:15-16 U:- // Civilian distraction effect, no further effect

Let me know if I should try to work some of this up as AutoCombat rules. Some of it requires new coding of course, but a lot of it could probably be done with existing rules. [[User:Spike|Spike]] 13:15, 7 March 2010 (EST)
: I dont plan on any changing to the underlying code yet. Your welcome to make up a new set of rules and testing them out. --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
:: OK added some rules above. I have not tested them yet, some of the syntax might not work. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)
::: Syntax looks good to me. Give them a test and let me know how they go.
::: Just a quick note on how AutoCombat works. First the success percent chance is calculated using the AutoCombat StatStrings, dead and unconscious units dont count. (those that bleed to death are considers alive, need to fix this). If it's below AbortThreshold it aborts. If it's 100-199 then change to 90. 200+ change to 95 (success is never a guarantee.) Aliens roll d100, if over your success chance you lose. If You win. Then average damage by each side is calculated based on Loaded weapon being carried and time units. All aliens are killed or stunned by X-Com unit chosen at random. Each Alien gets a chance to wound an X-Com unit based on Success Percentage. Randomly choose unit using random damage (max is average alien damage) Leave at least one X-Com Unit alive. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)

== Features for 9.8+ - New features ==

=== TFTD Gause Tank Research Fix ===
*Have the option to make the Gauss Tank require only Gauss Cannon research - this can make it more distinct than the Sonic Displacer and maybe slightly useful for a while
:*I plan on it. just not this version. --[[User:BladeFireLight|BladeFireLight]] 20:53, 18 January 2010 (EST)

=== Improved Base Comes At Cost ===

The Improved Base is supposed to be a "faster start" option rather than a "make the game easier" option. But it does make the game easier, not least because it gives you a load of free base facility improvements. (Not to mention not having to struggle along the first month with only Small Radar and no Alien Containment) To partly avoid making the game easier, please add a sub-option that subtracts the cost of the extra facilities from your starting cash. This should be the ''full'' cost of the extra facilities, not just the difference between e.g. a Small Radar and a Large Radar.
[[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
: I dont have the offsets to the starting money ranges. so I cant do this. --[[User:BladeFireLight|BladeFireLight]] 19:13, 10 March 2010 (EST)
:: I never realised that the starting money is slightly random, I see ranges from $4,125,000 to $4,153,000, in ten samples. Does not seem to depend on Difficulty or starting base location. That is going to be a hard offset to find. [[User:Spike|Spike]] 20:36, 11 March 2010 (EST)
::: I believe there is no "starting money" anywhere to be found, or rather the starting money is effectively zero but it soon changes: the first thing the game does when you begin a new game is perform a hidden monthly report which grants you money from the funding nations. Only way to decrease it is to lower your rating toward countries (you should be able to hack the starting diplomacy data located at 0x4728F8). Or I could just patch the initial money to be negative instead of zero thus providing lower overall starting money. [[User:Seb76|Seb76]] 15:52, 12 March 2010 (EST)
:::: That makes a lot of sense. The initial money is the same as the initial funding. Doh! I should've realised that. The solution to poke a negative number into the money field, prior to the "hidden funding round", sounds a great idea.
:::: Looking at initial money vs funding, your initial cash is always $1,860,000 less than your initial funding. This $1.86M is probably made up of the first 3 rows (only) of your initial Monthly Costs: $500K transport rental, $1200K Interceptor rental, and $160K salary (not hiring fees) for 8 Soldiers. The salary (and hiring fees) for 10 Scientists and 10 Engineers are ignored. The Base Maintenance costs, $224K for a standard starting base, are also ignored. This generosity saves you at least $774K. Could this be considered a bug? Possibly.
:::: The cash value of the XComUtil Improved Base is a whopping $4.5M. This is $1.6M of facilities (Alien Containment, Large Radar, 2nd Living Quarters) and $2.9M of personnel (+10 Engineers, +40 Scientists). $4.5M would wipe out all starting cash and players would begin the game with a negative balance - quite challenging! For XComUtil, it might be best to break improved Facilities and Extra Starting Personnel into 2 options, with each having a sub-option to pay for the improvements. ''"These extra facilities/staff would cost $1.6M/$2.9M, do you want to deduct that amount from your starting cash?"'' [[User:Spike|Spike]] 20:48, 12 March 2010 (EST)

=== Easier Inventory Management ===
Inventory management is one of the things I hate about the first two X-Coms. I was hired to be a commander, not a supply clerk! A mod which made general stores have 10000 space (like Apoc) would be nice.. [[User:Cesium|Cesium]] 21:39, 9 February 2010 (EST)
: The manager of any facility has to deal with generalities of space issues. The clerk tells you if that fancy new tank you just bought will fit. He has to put it in storage and keep track of what shelf the ammo is on. --[[User:BladeFireLight|BladeFireLight]] 22:27, 9 February 2010 (EST)
:: That's the clerk's problem and if he complains too much I'll have him peel potatoes until his hands drop. In any event, the limit doesn't make any sense:
::* General stores size is 8x8x2 (8x8x3 in TFTD) per base defence map, and should have no problem storing more than 50 items.
::: The items taking up 1 item unit are typically about the size of humanoid body. I think it's not unreasonable to have no more than 50 of those in the area that the General Stores takes up.
:::: I can't find a list on the wiki of storage space requirements for items, so I'm not sure which items take up 1 item unit. Typically the main space wasters are Heavy Plasma ammo/Blaster Bombs/Stun Bombs (late game) and/or HWPs and avalanches (early game). These either are definitely not the size of a human body (ammo/Bombs), or shouldn't be stored in stores at all (HWPs gain nothing, and might as well lay around somewhere else in base).
::* The size of a fully built X-Com base is about the size of a city block (judging by comparison of base defence to terror missions), and should easily be able to hold hundreds of items even in the starting base if it's willing to put some stuff not in the general stores.
::* The space limit makes no sense. Why do Blaster Bombs and Heavy Plasma ammo take so much space whereas in the inventory view it doesn't take any more than normal ammo? Who stores <s>mini tanks</s> HWPs in the same compartment as light weapons? And the way X-Com (probably) stores ammo and explosives is scary...
::: As you suggest, extremely powerful ammunition probably requires a lot more space for safe and secure storage in-base, versus on a tactical mission. Imagine what would happen if a Blaster Bomb exploded in a base? Or was stolen? They probably use nuclear warhead style storage facilities for those. And similarly for Avalanche warheads, alien artifacts, Elerium, etc. Segregating dangerous/explosive items from other items probably uses up a lot of overhead in the construction of the storage space - think armoured, bomb-proof lockers and bulkheads, advanced security systems, airlocks, scanners, etc. This is not just like piling stuff up in your shed! And the Commander who left Elerium or Avalanche warheads lying around in his hanger or corridors would justifiably be sacked on the spot by XCom High Command. [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Well, judging by all the explosives in the hangar during base defence and the X-COM 1.0 Elerium bug, Elerium and explosive warheads ''are'' lying around in the base... And all the equipment in the General Stores is stored in ordinary lockers according to the General Stores map ;-) More to the point, if X-COM wants to store explosives safely (judging by said warheads X-COM doesn't care too much) they need a special facility for this, not to store them in the room which also contains all the base's weapons and priceless alien artifacts.

:::: Furthermore, I expect X-COM to improvise on storage in the interest of actually winning the war. X-COM does do this and ignore the limit when manufacturing stuff in-base or getting loot from missions. All that's needed is that X-COM will improvise for transfers too. I can't imagine a quartermaster informing the commander there isn't any room for the new armour and that the troops should go without. Maybe the reason X-COM doesn't pay quartermasters each month is that they keep getting themselves lynched by enraged X-COM troops...
::* Gameplay wise, inventory micromanagement is just no fun, especially in the late game when you have all the cash you need but still has to sell stuff after each combat (which can be prolonged if you haven't sold for awhile), otherwise you can't transfer items to the base where your main team is at.
::* Maybe this entire "stores" thing is a plot by the CFN to force X-Com to share its technology with them by forcing X-Com to sell sell sell. It's not like they pay X-Com the real worth of the technology anyway. [[User:Cesium|Cesium]] 23:47, 9 February 2010 (EST)
::: I think a lot of people do find the inventory management tedious, or unrealistically low. Personally I think it's about right for large equipment (missiles, tanks, bodies), but too low for small arms and personal equipment. And yes, it only reflects using the General Stores modules, not storing stuff at random points in the base - maybe fair enough. If the right offset to patch can be found, the storage limits could easily be raised. The last few bytes of [[BASE.DAT]] could be a good place to look for this offset. BASE.DAT can store up to 9,999 units of each item per base. The total limit for items per base would need to be found by experiment, but 9,999 might work for those who want to ignore inventory. For those who feel inventory management is OK but the limits set too tight, the capacity of each General Stores could be increased from 50 to 100 - assuming we can find the offset for this to patch it. [[User:Spike|Spike]] 19:50, 10 February 2010 (EST)
::::Maybe you can try there:
.text:00439C85 66 81 C5 F4 01 add bp, 500
::::[[User:Seb76|Seb76]] 13:03, 11 February 2010 (EST)
::::: Yes that works nicely. E.g. patch '''66 81 C5 E8 03''' at that location and you get 100 space per General Stores. Thanks Seb! [[User:Spike|Spike]] 18:21, 13 February 2010 (EST)
:::::: Now if only I had the offsets or search signature so we can add that as an options --[[User:BladeFireLight|BladeFireLight]] 18:24, 13 February 2010 (EST)
::::::: UFO 1.4 dos: offset 143748. TFTD 2.1 dos: offset 178462. TFTD v1 dos: offset 176861. TFTD CE: offset 252795. UFO CE: offset 236680. (all offsets are in decimal and point to the "F4 01" value to be patched).
::::::: Patching to "E8 03" has been tested on dos versions (not on CE) and it works. The "base information" screen will display the correct value, though the values to line length scale is such that the line will max at 250. [[User:Cesium|Cesium]] 05:57, 14 February 2010 (EST)
::::::::Are the preceding bytes the same from TFTD 1 and 2x? --[[User:BladeFireLight|BladeFireLight]] 17:26, 15 February 2010 (EST)
::::::::: Yes they are. '''81 C3 F4 01''' is the add instruction. [[User:Cesium|Cesium]] 17:48, 15 February 2010 (EST)
::::::::: Sig for UFO Dos is '''81 C6 F4 01''' --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
:::::::::: Do you also have the preceding bytes for UFO? with the signatures I can create a patch file for all versions --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
::::::::::: I am not sure I understand your question.. Judging the the two UFO versions I have available (1.3 per xcusetup and 1.4) the common preceding bytes are ''80 78 16 07 75 0C 80 78 3A 00 75 06'' (followed by the sig). You could try to use the sig alone - it exists only once in the file. [[User:Cesium|Cesium]] 19:35, 15 February 2010 (EST)
:::::::::::: Offset Locations are something I'm collecting but also the unique series of bytes to find them for the two geoscape/tactical that I dont have. (UFO Spanish, TFTD Italian) I hope to add a lot more options in the in the future. I do feel this one nerfs the storage system anything to get the game up and going faster is always a plus. --[[User:BladeFireLight|BladeFireLight]] 22:01, 15 February 2010 (EST)
::::::::::::: Well, you may want to add another General Stores to the improved starting base if you want to achieve the faster startup effect without "nerfing" storage system for rest of game (I prefer a "nerf" due to late-game reasons). Also, I suggest you add an message in Xcusetup to ask people to get in contact with you if they use an unknown/unrecognized version. [[User:Cesium|Cesium]] 14:27, 16 February 2010 (EST)
::: Inventory management is just as much a pain in the early game, where you almost always are out of space until your 2nd general stores is built. I like realistic constraints, but not tedium. Maybe upping the space per Stores from 50 units to 100 units would be a generally acceptable approach (now that Seb76 has kindly found the offset)? [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Yeah, that would be a great improvement. [[User:Cesium|Cesium]] 15:45, 13 February 2010 (EST)

:I can confirm Seb76 is correct, as ever. The 2 bytes at offsets '''0x39c88''' and '''0x39c89''' in geoscape.exe code for the capacity of each General Stores. Default value is 500 ('''F4 01''') which equates to 50 in-game internal capacity units. (Smallest item uses 0.1 in game capacity so I guess that is 1 unit in internal units). I am not sure about a signature. From what I can tell, the preceding bytes '''66 81 C5''' are unique in geoscape.exe, which seems pretty odd, so someone else should verify that. [[User:Spike|Spike]] 19:48, 13 February 2010 (EST)
:: Yes it is unique to CE. it does not exist in any DOS EXE, but "F4 01" can be found in 79 places. Trial and error could locate it. --[[User:BladeFireLight|BladeFireLight]] 20:50, 13 February 2010 (EST)

=== AutoCombat ===

==== Firepower Factors ====
You might want to consider replacing the weapon offensive weighting factors for Autocombat with some factors that are (inversely) related to the [[Weapon_Analysis#Quantitative_Analysis|% TUs Per Kill]]. I've tabulated these for each weapon (including tanks) vs each alien race. You would still need to account for Psi, light/darkness, and XCom armour. Plus you would need a similar offensive factor for the aliens' attacks. But I could probably help with that, I have the data that's directly comparable to the % TUs per Kill for XCom weapons. [[User:Spike|Spike]] 22:06, 12 February 2010 (EST)

==== AutoWithdrawal ====

One of the most tedious things you can try to do in XCom is to scavenge the battlefield and retreat to landing craft for an Abort. A great option would be an AutoWithdrawal, similar to an AutoCombat, but with an easier threshold of XCom vs Alien combat power.

Basically it would scavenge all loose equipment off the Battlescape - dropped friendly and alien items, friendly and alien corpses and wounded, all go back into the landing craft. Elerium, Alloys, and UFO Components would not be recovered, as this is (normally) impossible apart from full tactical victory. All friendly troops return to the landing craft. Friendly losses, and equipment recovered, would be proportional to the offensive factor ratios but much more favourable than for AutoCombat. E.g. as long as XCom factors were at least equal to Alien factors, they would be able to scavenge everything and recover without casualties. If the aliens were stronger than XCom, they would only recover part of the scavenged equipment, and risk partial casualties, at say one third the rate of AutoCombat. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

: It's too easy compared to actual game IMHO. Every time a battle went FUBAR for me, it got FUBAR all the way and I was lucky if I could salvage my own team/equipment and maybe a single alien weapon/body. An AutoWithdrawal without salvage might be useful, but perhaps instead we should change AutoCombat failure mode to work better (e.g. Make some X-COM people survive a failed AutoCombat, depending on strength vs aliens). [[User:Cesium|Cesium]] 15:00, 7 March 2010 (EST)

:: Yes fair point. I was not thinking of the FUBAR situations, and you are right about how hairy those are. I was thinking of the situation where you control a certain part of the battlefield, but you either don't want to go on an endless hunt for the last few aliens, or you pretty much know you can't take on the aliens that are left (e.g. in the UFO or some other stronghold) without getting creamed. You can exercise a safe withdrawal, it's just tedious to carry out all the bodies and equipment. But it's pretty hard for an AutoCombat algorithm to detect which of those situations it is - FUBAR, boredom, or tactical withdrawal. I'll have to think about that, there may be no realistic solution at all. And there is the existing "teleport loose items back to base" command line option to XComUtil, maybe that's enough. [[User:Spike|Spike]] 16:08, 7 March 2010 (EST)

=== Tougher UFOs ===

[[Wish_List_(EU)#Tougher_UFOs|Tougher UFOs]]
As this is entirely implemented by patching data and data files it is a good candidate for XComUtil rather than [[UFO Extender]].
: That would definitely make the game harder. 9.7 is about the installer and the bug fixes. This would be a good candidate for 9.8. --[[User:BladeFireLight|BladeFireLight]] 01:38, 19 February 2010 (EST)
:: Cool! [[User:Spike|Spike]] 02:25, 19 February 2010 (EST)

=== Rebalanced Craft Weapons ===

This fits under the "making useless things usefull" category. It would be a 9.8 or later option. The idea is to make the Cannon, Stingray, Laser Cannon and Fusion Ball Launcher useful. Hopefully it breaks up the monotony of Dual Avalanches followed by Dual Plasma Beams, every game.

There is one common element in the approach, and two options. The common element is to fix the stats on the Fusion Ball Launcher. The two options are to use a stat-based approach, or a cost-based approach, to fix the other weapons.

NB This proposal is still a draft and will need tweaking, but I've got it to the point where it is worth discussing. Feedback is welcome!

''(Ultimately, the Plasma Beam still ends up being pretty much the optimum weapon in the end game. To mitigate this, it is a good idea to select the existing Alternate Energy Weapons Manufacturing option in XComUtil.)''

==== Fusion Ball Launcher ====

Increase the ammo capacity from 2 to 3. Don't mess with the damage. Job done.

See [[User:Spike#Fusion_Ball_Launcher]] and discussions linked from there.

==== Cost Based Approach ====

This uses historically realistic costs to restore game balance between different craft weapons. The stand off advantage of Avalanche missiles is now purchased at a price which is significant in terms of XCom budgets and mission yields. Stingrays and Cannons become significantly cheaper alternatives. The Laser Cannon, with similar capabilities to Stingrays but free to operate, also becomes very attractive. Mounting dual launched weapons becomes a very expensive luxury.

*Increase Avalanche missile Purchase cost to $386,000
*Increase Stingray missile Purchase cost to $125,000
*Leave Sell prices unmodified (to avoid creating a cash reservoir at the start of the game)
*Leave Launcher buy/sell prices unmodified

See [[User:Spike#Cost_Based_Rebalancing]]

==== Stat Based Approach ====

This provides a benefit trade-off to shorter range weapons, by increasing their firepower or effectiveness relative to longer range weapons.

*Increase Cannon stats to 15 Damage, 50% hit. Firepower is tripled, slightly ahead of (unmodified) Avalanches launching in Aggressive mode. Increase rearming rate to 200.
*Increase Stingray accuracy to 80%. Decrease Avalanche accuracy to 60%. Stingray now has 50% more firepower relative to Avalanche. Increase Stingray rearming rate to 2, so a full craft can be re-armed in the same time period with either weapon (instead of twice as long for Stingray).
*Increase Laser Cannon stats to 100 Damage, 50% hit. Firepower is doubled, 20% more than (unmodified) Avalanches launching in Aggressive mode, 2/3rds of Plasma Beam firepower.

To avoid advanced XCom aircraft exploiting the extra firepower of the Cannon weapons and disregarding the return fire from UFOs, this is best used alongside the Tougher UFOs option.

See [[User:Spike#Stat_Based_Rebalancing]]

=== Rebalanced Infantry Weapons ===

See [[User:Spike#Balancing_Infantry_Weapons]]

Primarily this means making the Rifle a bit stronger, and probably making the Pistol a bit weaker.

==See Also==

[[Wish List]]

= Completed Wish List Items =

=== BFG Default To Unchanged ===

Is it possible when using the BattleFieldGenerator, for it to detect the actual conditions for the mission (terrain, enemy craft, and light level) and offer these as defaults? [[User:Spike|Spike]] 08:22, 13 February 2010 (EST)
:Press The esc key at the prompt. (Line 719 in Xcomutil.txt, not that I expect anyone to read the manual :) ) Enter should also work. --[[User:BladeFireLight|BladeFireLight]] 12:34, 13 February 2010 (EST)
:: RTFM eh? My biggest failing. Maybe you could add an explicit prompt "Esc or Enter = [whatever the unmodified value would be]". [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)
::: From what I can see, hitting Escape during BFG makes it continue with ''all'' values reverting to the original conditions. It would be nice to be able to select some but not all original conditions. My main use of this is to turn a night mission into a day mission without the hassle of keeping the landing craft hovering around until the terminator crosses the landing site. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
:::: You could just use the force all daylight option.
:::: After reviewing Scott's code. Esc leaves all setting as-is. Pressing enter or any other key not listed will randomly choose for you. I will see if I can change enter to leave as is. --[[User:BladeFireLight|BladeFireLight]] 11:00, 7 March 2010 (EST)
::::: This has been added --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)

= MISC =

* It's actually quite hard to downgrade to DOSBox 0.72 in Ubuntu. Only 0.73 is offered, there is no ability to Force back to a lower package level with Synaptic Package Manager. Unix guru skilz are required to rollback to 0.72, and I guess 0.74 is not around yet, or not packaged for Ubunut APT? Is there any way to fudge around this, e.g. by providing the command line arguments in an optional text file for xcusetup.bat to parse? Having said that, even with no command line arguments, xcusetup hangs on my 0.73 DOSBox while executing SDUMP. I had to reboot in Windows to run xcusetup.bat - something that is only possible on a dual boot machine / Wubi machine. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
** Try using a different batch interpreter like 4DOS [http://www.4dos.info] to execute xcusetup inside DosBox. I tested this throughly before under DosBox/Linux and it works well with recent 9.7 builds. I suggest running "config -set cpu core=dynamic" and "config -set cpu cycles=max" before xcusetup to speed it up (xcusetup doesn't detect DosBox when 4Dos is run, so it doesn't run these automatically unlike normal DosBox case). [[User:Cesium|Cesium]] 09:48, 7 March 2010 (EST)
** Oh, and downgrading isn't that difficult: Get a dosbox 0.72 deb, and run "dpkg -i" on it, and then do "echo dosbox hold | dpkg --set-selections" to prevent future upgrades. [[User:Cesium|Cesium]] 09:50, 7 March 2010 (EST)
** Another option is to install the dosemu package, and run xcusetup under that. EU/TFTD can be run under that, but it doesn't work as well there. (Oh, and there's no mount command there. UFO/TFTD needs to exist under ~/.dosemu/drive_c which is C:) [[User:Cesium|Cesium]] 11:42, 7 March 2010 (EST)

:Thanks Cesium I will check this out. I still think it would be good to have a solution that works for people who are not knowledgeable with the unix command line though. [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)

:: Why use Linux if you dont know how to use the console? It is a text mode OS with a separate GUI. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)

::: Well Ubuntu is a bit different, as it's supposed to be an OS for the general public, where you never need to touch text mode! Incidentally I can't find any DEB or other packages for 0.72, all that is available on the DOSBox website is the source code. They really don't seem to realise that 0.73 is buggy! So I guess I will need to '''make''' it. Or just wait for 0.74 as I think it's out soon. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)

:::: See [http://archive.ubuntu.com/ubuntu/pool/universe/d/dosbox/] for 0.72 debs. Unlike Windows, package systems in Unix land are centralized, so best location to search is typically a package server mirror or a distro mirror, not a vendor's website. [[User:Cesium|Cesium]] 17:36, 9 March 2010 (EST)

Talk:XcomUtil

2010-03-16T22:11:00Z

BladeFireLight: /* Beta Disscusion */

=XcomUtil 9.7 Beta=

9.7 Beta is available on www.bladefirelight.com

==Release Notes==

This is a Beta, so backup your files before using. And check back often for newer builds.

New in this version.

*Major overhall of the installer (XcuSetup) and the inclusion of 16/32bit exe's to support both DOSBox and Windows Vista/7 x64.
*New subfolders added to hold supporting files making the install cleaner
*New XcuSetup command line arguments were added to XcuSetup allowing for silent install and uninstallation.
*New XcuSetup option for debugging the install (XcuSetup debug) creating XcomUtil\debug.txt.
*New command line argument "nobackup" skips backup only if it has been ran atleast once.
*XcuSetup can now have minimal impact on the game.
**Almost all options default to NO (Only Split Windows EXE set to Yes).
**Almost all changes are now prompted for (skyranger guns, interceptor as transport, Disjointed Base Bug, etc...).
***Items still done by default:
***Copy protection questions set to 0000000 for UFO 1.0-1.3 and X-Com 1.0
***Difficulty bug fixed in UFO 1.0-1.4 and X-Com 1.0-1.4
***Unique names for all maps in TFTD, Used for Hybrid Games
***Placement of X-Com Units on the Battlefield based on XcomUtil.cfg
***MIA Recovery on Won Combat (Units under mind\MC control when last controling alien killed are returned to X-Com control)
*XcomUtil.cfg is now pieced together and overwritten by XcuSetup (see XcomUtil\XcomUtil.txt for how to make permanent changes).
*All game files are restored to the pre-XcomUtil state each time XcuSetup is ran. Any modifications by other utilities will have to be re-applied.
*Vista/Win7 patch now an option for XcuSetup.
**This will fix the blank screen issue.
**Updated to support the split EXE.
**Will set X-Com to use CPU 0.
*XcuSetup attempts to fix UAC issues by resetting folder permissions.
*A number of community made fixes are included and selectable with XcuSetup.
*Support for the DOS/Window STEAM Install.
**Installer will detect STEAM and change steam launcher to start the XcomUtil Steam Menu (can be re-installed with XcomUtil\SteamSetup.bat
*Out of the box support for UFO Extender. XcuSetup will detect it and ask if you want RunXcom to use it.
*XcuSetup can be run from windows and RunXcom run from DosBox
*Hybrid Colors updated based on BombBloke's pallets.
*EQL flag allowed any turn.
*Add Xcom UFO Italian Support.
*Auto Combat will not run on second half of two part using first parts saved data.
*Auto Combat will no longer run if combat was won.
*MIA Recovery on won combat only.
*MIA Recovery no longer recovering units that bleed to death.
*Auto equip no longer triggers on second part of 2 stage missions.
*Combine clips skiped if between stages of 2-3 part missions.
*Updated f0dders ReadMe per his request. (XcomUtil\bugfix-readme.txt)
*Add-on support added. see XcomUtil\XcomUtil.txt and XcomUtil\Addon\Example.txt
*Prompted Terrain in BattleField Generator allows to abort or use of current setting.
*Beta versions include
**XcomUtil\XcomUtil.log includes lots of debug info
**XcomUtil\Debug.txt created by default (Release will need "debug" command argument)

Removed from this versions

*New Desert and Urban terrain. (Will be added once I have a C++ version of the Java Terrain Edit.)
*Expanded capacity Laviathan, Hammerhead and Avenger (maps avalible in XcomUtil\Patches)

NOTE: If you use DosBox, this requires DosBox 0.72 (Does not work on 0.73 due to buffer overflow setting ERRORLVEL)

===Build 435===

Original Sound Effects from UFO were re-sampled to work with 1.4 and CE.

*Add Category to option headers.
*Improve randomness by using current time instead of game date/time in srand()
*Added Option to keep Current terrain/UFO to BFG.
*Original UFO 1.2 Sounds for Geoscape and Tactical added as an option for UFO 1.4 and CE.
*Force Split EXE on STEAM. Fixes issues with setup failing.
*Reset Laser/Gauss craft weapons stats to be default.
*Example addon now uses different flag extension to avoid deletion by XcuSetup
*fix issue with Lab Screen on DosBox always screening

==Beta Disscusion==

===Build 435===
: I hope the improved randomness doesn't apply to the Aliens' d100 during AutoCombat. Otherwise, one could load-scum for success. [[User:Cesium|Cesium]] 06:33, 11 March 2010 (EST)
:: Actually it does. I can see what your getting at, but why do it that way. if you want to win the "WIN" command line option is faster and you get better loot from the UFO. also using the combat date would also swing the other way with an unwindable autocombat with an fully loaded avenger vs a survey ship. --[[User:BladeFireLight|BladeFireLight]] 17:41, 11 March 2010 (EST)
: In the setup question for sound files: "were replace" should be "were replaced". [[User:Cesium|Cesium]] 06:53, 11 March 2010 (EST)

Excellent! For the first time xcusetup.bat completed for me in Dosbox in Ubuntu. Previously the SDUMP commands were hanging it.

For the first time ever, I ran the sound setup utility. It did not response to any cursor keys, enter, tab, etc. The only key that worked was Escape, and I'm not sure what this did.

One point on the xcusetup.bat script - Ctrl C does not seem to work. On all those "press a key to continue" prompts could we also have "or 'q' to quit"?

[[User:Spike|Spike]] 18:41, 13 March 2010 (EST)

: "press a key to continue" is the Pause command. Ctrl + C works fine in Windows. DOSBox does not. The reason for the use of Pause is because an number of new players kept exiting setup early when I gave the option. Aborting early makes a mess and I dont want to have to troubleshoot it for Joe user. --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
:: OK I see, that makes a lot of sense. [[User:Spike|Spike]] 06:52, 14 March 2010 (EDT)

----

I have a strange issue. I succeed in an AutoCombat terror mission (117%) but the mission is resolved partially as if I had actually aborted the mission - all Civilians die, even though I could see 3-4 alive, my 13 soldiers outside the Skyranger go MIA, even the one who was killed by AutoCombat, and only my sergeant standing in the Skyranger makes it back. The problem is repeatable. On one occasion the sergeant was killed randomly by AutoCombat, meaning that the Skyranger flew back by itself, empty. Obviously this should never happen.

I've uploaded the [[Media:MIAoverload.zip|AutoCombat game save file]]. Incidentally this shows how to 'game' the current AutoCombat rules: Take maximum soldiers, no tanks. You give everyone a Rocket Launcher, they only need 1 Lg Rocket in it. Until you get Heavy Lasers, then replace the Rocket Launchers with them. Next replace with Heavy Plasmas. This approach always gives you maximum damage per soldier, and thus maximum chance of getting the +15 bonus for the W:3- rule. [[User:Spike|Spike]] 19:02, 15 March 2010 (EDT)

----

Does the SHP flag still work, after the changes to how XCOMUTIL.CFG is assembled? I just tried it, after rerunning XCUSETUP.BAT (Dosbox 0.72 under Ubuntu). XCOMUTIL SHP produces no output. XCOMUTIL SHP:CFG WRT writes GEOSCAPE.EXE, but nothing seems to change. During XCUSETUP I see the expected "Patch applied, ship data updated from CFG" (or whatever). [[User:Spike|Spike]] 17:40, 16 March 2010 (EDT)
:: Yes it works fine. your mistyping the command. it's "xcomutil ufoexe shp:cfg wrt" Second argument must be the target folder. Line 42 and 1266 of XcommUtil.txt.

==Open Bugs==
*There's no Italian text for the Alternate Laser Weapons option. Applying the patch seems to work, but it displays the text for the default laser weapons.
:*Anyone want to translate the text into Italian? --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
*The number of aliens in the mission report is inconsistent with the number of live aliens captured per research help. See [[Image:Alien_numbers_mismatch.zip]] and [[Image:Dead_alien_count.zip]].
* Morale is random at start of second stage after autocombat of first stage?
:* Actually Morale is used as the clip size and time units as the weapon damage. Don't ask me why. It would take a major re-write of auto combat to fix this. --[[User:BladeFireLight|BladeFireLight]] 19:34, 23 February 2010 (EST)
*RPL bug, when you turn creatures into Gill Men, they are reported as Snakemen
:* Reported how? Is this consistent? The name's used are from xcomutil.cfg. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
::*Sorry. It's reported in morale failure pop up messages. Though maybe this is an original TFTD bug rather than an XComUtil bug. [[User:Spike|Spike]] 19:21, 21 February 2010 (EST)
:::* See this: [http://www.youtube.com/watch?v=uGlSghf7aTU]. In that case, all Gill man (were lobster man before RPL) were reported as snakemen.. [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST)
*RPL bug, when you turn Lobstermen into other creatures (e.g. Gill Men), they are very hard to kill despite having the stats of the creature they turned in to. Possibly they are keeping their damage resistance? Maybe the race is stored in more than one place, for different purposes, and XComUtil misses one of these places?
:: I will look into this --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: The RPL only changes the basics; The race, rank, name, TimeUnits, Health, Energy, Reactions, Armor(front,back,left,right), Strenght and PSI Strenght. All other stats are left as-is. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
:::: I'm not so sure about this. See 05:00 mark at [http://www.youtube.com/watch?v=y-_zLdjhUHI]. The armour doesn't match the one Gill man should have (per UFOpaedia, at least). [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST). See also 04:17 mark at [http://www.youtube.com/watch?v=z5LfzFSkRnI] for reason to suspect resistances aren't always changed. It's possible he just was unlucky though... [[User:Cesium|Cesium]] 19:53, 21 February 2010 (EST)
::::: Actually the function is something like this
<pre>#define UpdateStat(x,y) pur->x = (unsigned char) \
( ( (unsigned int)pur->x \
* (unsigned int)pasTo->y \
) / (unsigned int)pasFrom->y )
UpdateStat( TimeUnits0, TimeUnits );
UpdateStat( Health0, Health );
UpdateStat( Energy0, Energy );
UpdateStat( Reactions0, Reactions );
UpdateStat( AFront0, AFront2 );
UpdateStat( ALeft0, ALeft2 );
UpdateStat( ARight0, ARight2 );
UpdateStat( ARear0, ARear2 );
UpdateStat( AUnder0, AUnder2 );
UpdateStat( Strength, Strength );
UpdateStat( PsiStrength, PsiStrength );
</pre>
::::: the 0's are values at start of tactical.
::::: I read that as Current(from game_x) * Target default(from xcomutil.cfg) / source default (from Xcomutil.cfg) so the stats will be different. --[[User:BladeFireLight|BladeFireLight]] 21:33, 21 February 2010 (EST)
:::::: I'd have expected Current(game_x) == Source default if applied on first turn? This would end up with result == Target default, no? Hmmm... We already saw some compiler multiplication wackiness with the research help bug. Possibly this affected these calculations too?
:::::: As for the code, you're not updating PsiSkill, so non Psi-users can't get Psi after RPL. [[User:Cesium|Cesium]] 22:03, 21 February 2010 (EST)
::::::: I didn't write this. I'm amusing Scott did it this way to adjust for difficulty because XcomUtil.cfg has the beginner level stats. It need's an overhaul to use the full stat entries including the unknowns adjusted correctly for the level. Something for latter. --[[User:BladeFireLight|BladeFireLight]] 22:09, 21 February 2010 (EST)
:::::::: For this specific issue I think you will need to update 0x37 of [[UNITREF.DAT]] which is the Damage Modifier. For the general problem you will need to update the Psi Strength and also Firing Accuracy, energy regen rate, movement class... loads of stuff. And of course LOFTEMPS. So with current RPL not changing LOFTEMPS, changed aliens are the wrong size and shape probably. This would be visible using the LOFTEMPS map viewer I suppose. [[User:Spike|Spike]] 18:39, 9 March 2010 (EST)
*[[Known Bugs#XComUtil Inventory Stacking Bug]]
:* I hope to overcome this but Scott's notes point to a technical limitation. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*Fusion Ball Launcher fixes - detailed discussion moved to [[Talk:Fusion_Ball_Launcher#XComUtil_FBL_Issues]]
** Profitability (inconsistency item) - becomes most profitable item when using Alternate Laser (and Plasma) Tech option. Recommendation - workshop space and Engineer hours x10, 4 Alloys, 20 Elerium. And make it more useful (see below).
** Usefulness ''(wish list item)'' - perceived as being not very useful with standard stats. Recommendation - increase ammo to 3. Leave damage as-is to allow for Tougher UFOs (see Wish List).
*Zrbite lying around in odd places. Objects lying around in odd places in general - these are map modifying errors, probably only occur when customising terrain etc.
:: Will be part of an overhaul of the BFG --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*There is a small problem in editing/customising craft using '''XComUtil.cfg'''. Certain X-Com craft weapon values - the rate of fire value - can't be set. Or more specifically, they can be set (patched) in the executable but it has no effect in the game. To avoid confusion they should perhaps be removed from the format of custom craft, or commented out. (This rate of fire patching ''might'' work on UFOs, haven't tested it).
:: Can you be more specific? --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: There is a section in '''xcomutil.cfg''' which is used for patching XCom craft weapon characteristics. This is where Scott changed values for the Laser Cannon, etc. Probably very few people use these fields. I only used them because I was doing research into the game mechanics. One of the values changed in this section is the reload time. These values are present in the executable, and can be patched, but patching them has no effect (other than to change the UFOPaedia entry). The reload time seems to be hard coded elsewhere in the executable, based (broadly) on the class of weapon. So you might want to comment this column with an a note saying "cannot be modified for combat". On the other hand I could be wrong, or someone still might want to modify these fields. Discussion is at [[Talk:UFO_Interception#Observed_Rates_of_Fire]]. Offsets are at [[Talk:GEOSCAPE.EXE#Craft_weapon_stats]]. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
:::: Or maybe change these display-only values so that they reflect the [[Talk:UFO_Interception#Observed_Rates_of_Fire|observed reload rates]]? I am not yet 100% sure I have got these right, might want to wait until I do some more confirmation tests. [[User:Spike|Spike]] 15:26, 22 February 2010 (EST)
*EQL only works on turn 1 (see discussion above)
::: Added to my to do list. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*Research Help from Captured Aliens awards research help without checking first if you have Alien Containment at the base of origin. Resulting in dead aliens helping you with your enquiries! Possibly only applies to AutoCombat? [[User:Spike|Spike]] 21:05, 14 March 2010 (EDT)
:: Ideally it would not only check for containment but also have a research item for it and check on how many scientist days had been reduced since the last combat and use that as a value for how much you get form the aliens still in containment. But that could just be a pipe dream. Checking for containment for now is a good idea. --[[User:BladeFireLight|BladeFireLight]] 15:35, 16 March 2010 (EDT)

==Fixed Bugs==
*don't prevent patching windows version while running in dosbox, or vice versa
:*Fixed: XcuSetup can be run independantly to the OS RunXcom is used in.
*4DOS and MS-DOS 5 dont like "-" in variable names.
:*Fixed
*Enviroment space reached quickly on most DOS envirments.
:*Partly Fixed: Requirement has been drasticly reduced to to ~1024 use of Command.com /e:xxxx still may be required
*EnvClean.bat has an error in line 172: ser -> set.
:* Fixed in build 204.
*ANSI escape sequences aren't necessarily supported on a real dos environment/emulation
:*Fixed: ANSI only used in DOSBox
*If all the aliens are down (some of them stunned), the last save is named "AutoCombat" and I end turn, XcomUtil may still run "AutoCombat" phase. This may have slightly different results than end of combat would have had
:*Fixed: Autocombat will not run if you have already won.
*A fully loaded Hammerhead's initial deployment has three aquanauts outside the craft.
:*Fixed: the unit placement for the default 12 unit craft has been added to XcomUtil.cfg
*Select terrain: dosent apear untill after I select a terrain in BFG prompting
:*Fixed
*geodata/obdata.dat get's trunkated with slecting any improved weapon.
:*Fixed: This happend because a full backup did not complete but XcuSetup does not detect it. Backup script's changed to avoid xcopy timeout on some versions of DOS. (Backups are required by SDUMP to apply patches)
*I get this error dureing backup "16-bit MS-DOS Subsystem NTVDM has encountered a System Error The handle is invalid."
:*Fixed: All NT based OS's now useing 32bit EXE's
* You can get X-COM MIA if you abort a mission, even if everyone is in the exit. Possibly a second stage bug only? See [[Image:X-COM_MIA.zip]]. Note that this only affects the report - after mission all the X-COM troops are still available.
:*NOT Fixed: This happens even on vanilla TFTD with that save. Given it's TFTD it could be an issue with the mapfiles. --[[User:BladeFireLight|BladeFireLight]] 00:23, 24 February 2010 (EST)
*Various second stage bugs - ammo clip recovery, crashes after autocombat of first stage, etc. Mainly for TFTD, but possibly Cydonia in UFO is also affected.
:*Fixed: Clip recoverty no longer ran between parts of 2-3 part missions. Autocombat only crashes on two part if you are aborting the second stage and the save in slot 10 is from the first stage. Stage comparisons are now done to abort autocmbat if you do this.
*Removal of Small Scout map / Survey Ship map, making it impossible to do these Battlescape missions.
:*Fixed: 9.7 only removes the maps if you use the BFG. I hope to have 9.8 not remove them at all. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*The XcuSetup prompt for the option of less-profitable weapons manufacturing is misleadingly called "new laser weapons".
:*Fixed: Renamed to Alternate Lasor weapons.
* SteamSetup.bat won't run from DOSBox. It says "This needs to be run from Windows". Though, does it make any sense to run SteamSetup.bat under DOSBox (eg for a linux system with no Steam)? [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
:*NOT Fixed: STEAM dosent give access by default to the command prompt. If you know how to add that then you should know enought of DOS not to need the STEAM menu. --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
* '''cfg/ShipDefU.txt''' has the XCU values for improved Laser Cannon (35/35/35), not the original values (21/35/70). Is this correct - is this file supposed to be the original defaults? [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)
:*Fixed: I was unawhare that this had been changed. The weapons are not prompted for any change so they should not be changed. I'm reseting them all to defaults and looking to see if Scott had anything about them in the notes. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
* standalone patches the fix the difficulty bug
:*Partialy Fixed: 9.7 min install is the dificulty patch and changeing Copy protection questions to all 0's.
*Version detection issues with obscure versions (Italian, 1.2a, etc.) causing corruption or lack of patching.
:*Fixed: Added support and patching offsets.
*Various default options make the game easier, not harder (''harder'' being the intent of XComUtil, right?). These should not be defaults. (More discussion at [[Talk:Enemy_Unknown_Extended#Standard_Config_Discussions]]) E.g.
::: 9.7 only has 3 items on by default. Remove copy protection. Fix Difficulty bug and Split EXE (split EXE can be skiped but not the others). All other options are default to NO.
::: As for the intent of XcomUtil. Scott added features to
:::# Increase difficulty.
:::# Make useless items useful.
:::# Get the game Started faster.
::: I have added:
:::# Don't make unwanted changes.
:::# Fix game bugs
:::::Yes all of those are very sensible. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
::::Latter versions of XcomUtil will turn the last two forced items to prompted. with only the Difficulty bug and the split EXE as Default=Yes. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Basic tanks using advanced tank stats
**Improved High Explosive - very powerful in favour of X-Com, especially as alien spawn points and routes aren't set up to cover holes in UFO hulls.
:*Gauss weapons have infinite ammo
::: 9.7 has a second option to just the increase power to closer match UFO.
:*Using fighters as transports (carrying soldiers)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Using transports as fighters (weapon hardpoints)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Improved Heavy Laser / Heavy Gauss. OK, this should maybe be a ''recommended'' option since the unpatched weapons are nearly pointless. But, it does make the game easier. [[User:Spike|Spike]] 20:12, 7 February 2010 (EST)
*FreeDOS breaks horribly dering Setup
:*This is most likely an issue with the limits of FreeDOS.
:** Actually, this seems to work well for the latest builds (tested with FreeCOM 0.84 under dosemu). [[User:Cesium|Cesium]] 18:07, 14 March 2010 (EDT)

=XComUtil Wish List=
Things that are not bugs or inconsistencies in XComUtil but would be Nice To Have

== Features for 9.7 - Interface, consistency and bug fixes ==

=== Categorise Config Options ===

For each option, in the prompt, note which category of option this is, according your list above. E.g. faster start, making the game harder, making useless items useful, bug fix, variant game, etc. [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)

:Actually it might be even better to organise the options questions into sections, thematically grouped by these categories. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

:: Items are currently sorted like this.
* Windows EXE
* Game Fixes
* Game Mods
** Sound
** Craft
** Base
** Equipment
** Research
** Units
** Battlefield
** Alien Craft
** Misc
--[[User:BladeFireLight|BladeFireLight]] 19:25, 10 March 2010 (EST)

=== Improved Pistol Modification ===
*Remove 3rd burst for Pistol
Detailed discussion moved to [[Talk:Pistol#XComUtil_Burst_Mode_Pistol]] to de-clutter this page. Summarised recommendations will be posted back here based on whatever consensus emerges.

Current recommendation: Reduce auto accuracy from 60% to 20%, with the same TUs (54%).When prompting, point out that no improvements are required to the Pistol to make it useful. [[User:Spike|Spike]] 08:12, 14 March 2010 (EDT)

* Dart Gun

On the other hand, the Dart Gun really is useless, even as a last ditch personal defence weapon. Auto mode, with very low accuracy (10%?), would at least give it some value as a defensive sidearm for medics, heavy weapons troops, etc. Scouts and others carrying a scanner or grenade in the other hand would still be better off using a Jet Harpoon, or even an AP HydroJet Cannon, one-handed. [[User:Spike|Spike]] 03:47, 16 March 2010 (EDT)

=== Fusion weapons inconsistently exempted from Alternate Laser Tech ===
* Fusion weapons inconsistently exempted from the "more difficult" energy weapons manufacturing option ("alternate laser Tech"). Blaster Bombs and Blaster Launchers, Fusion hovertanks and ammo, and Fusion Balls and Fusion Ball Launchers - none of these are harder to build or use with the "alternate Tech" option. Why make laser weapons/tanks and plasma weapons/tanks harder but not Fusion weapons? It's not consistent. I wonder if Scott didn't look at these because he never used Blaster Launchers or Fusion Hovertanks, as he considered them to unbalancing already? And ignored FBLs because, well, most people ignore them? But this should be consistent. Or, the "harder weapons" option could be broken down into sub options, e.g. for each weapon technology:
** Much more expensive (typically: add some exotic materials, 10x workshop space and 10x Engineer hours)
** Can/can't manufacture the battlescape weapons/tanks (pure alien weapons only)
** Can/can't manufacture the ammo (pure alien weapons only)
:Personally I would prefer it to be all-or-nothing but include the Fusion weapons as being more difficult to make and use. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
* In the meantime (ahead of introducing any changes), maybe change the prompt to "Alternate Laser and Plasma Tech"/"Alternate Gauss and Sonic Tech", and/or point out explicitly that the changes don't affect any Fusion/Blaster/Pulse Wave weapons. [[User:Spike|Spike]] 08:15, 14 March 2010 (EDT)

=== AutoCombat issues ===
* All Civilians are dead if AutoCombat is used to end a Terror mission. It's too not much of a problem, since score is likely to be positive anyway. It would possibly be an improvement to assume all civs from first stage are dead (if ran at second stage) and get a random number (using mission seed) for dead civs at current stage? [[User:Cesium|Cesium]] 07:00, 22 February 2010 (EST)
:* This is odd. Autocombat is supposed to skip over civilians when using the kill function. --[[User:BladeFireLight|BladeFireLight]] 00:18, 24 February 2010 (EST)
::*Maybe kill civilians (or not) according to the force ratios. If XCom has only enough force to win the mission, all Civilians are dead. If XCom bring a certain amount of "excessive force", all or nearly all Civilians are saved. By the way I love AutoCombat, it is great for avoiding repetitive combat and only playing the new, interesting bits. [[User:Spike|Spike]] 15:53, 22 February 2010 (EST)
:::* Thinking about this, I recalled the scenario where someone fights the mission and uses AutoCombat to hunt the last aliens (another reason AutoCombat is great). Spike's suggestion is better from pure RNG, since in this case probably all civs that were at risk already died. So lets see what we suggest XcomUtil do:
:::# Count civs from first stage if there was one as dead (since IIRC XcomUtil has no memory of first stage when exiting second stage, so we can't take them into account?).
:::# Deduct dead civs from current stage.
:::# Calculate extra dead civs using force ratio to bias the RNG (I prefer merely biasing the RNG rather than precluding results, since Xcom in general has a large variance in almost every gameplay mechanic). [[User:Cesium|Cesium]] 18:27, 22 February 2010 (EST)
* Day vs Night
** The Day/night algorithm breaks. For example, at any point when XCom has more than twice as many flare-carrying soldiers than there are remaining aliens, XCom is actually ''stronger'' in darkness than it would be in full daylight. Toward the end of a battle this is a very common situation. But fixing the algorithm is tricky. What might work is to give -10 for each Soldier in darkness, reduce from -20 to -10 for each Alien in darkness, then add back +10 for every soldier with a light source. Thus there is no way XCom can go 'net positive' from light sources.
:: If you have more units then they do you can see more of the battle field. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:::It never makes sense for XCom to be stronger at night, than during the day, for the same force ratio. But that is what happens. An example. 10 XCom soldiers with flares and 3 aliens. At night there is an extra -30 modifier for the aliens, but a +100 modifier for XCom, net +70. The same 10 soldiers against the same 3 aliens are +70 ''more'' effective in darkness than they would be in daylight. It does not make any sense. [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
** The definition of a light source should be expanded to include a Flare ''or'' an Incendiary weapon. In fact, one Incendiary-capable weapon of any type (AC/HC/HjC/GC), with appropriate Incendiary rounds carried, should be enough for the entire squad to be considered as having a light source. But this may be hard to implement without a special flag and a special pre-search for a valid Incendiary weapon, since AutoCombat normally scores by individual soldiers, not by whole squads.
:: This would take a rewrite. currently the ammo is not used by W: --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
** To be honest I would prefer that each soldier without a light source in darkness is 50% effective, each soldier with a light source (personal or squad), is 75% effective. Meanwhile how about this:

//Darkness
-10 L:-9 u:-2 // Human in Darkness

+10 L:-9 u:-2 W:-27 U:- // Human in Darkness w/Flare -OR-
+10 L:-9 u:-2 W:-4 W:-7 U:- // Human in Darkness w/In ammo and launcher HC/GC-IN -OR-
+10 L:-9 u:-2 W:-8 W:-11 U:- // Human in Darkness w/In ammo and launcher AC/HjC-IN -OR-
+10 L:-9 u:-2 W:-12 W:-15 U:- // Human in Darkness w/In ammo and launcher IN Rkt/Torp

-10 L:-9 u:4-14 // Alien in Darkness
:: Only thing I see is that this ''must'' come at the end. The U:- removes the unit from further consideration. --[[User:BladeFireLight|BladeFireLight]] 19:58, 9 March 2010 (EST)
::: Yes, to use the U: flag for this "OR" function, it must come at the end of the section for humans. That's how I have it my updated AutCombt.txt, these fragments are a bit out of context. It's not critical to have the "OR", it's just nice-to-have as it stops someone cheating by having a flare and one of each loaded incendiary launcher weapon in each hand and in their backpack, to get quadruple score. But hopefully people are unlikely to cheat at AutoCombat, there are easier ways such as the WIN flag. [[User:Spike|Spike]] 20:39, 9 March 2010 (EST)
* The Zombie is rated the same as a tank, a Chrysallid/Tentaculat or an effective Psi alien (-50). I think this is too high, as Zombies are much weaker than those units. A Zombie should be maybe -25.
: Disagree. the zombie should be slightly higher then a Chrysallid/Tentaculat as it will become one and you have to kill it twice. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:: OK good point! [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
* Area effect weapons (HE, IN, Small Launcher) should have at least the same bonus as effective-on-Auto weapons (+5). This is because they can damage/kill multiple targets. (The AC/HjC should not get both bonuses however.)

//Area Weapons. ToDo: compensating bonus for aliens. should not be cumulative. check if "effective?"
+5 u:-2 W:-4 W:-6 // Human w/HE ammo and launcher HC/GC-HE
+5 u:-2 W:-8 W:-10 // Human w/HE ammo and launcher AC/HjC-HE
+10 u:-2 W:-12 W:-13 // Human w/HE ammo and launcher Sm HE Rkt/Torp
+10 u:-2 W:-12 W:-13 // Human w/HE ammo and launcher Lg HE Rkt/Torp
+10 u:-2 W:-42 W:-43 // Human w/ Stun/Shok Launcher and ammo
+25 u:-2 W:-40 W:-41 // Human w/ Blaster/DP Launcher and ammo

-10 u:4-14 W:-42 W:-43 // Alien w/ Stun/Shok Launcher and ammo
-25 u:4-14 W:-40 W:-41 // Alien w/ Blaster/DP Launcher and ammo

::Having tested the first 2 rules, the first rule (HC-HE) does not work unless you remove the ammo specifier W:-6, making it just a test for an HC. But weirdly the second rule (AC-HE) works fine with its ammo specifier in place. Odd. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
::: The problem was due to [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Ammo loaded into a weapon by the game automatically prior to the equip phase is not caught by the W: function. When the ammo is loaded manually, both rules works fine. [[User:Spike|Spike]] 18:16, 13 March 2010 (EST)

* Pistols with the burst mode option should not count as Auto weapons (maybe they don't).
: Burst and snap are based on default stats --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
* Blaster Launchers / DPLs (with ammo) should be worth as much as a tank, e.g. +/- 50 (including the single shot effective bonus it should already get - see suggested rule above under area weapons)
* Should distinguish between tanks. Even with improved armour, a Tank/Cannon is not the same as a Fusion Hovertank. I would suggest a range of 25 for a Tank/Cannon to 75 for a Hovertank/Fusion. Maybe 40 for a Tank/Rocket, 50 for Tank/Laser, 60 for a Hovertank/Plasma?
:This does not seem to be possible with the existing ruleset as all Tanks are unit type 3
::Hmm, byte 42 of [[UNITREF.DAT]] is Rank but also Tank chassis. So this ''might'' allow distinguishing tracked tanks from hover tanks, at least. An alternative approach would be to pick some stat (that has a StatStrings statid) and set it to a different unique value for each tank type. [[User:Spike|Spike]] 18:32, 9 March 2010 (EST)
::This rule set might work:

// Tanks - distinguish chassis types.
+40 u:3-3 R:0-0 // Tank, Tracked (Cannon, Rocket, Laser)//To Test
+60 u:3-3 R:1-1 // Tank, Hover (Plasma, Fusion) //To Test

* Flying units (either side) should be worth say +/- 5
:Not possible for XCom as no statid makes a distinction between Power Suit and Flying Suit. Would be possible for aliens eg:

-5 T:0- u:6-6 // Flying Alien - Ethereal
-5 T:0- u:8-8 // Flying Alien - Floater
-5 T:1- u:13-13 // "Flying" Alien - Hallucinoid
-5 T:1- u:11-11 // "Flying" Alien - Tentaculat

* If the squad is carrying some Smoke or Dye that should be worth maybe +5 - +10. But since the aliens don't ever carry that, you need some balancing factor for them.

+1 u:-2 W:-20 // +1 per human with smoke grenade(s) (hopefully not +1 per grenade!)

* Effective melee weapons should be counted. This is particularly important in TFTD when ranged weapons may be ineffective, e.g. vs Lobstermen.
* Similarly if the enemy are in heavy armour and therefore a soldier/alien does not have an effective weapon, any HE Pack / Alien Grenade / Sonic Pulser should be counted for something (if it is "effective").

//Melee weapons
+5 u:-2 W:1- W:-26 // Human w/o effective ranged weapon but w/ Stun Rod
<s>+5 u:-2 W:3-26 // Human w/ effective Stun Rod (cumulative to above)</s>

::The second rule doesn't work at all, it looks like it counts all items of types 3-6. The "superiority" function (first value before the hyphen) does not seem to operate, probably because it is a melee weapon. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
::: did you try W:255-26 ? not that I know if it would work. AutoCombat doesn't recognize stun rods as weapons when applying damage.--[[User:BladeFireLight|BladeFireLight]] 21:01, 9 March 2010 (EST)
:::: OK, if AutoCombat rates stun rods as doing no damage, the lower range of the W: function ("superiority") will likely never work. So we can't tell whether or not a Stun Rod is "effective" vs the current enemy. In general, the Stun Rod is a pretty effective weapon. So instead we generalise and just use something like this rule set:

//Melee weapons
+5 u:-2 W:1- W:-26 // Human w/o effective ranged weapon but w/ Stun Rod
+5 u:-2 W:-26 // Human w/ effective Stun Rod (cumulative to above)

//It would be nice if AutoCombat checked for the presence of Stun Rods and used them to increase the chance of an alien casualty being stunned rather than killed.

//To Do: check if TFTD melee weapons are included in "effective" weapons by the W: statid.

//Grenades
+5 u:-2 W:1- W:-19 // Human w/o effective ranged weapon but w/ effective grenade(s)
+5 u:-2 W:1- W:-21 // Human w/o effective ranged weapon but w/ effective prox grenade(s)
+5 u:-2 W:1- W:-22 // Human w/o effective ranged weapon but w/ effective HE pack(s)
+5 u:-2 W:1- W:-44 // Human w/o effective ranged weapon but w/ effective Alien grenade(s)

-5 u:4-14 W:3-44 // -5 per Alien with effective Alien Grenade(s) (hope not -5 per grenade!)
:: Only one per unit. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)
::: Tested ok too! [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
* AutoCombat victories should award all UFO Components, not just some Navigation, Elerium and Alloys.
* Every Civilian on the map should be a penalty to XCom of maybe -5, due to the distraction effects of trying to save them / avoid killing them.

-5 u:15-16 U:- // Civilian distraction effect, no further effect

Let me know if I should try to work some of this up as AutoCombat rules. Some of it requires new coding of course, but a lot of it could probably be done with existing rules. [[User:Spike|Spike]] 13:15, 7 March 2010 (EST)
: I dont plan on any changing to the underlying code yet. Your welcome to make up a new set of rules and testing them out. --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
:: OK added some rules above. I have not tested them yet, some of the syntax might not work. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)
::: Syntax looks good to me. Give them a test and let me know how they go.
::: Just a quick note on how AutoCombat works. First the success percent chance is calculated using the AutoCombat StatStrings, dead and unconscious units dont count. (those that bleed to death are considers alive, need to fix this). If it's below AbortThreshold it aborts. If it's 100-199 then change to 90. 200+ change to 95 (success is never a guarantee.) Aliens roll d100, if over your success chance you lose. If You win. Then average damage by each side is calculated based on Loaded weapon being carried and time units. All aliens are killed or stunned by X-Com unit chosen at random. Each Alien gets a chance to wound an X-Com unit based on Success Percentage. Randomly choose unit using random damage (max is average alien damage) Leave at least one X-Com Unit alive. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)

== Features for 9.8+ - New features ==

=== TFTD Gause Tank Research Fix ===
*Have the option to make the Gauss Tank require only Gauss Cannon research - this can make it more distinct than the Sonic Displacer and maybe slightly useful for a while
:*I plan on it. just not this version. --[[User:BladeFireLight|BladeFireLight]] 20:53, 18 January 2010 (EST)

=== Improved Base Comes At Cost ===

The Improved Base is supposed to be a "faster start" option rather than a "make the game easier" option. But it does make the game easier, not least because it gives you a load of free base facility improvements. (Not to mention not having to struggle along the first month with only Small Radar and no Alien Containment) To partly avoid making the game easier, please add a sub-option that subtracts the cost of the extra facilities from your starting cash. This should be the ''full'' cost of the extra facilities, not just the difference between e.g. a Small Radar and a Large Radar.
[[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
: I dont have the offsets to the starting money ranges. so I cant do this. --[[User:BladeFireLight|BladeFireLight]] 19:13, 10 March 2010 (EST)
:: I never realised that the starting money is slightly random, I see ranges from $4,125,000 to $4,153,000, in ten samples. Does not seem to depend on Difficulty or starting base location. That is going to be a hard offset to find. [[User:Spike|Spike]] 20:36, 11 March 2010 (EST)
::: I believe there is no "starting money" anywhere to be found, or rather the starting money is effectively zero but it soon changes: the first thing the game does when you begin a new game is perform a hidden monthly report which grants you money from the funding nations. Only way to decrease it is to lower your rating toward countries (you should be able to hack the starting diplomacy data located at 0x4728F8). Or I could just patch the initial money to be negative instead of zero thus providing lower overall starting money. [[User:Seb76|Seb76]] 15:52, 12 March 2010 (EST)
:::: That makes a lot of sense. The initial money is the same as the initial funding. Doh! I should've realised that. The solution to poke a negative number into the money field, prior to the "hidden funding round", sounds a great idea.
:::: Looking at initial money vs funding, your initial cash is always $1,860,000 less than your initial funding. This $1.86M is probably made up of the first 3 rows (only) of your initial Monthly Costs: $500K transport rental, $1200K Interceptor rental, and $160K salary (not hiring fees) for 8 Soldiers. The salary (and hiring fees) for 10 Scientists and 10 Engineers are ignored. The Base Maintenance costs, $224K for a standard starting base, are also ignored. This generosity saves you at least $774K. Could this be considered a bug? Possibly.
:::: The cash value of the XComUtil Improved Base is a whopping $4.5M. This is $1.6M of facilities (Alien Containment, Large Radar, 2nd Living Quarters) and $2.9M of personnel (+10 Engineers, +40 Scientists). $4.5M would wipe out all starting cash and players would begin the game with a negative balance - quite challenging! For XComUtil, it might be best to break improved Facilities and Extra Starting Personnel into 2 options, with each having a sub-option to pay for the improvements. ''"These extra facilities/staff would cost $1.6M/$2.9M, do you want to deduct that amount from your starting cash?"'' [[User:Spike|Spike]] 20:48, 12 March 2010 (EST)

=== Easier Inventory Management ===
Inventory management is one of the things I hate about the first two X-Coms. I was hired to be a commander, not a supply clerk! A mod which made general stores have 10000 space (like Apoc) would be nice.. [[User:Cesium|Cesium]] 21:39, 9 February 2010 (EST)
: The manager of any facility has to deal with generalities of space issues. The clerk tells you if that fancy new tank you just bought will fit. He has to put it in storage and keep track of what shelf the ammo is on. --[[User:BladeFireLight|BladeFireLight]] 22:27, 9 February 2010 (EST)
:: That's the clerk's problem and if he complains too much I'll have him peel potatoes until his hands drop. In any event, the limit doesn't make any sense:
::* General stores size is 8x8x2 (8x8x3 in TFTD) per base defence map, and should have no problem storing more than 50 items.
::: The items taking up 1 item unit are typically about the size of humanoid body. I think it's not unreasonable to have no more than 50 of those in the area that the General Stores takes up.
:::: I can't find a list on the wiki of storage space requirements for items, so I'm not sure which items take up 1 item unit. Typically the main space wasters are Heavy Plasma ammo/Blaster Bombs/Stun Bombs (late game) and/or HWPs and avalanches (early game). These either are definitely not the size of a human body (ammo/Bombs), or shouldn't be stored in stores at all (HWPs gain nothing, and might as well lay around somewhere else in base).
::* The size of a fully built X-Com base is about the size of a city block (judging by comparison of base defence to terror missions), and should easily be able to hold hundreds of items even in the starting base if it's willing to put some stuff not in the general stores.
::* The space limit makes no sense. Why do Blaster Bombs and Heavy Plasma ammo take so much space whereas in the inventory view it doesn't take any more than normal ammo? Who stores <s>mini tanks</s> HWPs in the same compartment as light weapons? And the way X-Com (probably) stores ammo and explosives is scary...
::: As you suggest, extremely powerful ammunition probably requires a lot more space for safe and secure storage in-base, versus on a tactical mission. Imagine what would happen if a Blaster Bomb exploded in a base? Or was stolen? They probably use nuclear warhead style storage facilities for those. And similarly for Avalanche warheads, alien artifacts, Elerium, etc. Segregating dangerous/explosive items from other items probably uses up a lot of overhead in the construction of the storage space - think armoured, bomb-proof lockers and bulkheads, advanced security systems, airlocks, scanners, etc. This is not just like piling stuff up in your shed! And the Commander who left Elerium or Avalanche warheads lying around in his hanger or corridors would justifiably be sacked on the spot by XCom High Command. [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Well, judging by all the explosives in the hangar during base defence and the X-COM 1.0 Elerium bug, Elerium and explosive warheads ''are'' lying around in the base... And all the equipment in the General Stores is stored in ordinary lockers according to the General Stores map ;-) More to the point, if X-COM wants to store explosives safely (judging by said warheads X-COM doesn't care too much) they need a special facility for this, not to store them in the room which also contains all the base's weapons and priceless alien artifacts.

:::: Furthermore, I expect X-COM to improvise on storage in the interest of actually winning the war. X-COM does do this and ignore the limit when manufacturing stuff in-base or getting loot from missions. All that's needed is that X-COM will improvise for transfers too. I can't imagine a quartermaster informing the commander there isn't any room for the new armour and that the troops should go without. Maybe the reason X-COM doesn't pay quartermasters each month is that they keep getting themselves lynched by enraged X-COM troops...
::* Gameplay wise, inventory micromanagement is just no fun, especially in the late game when you have all the cash you need but still has to sell stuff after each combat (which can be prolonged if you haven't sold for awhile), otherwise you can't transfer items to the base where your main team is at.
::* Maybe this entire "stores" thing is a plot by the CFN to force X-Com to share its technology with them by forcing X-Com to sell sell sell. It's not like they pay X-Com the real worth of the technology anyway. [[User:Cesium|Cesium]] 23:47, 9 February 2010 (EST)
::: I think a lot of people do find the inventory management tedious, or unrealistically low. Personally I think it's about right for large equipment (missiles, tanks, bodies), but too low for small arms and personal equipment. And yes, it only reflects using the General Stores modules, not storing stuff at random points in the base - maybe fair enough. If the right offset to patch can be found, the storage limits could easily be raised. The last few bytes of [[BASE.DAT]] could be a good place to look for this offset. BASE.DAT can store up to 9,999 units of each item per base. The total limit for items per base would need to be found by experiment, but 9,999 might work for those who want to ignore inventory. For those who feel inventory management is OK but the limits set too tight, the capacity of each General Stores could be increased from 50 to 100 - assuming we can find the offset for this to patch it. [[User:Spike|Spike]] 19:50, 10 February 2010 (EST)
::::Maybe you can try there:
.text:00439C85 66 81 C5 F4 01 add bp, 500
::::[[User:Seb76|Seb76]] 13:03, 11 February 2010 (EST)
::::: Yes that works nicely. E.g. patch '''66 81 C5 E8 03''' at that location and you get 100 space per General Stores. Thanks Seb! [[User:Spike|Spike]] 18:21, 13 February 2010 (EST)
:::::: Now if only I had the offsets or search signature so we can add that as an options --[[User:BladeFireLight|BladeFireLight]] 18:24, 13 February 2010 (EST)
::::::: UFO 1.4 dos: offset 143748. TFTD 2.1 dos: offset 178462. TFTD v1 dos: offset 176861. TFTD CE: offset 252795. UFO CE: offset 236680. (all offsets are in decimal and point to the "F4 01" value to be patched).
::::::: Patching to "E8 03" has been tested on dos versions (not on CE) and it works. The "base information" screen will display the correct value, though the values to line length scale is such that the line will max at 250. [[User:Cesium|Cesium]] 05:57, 14 February 2010 (EST)
::::::::Are the preceding bytes the same from TFTD 1 and 2x? --[[User:BladeFireLight|BladeFireLight]] 17:26, 15 February 2010 (EST)
::::::::: Yes they are. '''81 C3 F4 01''' is the add instruction. [[User:Cesium|Cesium]] 17:48, 15 February 2010 (EST)
::::::::: Sig for UFO Dos is '''81 C6 F4 01''' --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
:::::::::: Do you also have the preceding bytes for UFO? with the signatures I can create a patch file for all versions --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
::::::::::: I am not sure I understand your question.. Judging the the two UFO versions I have available (1.3 per xcusetup and 1.4) the common preceding bytes are ''80 78 16 07 75 0C 80 78 3A 00 75 06'' (followed by the sig). You could try to use the sig alone - it exists only once in the file. [[User:Cesium|Cesium]] 19:35, 15 February 2010 (EST)
:::::::::::: Offset Locations are something I'm collecting but also the unique series of bytes to find them for the two geoscape/tactical that I dont have. (UFO Spanish, TFTD Italian) I hope to add a lot more options in the in the future. I do feel this one nerfs the storage system anything to get the game up and going faster is always a plus. --[[User:BladeFireLight|BladeFireLight]] 22:01, 15 February 2010 (EST)
::::::::::::: Well, you may want to add another General Stores to the improved starting base if you want to achieve the faster startup effect without "nerfing" storage system for rest of game (I prefer a "nerf" due to late-game reasons). Also, I suggest you add an message in Xcusetup to ask people to get in contact with you if they use an unknown/unrecognized version. [[User:Cesium|Cesium]] 14:27, 16 February 2010 (EST)
::: Inventory management is just as much a pain in the early game, where you almost always are out of space until your 2nd general stores is built. I like realistic constraints, but not tedium. Maybe upping the space per Stores from 50 units to 100 units would be a generally acceptable approach (now that Seb76 has kindly found the offset)? [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Yeah, that would be a great improvement. [[User:Cesium|Cesium]] 15:45, 13 February 2010 (EST)

:I can confirm Seb76 is correct, as ever. The 2 bytes at offsets '''0x39c88''' and '''0x39c89''' in geoscape.exe code for the capacity of each General Stores. Default value is 500 ('''F4 01''') which equates to 50 in-game internal capacity units. (Smallest item uses 0.1 in game capacity so I guess that is 1 unit in internal units). I am not sure about a signature. From what I can tell, the preceding bytes '''66 81 C5''' are unique in geoscape.exe, which seems pretty odd, so someone else should verify that. [[User:Spike|Spike]] 19:48, 13 February 2010 (EST)
:: Yes it is unique to CE. it does not exist in any DOS EXE, but "F4 01" can be found in 79 places. Trial and error could locate it. --[[User:BladeFireLight|BladeFireLight]] 20:50, 13 February 2010 (EST)

=== AutoCombat ===

==== Firepower Factors ====
You might want to consider replacing the weapon offensive weighting factors for Autocombat with some factors that are (inversely) related to the [[Weapon_Analysis#Quantitative_Analysis|% TUs Per Kill]]. I've tabulated these for each weapon (including tanks) vs each alien race. You would still need to account for Psi, light/darkness, and XCom armour. Plus you would need a similar offensive factor for the aliens' attacks. But I could probably help with that, I have the data that's directly comparable to the % TUs per Kill for XCom weapons. [[User:Spike|Spike]] 22:06, 12 February 2010 (EST)

==== AutoWithdrawal ====

One of the most tedious things you can try to do in XCom is to scavenge the battlefield and retreat to landing craft for an Abort. A great option would be an AutoWithdrawal, similar to an AutoCombat, but with an easier threshold of XCom vs Alien combat power.

Basically it would scavenge all loose equipment off the Battlescape - dropped friendly and alien items, friendly and alien corpses and wounded, all go back into the landing craft. Elerium, Alloys, and UFO Components would not be recovered, as this is (normally) impossible apart from full tactical victory. All friendly troops return to the landing craft. Friendly losses, and equipment recovered, would be proportional to the offensive factor ratios but much more favourable than for AutoCombat. E.g. as long as XCom factors were at least equal to Alien factors, they would be able to scavenge everything and recover without casualties. If the aliens were stronger than XCom, they would only recover part of the scavenged equipment, and risk partial casualties, at say one third the rate of AutoCombat. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

: It's too easy compared to actual game IMHO. Every time a battle went FUBAR for me, it got FUBAR all the way and I was lucky if I could salvage my own team/equipment and maybe a single alien weapon/body. An AutoWithdrawal without salvage might be useful, but perhaps instead we should change AutoCombat failure mode to work better (e.g. Make some X-COM people survive a failed AutoCombat, depending on strength vs aliens). [[User:Cesium|Cesium]] 15:00, 7 March 2010 (EST)

:: Yes fair point. I was not thinking of the FUBAR situations, and you are right about how hairy those are. I was thinking of the situation where you control a certain part of the battlefield, but you either don't want to go on an endless hunt for the last few aliens, or you pretty much know you can't take on the aliens that are left (e.g. in the UFO or some other stronghold) without getting creamed. You can exercise a safe withdrawal, it's just tedious to carry out all the bodies and equipment. But it's pretty hard for an AutoCombat algorithm to detect which of those situations it is - FUBAR, boredom, or tactical withdrawal. I'll have to think about that, there may be no realistic solution at all. And there is the existing "teleport loose items back to base" command line option to XComUtil, maybe that's enough. [[User:Spike|Spike]] 16:08, 7 March 2010 (EST)

=== Tougher UFOs ===

[[Wish_List_(EU)#Tougher_UFOs|Tougher UFOs]]
As this is entirely implemented by patching data and data files it is a good candidate for XComUtil rather than [[UFO Extender]].
: That would definitely make the game harder. 9.7 is about the installer and the bug fixes. This would be a good candidate for 9.8. --[[User:BladeFireLight|BladeFireLight]] 01:38, 19 February 2010 (EST)
:: Cool! [[User:Spike|Spike]] 02:25, 19 February 2010 (EST)

=== Rebalanced Craft Weapons ===

This fits under the "making useless things usefull" category. It would be a 9.8 or later option. The idea is to make the Cannon, Stingray, Laser Cannon and Fusion Ball Launcher useful. Hopefully it breaks up the monotony of Dual Avalanches followed by Dual Plasma Beams, every game.

There is one common element in the approach, and two options. The common element is to fix the stats on the Fusion Ball Launcher. The two options are to use a stat-based approach, or a cost-based approach, to fix the other weapons.

NB This proposal is still a draft and will need tweaking, but I've got it to the point where it is worth discussing. Feedback is welcome!

''(Ultimately, the Plasma Beam still ends up being pretty much the optimum weapon in the end game. To mitigate this, it is a good idea to select the existing Alternate Energy Weapons Manufacturing option in XComUtil.)''

==== Fusion Ball Launcher ====

Increase the ammo capacity from 2 to 3. Don't mess with the damage. Job done.

See [[User:Spike#Fusion_Ball_Launcher]] and discussions linked from there.

==== Cost Based Approach ====

This uses historically realistic costs to restore game balance between different craft weapons. The stand off advantage of Avalanche missiles is now purchased at a price which is significant in terms of XCom budgets and mission yields. Stingrays and Cannons become significantly cheaper alternatives. The Laser Cannon, with similar capabilities to Stingrays but free to operate, also becomes very attractive. Mounting dual launched weapons becomes a very expensive luxury.

*Increase Avalanche missile Purchase cost to $386,000
*Increase Stingray missile Purchase cost to $125,000
*Leave Sell prices unmodified (to avoid creating a cash reservoir at the start of the game)
*Leave Launcher buy/sell prices unmodified

See [[User:Spike#Cost_Based_Rebalancing]]

==== Stat Based Approach ====

This provides a benefit trade-off to shorter range weapons, by increasing their firepower or effectiveness relative to longer range weapons.

*Increase Cannon stats to 15 Damage, 50% hit. Firepower is tripled, slightly ahead of (unmodified) Avalanches launching in Aggressive mode. Increase rearming rate to 200.
*Increase Stingray accuracy to 80%. Decrease Avalanche accuracy to 60%. Stingray now has 50% more firepower relative to Avalanche. Increase Stingray rearming rate to 2, so a full craft can be re-armed in the same time period with either weapon (instead of twice as long for Stingray).
*Increase Laser Cannon stats to 100 Damage, 50% hit. Firepower is doubled, 20% more than (unmodified) Avalanches launching in Aggressive mode, 2/3rds of Plasma Beam firepower.

To avoid advanced XCom aircraft exploiting the extra firepower of the Cannon weapons and disregarding the return fire from UFOs, this is best used alongside the Tougher UFOs option.

See [[User:Spike#Stat_Based_Rebalancing]]

=== Rebalanced Infantry Weapons ===

See [[User:Spike#Balancing_Infantry_Weapons]]

Primarily this means making the Rifle a bit stronger, and probably making the Pistol a bit weaker.

==See Also==

[[Wish List]]

= Completed Wish List Items =

=== BFG Default To Unchanged ===

Is it possible when using the BattleFieldGenerator, for it to detect the actual conditions for the mission (terrain, enemy craft, and light level) and offer these as defaults? [[User:Spike|Spike]] 08:22, 13 February 2010 (EST)
:Press The esc key at the prompt. (Line 719 in Xcomutil.txt, not that I expect anyone to read the manual :) ) Enter should also work. --[[User:BladeFireLight|BladeFireLight]] 12:34, 13 February 2010 (EST)
:: RTFM eh? My biggest failing. Maybe you could add an explicit prompt "Esc or Enter = [whatever the unmodified value would be]". [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)
::: From what I can see, hitting Escape during BFG makes it continue with ''all'' values reverting to the original conditions. It would be nice to be able to select some but not all original conditions. My main use of this is to turn a night mission into a day mission without the hassle of keeping the landing craft hovering around until the terminator crosses the landing site. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
:::: You could just use the force all daylight option.
:::: After reviewing Scott's code. Esc leaves all setting as-is. Pressing enter or any other key not listed will randomly choose for you. I will see if I can change enter to leave as is. --[[User:BladeFireLight|BladeFireLight]] 11:00, 7 March 2010 (EST)
::::: This has been added --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)

= MISC =

* It's actually quite hard to downgrade to DOSBox 0.72 in Ubuntu. Only 0.73 is offered, there is no ability to Force back to a lower package level with Synaptic Package Manager. Unix guru skilz are required to rollback to 0.72, and I guess 0.74 is not around yet, or not packaged for Ubunut APT? Is there any way to fudge around this, e.g. by providing the command line arguments in an optional text file for xcusetup.bat to parse? Having said that, even with no command line arguments, xcusetup hangs on my 0.73 DOSBox while executing SDUMP. I had to reboot in Windows to run xcusetup.bat - something that is only possible on a dual boot machine / Wubi machine. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
** Try using a different batch interpreter like 4DOS [http://www.4dos.info] to execute xcusetup inside DosBox. I tested this throughly before under DosBox/Linux and it works well with recent 9.7 builds. I suggest running "config -set cpu core=dynamic" and "config -set cpu cycles=max" before xcusetup to speed it up (xcusetup doesn't detect DosBox when 4Dos is run, so it doesn't run these automatically unlike normal DosBox case). [[User:Cesium|Cesium]] 09:48, 7 March 2010 (EST)
** Oh, and downgrading isn't that difficult: Get a dosbox 0.72 deb, and run "dpkg -i" on it, and then do "echo dosbox hold | dpkg --set-selections" to prevent future upgrades. [[User:Cesium|Cesium]] 09:50, 7 March 2010 (EST)
** Another option is to install the dosemu package, and run xcusetup under that. EU/TFTD can be run under that, but it doesn't work as well there. (Oh, and there's no mount command there. UFO/TFTD needs to exist under ~/.dosemu/drive_c which is C:) [[User:Cesium|Cesium]] 11:42, 7 March 2010 (EST)

:Thanks Cesium I will check this out. I still think it would be good to have a solution that works for people who are not knowledgeable with the unix command line though. [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)

:: Why use Linux if you dont know how to use the console? It is a text mode OS with a separate GUI. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)

::: Well Ubuntu is a bit different, as it's supposed to be an OS for the general public, where you never need to touch text mode! Incidentally I can't find any DEB or other packages for 0.72, all that is available on the DOSBox website is the source code. They really don't seem to realise that 0.73 is buggy! So I guess I will need to '''make''' it. Or just wait for 0.74 as I think it's out soon. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)

:::: See [http://archive.ubuntu.com/ubuntu/pool/universe/d/dosbox/] for 0.72 debs. Unlike Windows, package systems in Unix land are centralized, so best location to search is typically a package server mirror or a distro mirror, not a vendor's website. [[User:Cesium|Cesium]] 17:36, 9 March 2010 (EST)

Talk:XcomUtil

2010-03-16T19:35:05Z

BladeFireLight: /* Open Bugs */

=XcomUtil 9.7 Beta=

9.7 Beta is available on www.bladefirelight.com

==Release Notes==

This is a Beta, so backup your files before using. And check back often for newer builds.

New in this version.

*Major overhall of the installer (XcuSetup) and the inclusion of 16/32bit exe's to support both DOSBox and Windows Vista/7 x64.
*New subfolders added to hold supporting files making the install cleaner
*New XcuSetup command line arguments were added to XcuSetup allowing for silent install and uninstallation.
*New XcuSetup option for debugging the install (XcuSetup debug) creating XcomUtil\debug.txt.
*New command line argument "nobackup" skips backup only if it has been ran atleast once.
*XcuSetup can now have minimal impact on the game.
**Almost all options default to NO (Only Split Windows EXE set to Yes).
**Almost all changes are now prompted for (skyranger guns, interceptor as transport, Disjointed Base Bug, etc...).
***Items still done by default:
***Copy protection questions set to 0000000 for UFO 1.0-1.3 and X-Com 1.0
***Difficulty bug fixed in UFO 1.0-1.4 and X-Com 1.0-1.4
***Unique names for all maps in TFTD, Used for Hybrid Games
***Placement of X-Com Units on the Battlefield based on XcomUtil.cfg
***MIA Recovery on Won Combat (Units under mind\MC control when last controling alien killed are returned to X-Com control)
*XcomUtil.cfg is now pieced together and overwritten by XcuSetup (see XcomUtil\XcomUtil.txt for how to make permanent changes).
*All game files are restored to the pre-XcomUtil state each time XcuSetup is ran. Any modifications by other utilities will have to be re-applied.
*Vista/Win7 patch now an option for XcuSetup.
**This will fix the blank screen issue.
**Updated to support the split EXE.
**Will set X-Com to use CPU 0.
*XcuSetup attempts to fix UAC issues by resetting folder permissions.
*A number of community made fixes are included and selectable with XcuSetup.
*Support for the DOS/Window STEAM Install.
**Installer will detect STEAM and change steam launcher to start the XcomUtil Steam Menu (can be re-installed with XcomUtil\SteamSetup.bat
*Out of the box support for UFO Extender. XcuSetup will detect it and ask if you want RunXcom to use it.
*XcuSetup can be run from windows and RunXcom run from DosBox
*Hybrid Colors updated based on BombBloke's pallets.
*EQL flag allowed any turn.
*Add Xcom UFO Italian Support.
*Auto Combat will not run on second half of two part using first parts saved data.
*Auto Combat will no longer run if combat was won.
*MIA Recovery on won combat only.
*MIA Recovery no longer recovering units that bleed to death.
*Auto equip no longer triggers on second part of 2 stage missions.
*Combine clips skiped if between stages of 2-3 part missions.
*Updated f0dders ReadMe per his request. (XcomUtil\bugfix-readme.txt)
*Add-on support added. see XcomUtil\XcomUtil.txt and XcomUtil\Addon\Example.txt
*Prompted Terrain in BattleField Generator allows to abort or use of current setting.
*Beta versions include
**XcomUtil\XcomUtil.log includes lots of debug info
**XcomUtil\Debug.txt created by default (Release will need "debug" command argument)

Removed from this versions

*New Desert and Urban terrain. (Will be added once I have a C++ version of the Java Terrain Edit.)
*Expanded capacity Laviathan, Hammerhead and Avenger (maps avalible in XcomUtil\Patches)

NOTE: If you use DosBox, this requires DosBox 0.72 (Does not work on 0.73 due to buffer overflow setting ERRORLVEL)

===Build 435===

Original Sound Effects from UFO were re-sampled to work with 1.4 and CE.

*Add Category to option headers.
*Improve randomness by using current time instead of game date/time in srand()
*Added Option to keep Current terrain/UFO to BFG.
*Original UFO 1.2 Sounds for Geoscape and Tactical added as an option for UFO 1.4 and CE.
*Force Split EXE on STEAM. Fixes issues with setup failing.
*Reset Laser/Gauss craft weapons stats to be default.
*Example addon now uses different flag extension to avoid deletion by XcuSetup
*fix issue with Lab Screen on DosBox always screening

==Beta Disscusion==

===Build 435===
: I hope the improved randomness doesn't apply to the Aliens' d100 during AutoCombat. Otherwise, one could load-scum for success. [[User:Cesium|Cesium]] 06:33, 11 March 2010 (EST)
:: Actually it does. I can see what your getting at, but why do it that way. if you want to win the "WIN" command line option is faster and you get better loot from the UFO. also using the combat date would also swing the other way with an unwindable autocombat with an fully loaded avenger vs a survey ship. --[[User:BladeFireLight|BladeFireLight]] 17:41, 11 March 2010 (EST)
: In the setup question for sound files: "were replace" should be "were replaced". [[User:Cesium|Cesium]] 06:53, 11 March 2010 (EST)

Excellent! For the first time xcusetup.bat completed for me in Dosbox in Ubuntu. Previously the SDUMP commands were hanging it.

For the first time ever, I ran the sound setup utility. It did not response to any cursor keys, enter, tab, etc. The only key that worked was Escape, and I'm not sure what this did.

One point on the xcusetup.bat script - Ctrl C does not seem to work. On all those "press a key to continue" prompts could we also have "or 'q' to quit"?

[[User:Spike|Spike]] 18:41, 13 March 2010 (EST)

: "press a key to continue" is the Pause command. Ctrl + C works fine in Windows. DOSBox does not. The reason for the use of Pause is because an number of new players kept exiting setup early when I gave the option. Aborting early makes a mess and I dont want to have to troubleshoot it for Joe user. --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
:: OK I see, that makes a lot of sense. [[User:Spike|Spike]] 06:52, 14 March 2010 (EDT)

I have a strange issue. I succeed in an AutoCombat terror mission (117%) but the mission is resolved partially as if I had actually aborted the mission - all Civilians die, even though I could see 3-4 alive, my 13 soldiers outside the Skyranger go MIA, even the one who was killed by AutoCombat, and only my sergeant standing in the Skyranger makes it back. The problem is repeatable. On one occasion the sergeant was killed randomly by AutoCombat, meaning that the Skyranger flew back by itself, empty. Obviously this should never happen.

I've uploaded the [[Media:MIAoverload.zip|AutoCombat game save file]]. Incidentally this shows how to 'game' the current AutoCombat rules: Take maximum soldiers, no tanks. You give everyone a Rocket Launcher, they only need 1 Lg Rocket in it. Until you get Heavy Lasers, then replace the Rocket Launchers with them. Next replace with Heavy Plasmas. This approach always gives you maximum damage per soldier, and thus maximum chance of getting the +15 bonus for the W:3- rule. [[User:Spike|Spike]] 19:02, 15 March 2010 (EDT)

==Open Bugs==
*There's no Italian text for the Alternate Laser Weapons option. Applying the patch seems to work, but it displays the text for the default laser weapons.
:*Anyone want to translate the text into Italian? --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
*The number of aliens in the mission report is inconsistent with the number of live aliens captured per research help. See [[Image:Alien_numbers_mismatch.zip]] and [[Image:Dead_alien_count.zip]].
* Morale is random at start of second stage after autocombat of first stage?
:* Actually Morale is used as the clip size and time units as the weapon damage. Don't ask me why. It would take a major re-write of auto combat to fix this. --[[User:BladeFireLight|BladeFireLight]] 19:34, 23 February 2010 (EST)
*RPL bug, when you turn creatures into Gill Men, they are reported as Snakemen
:* Reported how? Is this consistent? The name's used are from xcomutil.cfg. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
::*Sorry. It's reported in morale failure pop up messages. Though maybe this is an original TFTD bug rather than an XComUtil bug. [[User:Spike|Spike]] 19:21, 21 February 2010 (EST)
:::* See this: [http://www.youtube.com/watch?v=uGlSghf7aTU]. In that case, all Gill man (were lobster man before RPL) were reported as snakemen.. [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST)
*RPL bug, when you turn Lobstermen into other creatures (e.g. Gill Men), they are very hard to kill despite having the stats of the creature they turned in to. Possibly they are keeping their damage resistance? Maybe the race is stored in more than one place, for different purposes, and XComUtil misses one of these places?
:: I will look into this --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: The RPL only changes the basics; The race, rank, name, TimeUnits, Health, Energy, Reactions, Armor(front,back,left,right), Strenght and PSI Strenght. All other stats are left as-is. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
:::: I'm not so sure about this. See 05:00 mark at [http://www.youtube.com/watch?v=y-_zLdjhUHI]. The armour doesn't match the one Gill man should have (per UFOpaedia, at least). [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST). See also 04:17 mark at [http://www.youtube.com/watch?v=z5LfzFSkRnI] for reason to suspect resistances aren't always changed. It's possible he just was unlucky though... [[User:Cesium|Cesium]] 19:53, 21 February 2010 (EST)
::::: Actually the function is something like this
<pre>#define UpdateStat(x,y) pur->x = (unsigned char) \
( ( (unsigned int)pur->x \
* (unsigned int)pasTo->y \
) / (unsigned int)pasFrom->y )
UpdateStat( TimeUnits0, TimeUnits );
UpdateStat( Health0, Health );
UpdateStat( Energy0, Energy );
UpdateStat( Reactions0, Reactions );
UpdateStat( AFront0, AFront2 );
UpdateStat( ALeft0, ALeft2 );
UpdateStat( ARight0, ARight2 );
UpdateStat( ARear0, ARear2 );
UpdateStat( AUnder0, AUnder2 );
UpdateStat( Strength, Strength );
UpdateStat( PsiStrength, PsiStrength );
</pre>
::::: the 0's are values at start of tactical.
::::: I read that as Current(from game_x) * Target default(from xcomutil.cfg) / source default (from Xcomutil.cfg) so the stats will be different. --[[User:BladeFireLight|BladeFireLight]] 21:33, 21 February 2010 (EST)
:::::: I'd have expected Current(game_x) == Source default if applied on first turn? This would end up with result == Target default, no? Hmmm... We already saw some compiler multiplication wackiness with the research help bug. Possibly this affected these calculations too?
:::::: As for the code, you're not updating PsiSkill, so non Psi-users can't get Psi after RPL. [[User:Cesium|Cesium]] 22:03, 21 February 2010 (EST)
::::::: I didn't write this. I'm amusing Scott did it this way to adjust for difficulty because XcomUtil.cfg has the beginner level stats. It need's an overhaul to use the full stat entries including the unknowns adjusted correctly for the level. Something for latter. --[[User:BladeFireLight|BladeFireLight]] 22:09, 21 February 2010 (EST)
:::::::: For this specific issue I think you will need to update 0x37 of [[UNITREF.DAT]] which is the Damage Modifier. For the general problem you will need to update the Psi Strength and also Firing Accuracy, energy regen rate, movement class... loads of stuff. And of course LOFTEMPS. So with current RPL not changing LOFTEMPS, changed aliens are the wrong size and shape probably. This would be visible using the LOFTEMPS map viewer I suppose. [[User:Spike|Spike]] 18:39, 9 March 2010 (EST)
*[[Known Bugs#XComUtil Inventory Stacking Bug]]
:* I hope to overcome this but Scott's notes point to a technical limitation. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*Fusion Ball Launcher fixes - detailed discussion moved to [[Talk:Fusion_Ball_Launcher#XComUtil_FBL_Issues]]
** Profitability (inconsistency item) - becomes most profitable item when using Alternate Laser (and Plasma) Tech option. Recommendation - workshop space and Engineer hours x10, 4 Alloys, 20 Elerium. And make it more useful (see below).
** Usefulness ''(wish list item)'' - perceived as being not very useful with standard stats. Recommendation - increase ammo to 3. Leave damage as-is to allow for Tougher UFOs (see Wish List).
*Zrbite lying around in odd places. Objects lying around in odd places in general - these are map modifying errors, probably only occur when customising terrain etc.
:: Will be part of an overhaul of the BFG --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*There is a small problem in editing/customising craft using '''XComUtil.cfg'''. Certain X-Com craft weapon values - the rate of fire value - can't be set. Or more specifically, they can be set (patched) in the executable but it has no effect in the game. To avoid confusion they should perhaps be removed from the format of custom craft, or commented out. (This rate of fire patching ''might'' work on UFOs, haven't tested it).
:: Can you be more specific? --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: There is a section in '''xcomutil.cfg''' which is used for patching XCom craft weapon characteristics. This is where Scott changed values for the Laser Cannon, etc. Probably very few people use these fields. I only used them because I was doing research into the game mechanics. One of the values changed in this section is the reload time. These values are present in the executable, and can be patched, but patching them has no effect (other than to change the UFOPaedia entry). The reload time seems to be hard coded elsewhere in the executable, based (broadly) on the class of weapon. So you might want to comment this column with an a note saying "cannot be modified for combat". On the other hand I could be wrong, or someone still might want to modify these fields. Discussion is at [[Talk:UFO_Interception#Observed_Rates_of_Fire]]. Offsets are at [[Talk:GEOSCAPE.EXE#Craft_weapon_stats]]. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
:::: Or maybe change these display-only values so that they reflect the [[Talk:UFO_Interception#Observed_Rates_of_Fire|observed reload rates]]? I am not yet 100% sure I have got these right, might want to wait until I do some more confirmation tests. [[User:Spike|Spike]] 15:26, 22 February 2010 (EST)
*EQL only works on turn 1 (see discussion above)
::: Added to my to do list. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*Research Help from Captured Aliens awards research help without checking first if you have Alien Containment at the base of origin. Resulting in dead aliens helping you with your enquiries! Possibly only applies to AutoCombat? [[User:Spike|Spike]] 21:05, 14 March 2010 (EDT)
:: Ideally it would not only check for containment but also have a research item for it and check on how many scientist days had been reduced since the last combat and use that as a value for how much you get form the aliens still in containment. But that could just be a pipe dream. Checking for containment for now is a good idea. --[[User:BladeFireLight|BladeFireLight]] 15:35, 16 March 2010 (EDT)

==Fixed Bugs==
*don't prevent patching windows version while running in dosbox, or vice versa
:*Fixed: XcuSetup can be run independantly to the OS RunXcom is used in.
*4DOS and MS-DOS 5 dont like "-" in variable names.
:*Fixed
*Enviroment space reached quickly on most DOS envirments.
:*Partly Fixed: Requirement has been drasticly reduced to to ~1024 use of Command.com /e:xxxx still may be required
*EnvClean.bat has an error in line 172: ser -> set.
:* Fixed in build 204.
*ANSI escape sequences aren't necessarily supported on a real dos environment/emulation
:*Fixed: ANSI only used in DOSBox
*If all the aliens are down (some of them stunned), the last save is named "AutoCombat" and I end turn, XcomUtil may still run "AutoCombat" phase. This may have slightly different results than end of combat would have had
:*Fixed: Autocombat will not run if you have already won.
*A fully loaded Hammerhead's initial deployment has three aquanauts outside the craft.
:*Fixed: the unit placement for the default 12 unit craft has been added to XcomUtil.cfg
*Select terrain: dosent apear untill after I select a terrain in BFG prompting
:*Fixed
*geodata/obdata.dat get's trunkated with slecting any improved weapon.
:*Fixed: This happend because a full backup did not complete but XcuSetup does not detect it. Backup script's changed to avoid xcopy timeout on some versions of DOS. (Backups are required by SDUMP to apply patches)
*I get this error dureing backup "16-bit MS-DOS Subsystem NTVDM has encountered a System Error The handle is invalid."
:*Fixed: All NT based OS's now useing 32bit EXE's
* You can get X-COM MIA if you abort a mission, even if everyone is in the exit. Possibly a second stage bug only? See [[Image:X-COM_MIA.zip]]. Note that this only affects the report - after mission all the X-COM troops are still available.
:*NOT Fixed: This happens even on vanilla TFTD with that save. Given it's TFTD it could be an issue with the mapfiles. --[[User:BladeFireLight|BladeFireLight]] 00:23, 24 February 2010 (EST)
*Various second stage bugs - ammo clip recovery, crashes after autocombat of first stage, etc. Mainly for TFTD, but possibly Cydonia in UFO is also affected.
:*Fixed: Clip recoverty no longer ran between parts of 2-3 part missions. Autocombat only crashes on two part if you are aborting the second stage and the save in slot 10 is from the first stage. Stage comparisons are now done to abort autocmbat if you do this.
*Removal of Small Scout map / Survey Ship map, making it impossible to do these Battlescape missions.
:*Fixed: 9.7 only removes the maps if you use the BFG. I hope to have 9.8 not remove them at all. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*The XcuSetup prompt for the option of less-profitable weapons manufacturing is misleadingly called "new laser weapons".
:*Fixed: Renamed to Alternate Lasor weapons.
* SteamSetup.bat won't run from DOSBox. It says "This needs to be run from Windows". Though, does it make any sense to run SteamSetup.bat under DOSBox (eg for a linux system with no Steam)? [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
:*NOT Fixed: STEAM dosent give access by default to the command prompt. If you know how to add that then you should know enought of DOS not to need the STEAM menu. --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
* '''cfg/ShipDefU.txt''' has the XCU values for improved Laser Cannon (35/35/35), not the original values (21/35/70). Is this correct - is this file supposed to be the original defaults? [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)
:*Fixed: I was unawhare that this had been changed. The weapons are not prompted for any change so they should not be changed. I'm reseting them all to defaults and looking to see if Scott had anything about them in the notes. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
* standalone patches the fix the difficulty bug
:*Partialy Fixed: 9.7 min install is the dificulty patch and changeing Copy protection questions to all 0's.
*Version detection issues with obscure versions (Italian, 1.2a, etc.) causing corruption or lack of patching.
:*Fixed: Added support and patching offsets.
*Various default options make the game easier, not harder (''harder'' being the intent of XComUtil, right?). These should not be defaults. (More discussion at [[Talk:Enemy_Unknown_Extended#Standard_Config_Discussions]]) E.g.
::: 9.7 only has 3 items on by default. Remove copy protection. Fix Difficulty bug and Split EXE (split EXE can be skiped but not the others). All other options are default to NO.
::: As for the intent of XcomUtil. Scott added features to
:::# Increase difficulty.
:::# Make useless items useful.
:::# Get the game Started faster.
::: I have added:
:::# Don't make unwanted changes.
:::# Fix game bugs
:::::Yes all of those are very sensible. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
::::Latter versions of XcomUtil will turn the last two forced items to prompted. with only the Difficulty bug and the split EXE as Default=Yes. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Basic tanks using advanced tank stats
**Improved High Explosive - very powerful in favour of X-Com, especially as alien spawn points and routes aren't set up to cover holes in UFO hulls.
:*Gauss weapons have infinite ammo
::: 9.7 has a second option to just the increase power to closer match UFO.
:*Using fighters as transports (carrying soldiers)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Using transports as fighters (weapon hardpoints)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Improved Heavy Laser / Heavy Gauss. OK, this should maybe be a ''recommended'' option since the unpatched weapons are nearly pointless. But, it does make the game easier. [[User:Spike|Spike]] 20:12, 7 February 2010 (EST)
*FreeDOS breaks horribly dering Setup
:*This is most likely an issue with the limits of FreeDOS.
:** Actually, this seems to work well for the latest builds (tested with FreeCOM 0.84 under dosemu). [[User:Cesium|Cesium]] 18:07, 14 March 2010 (EDT)

=XComUtil Wish List=
Things that are not bugs or inconsistencies in XComUtil but would be Nice To Have

== Features for 9.7 - Interface, consistency and bug fixes ==

=== Categorise Config Options ===

For each option, in the prompt, note which category of option this is, according your list above. E.g. faster start, making the game harder, making useless items useful, bug fix, variant game, etc. [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)

:Actually it might be even better to organise the options questions into sections, thematically grouped by these categories. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

:: Items are currently sorted like this.
* Windows EXE
* Game Fixes
* Game Mods
** Sound
** Craft
** Base
** Equipment
** Research
** Units
** Battlefield
** Alien Craft
** Misc
--[[User:BladeFireLight|BladeFireLight]] 19:25, 10 March 2010 (EST)

=== Improved Pistol Modification ===
*Remove 3rd burst for Pistol
Detailed discussion moved to [[Talk:Pistol#XComUtil_Burst_Mode_Pistol]] to de-clutter this page. Summarised recommendations will be posted back here based on whatever consensus emerges.

Current recommendation: Reduce auto accuracy from 60% to 20%, with the same TUs (54%).When prompting, point out that no improvements are required to the Pistol to make it useful. [[User:Spike|Spike]] 08:12, 14 March 2010 (EDT)

* Dart Gun

On the other hand, the Dart Gun really is useless, even as a last ditch personal defence weapon. Auto mode, with very low accuracy (10%?), would at least give it some value as a defensive sidearm for medics, heavy weapons troops, etc. Scouts and others carrying a scanner or grenade in the other hand would still be better off using a Jet Harpoon, or even an AP HydroJet Cannon, one-handed. [[User:Spike|Spike]] 03:47, 16 March 2010 (EDT)

=== Fusion weapons inconsistently exempted from Alternate Laser Tech ===
* Fusion weapons inconsistently exempted from the "more difficult" energy weapons manufacturing option ("alternate laser Tech"). Blaster Bombs and Blaster Launchers, Fusion hovertanks and ammo, and Fusion Balls and Fusion Ball Launchers - none of these are harder to build or use with the "alternate Tech" option. Why make laser weapons/tanks and plasma weapons/tanks harder but not Fusion weapons? It's not consistent. I wonder if Scott didn't look at these because he never used Blaster Launchers or Fusion Hovertanks, as he considered them to unbalancing already? And ignored FBLs because, well, most people ignore them? But this should be consistent. Or, the "harder weapons" option could be broken down into sub options, e.g. for each weapon technology:
** Much more expensive (typically: add some exotic materials, 10x workshop space and 10x Engineer hours)
** Can/can't manufacture the battlescape weapons/tanks (pure alien weapons only)
** Can/can't manufacture the ammo (pure alien weapons only)
:Personally I would prefer it to be all-or-nothing but include the Fusion weapons as being more difficult to make and use. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
* In the meantime (ahead of introducing any changes), maybe change the prompt to "Alternate Laser and Plasma Tech"/"Alternate Gauss and Sonic Tech", and/or point out explicitly that the changes don't affect any Fusion/Blaster/Pulse Wave weapons. [[User:Spike|Spike]] 08:15, 14 March 2010 (EDT)

=== AutoCombat issues ===
* All Civilians are dead if AutoCombat is used to end a Terror mission. It's too not much of a problem, since score is likely to be positive anyway. It would possibly be an improvement to assume all civs from first stage are dead (if ran at second stage) and get a random number (using mission seed) for dead civs at current stage? [[User:Cesium|Cesium]] 07:00, 22 February 2010 (EST)
:* This is odd. Autocombat is supposed to skip over civilians when using the kill function. --[[User:BladeFireLight|BladeFireLight]] 00:18, 24 February 2010 (EST)
::*Maybe kill civilians (or not) according to the force ratios. If XCom has only enough force to win the mission, all Civilians are dead. If XCom bring a certain amount of "excessive force", all or nearly all Civilians are saved. By the way I love AutoCombat, it is great for avoiding repetitive combat and only playing the new, interesting bits. [[User:Spike|Spike]] 15:53, 22 February 2010 (EST)
:::* Thinking about this, I recalled the scenario where someone fights the mission and uses AutoCombat to hunt the last aliens (another reason AutoCombat is great). Spike's suggestion is better from pure RNG, since in this case probably all civs that were at risk already died. So lets see what we suggest XcomUtil do:
:::# Count civs from first stage if there was one as dead (since IIRC XcomUtil has no memory of first stage when exiting second stage, so we can't take them into account?).
:::# Deduct dead civs from current stage.
:::# Calculate extra dead civs using force ratio to bias the RNG (I prefer merely biasing the RNG rather than precluding results, since Xcom in general has a large variance in almost every gameplay mechanic). [[User:Cesium|Cesium]] 18:27, 22 February 2010 (EST)
* Day vs Night
** The Day/night algorithm breaks. For example, at any point when XCom has more than twice as many flare-carrying soldiers than there are remaining aliens, XCom is actually ''stronger'' in darkness than it would be in full daylight. Toward the end of a battle this is a very common situation. But fixing the algorithm is tricky. What might work is to give -10 for each Soldier in darkness, reduce from -20 to -10 for each Alien in darkness, then add back +10 for every soldier with a light source. Thus there is no way XCom can go 'net positive' from light sources.
:: If you have more units then they do you can see more of the battle field. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:::It never makes sense for XCom to be stronger at night, than during the day, for the same force ratio. But that is what happens. An example. 10 XCom soldiers with flares and 3 aliens. At night there is an extra -30 modifier for the aliens, but a +100 modifier for XCom, net +70. The same 10 soldiers against the same 3 aliens are +70 ''more'' effective in darkness than they would be in daylight. It does not make any sense. [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
** The definition of a light source should be expanded to include a Flare ''or'' an Incendiary weapon. In fact, one Incendiary-capable weapon of any type (AC/HC/HjC/GC), with appropriate Incendiary rounds carried, should be enough for the entire squad to be considered as having a light source. But this may be hard to implement without a special flag and a special pre-search for a valid Incendiary weapon, since AutoCombat normally scores by individual soldiers, not by whole squads.
:: This would take a rewrite. currently the ammo is not used by W: --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
** To be honest I would prefer that each soldier without a light source in darkness is 50% effective, each soldier with a light source (personal or squad), is 75% effective. Meanwhile how about this:

//Darkness
-10 L:-9 u:-2 // Human in Darkness

+10 L:-9 u:-2 W:-27 U:- // Human in Darkness w/Flare -OR-
+10 L:-9 u:-2 W:-4 W:-7 U:- // Human in Darkness w/In ammo and launcher HC/GC-IN -OR-
+10 L:-9 u:-2 W:-8 W:-11 U:- // Human in Darkness w/In ammo and launcher AC/HjC-IN -OR-
+10 L:-9 u:-2 W:-12 W:-15 U:- // Human in Darkness w/In ammo and launcher IN Rkt/Torp

-10 L:-9 u:4-14 // Alien in Darkness
:: Only thing I see is that this ''must'' come at the end. The U:- removes the unit from further consideration. --[[User:BladeFireLight|BladeFireLight]] 19:58, 9 March 2010 (EST)
::: Yes, to use the U: flag for this "OR" function, it must come at the end of the section for humans. That's how I have it my updated AutCombt.txt, these fragments are a bit out of context. It's not critical to have the "OR", it's just nice-to-have as it stops someone cheating by having a flare and one of each loaded incendiary launcher weapon in each hand and in their backpack, to get quadruple score. But hopefully people are unlikely to cheat at AutoCombat, there are easier ways such as the WIN flag. [[User:Spike|Spike]] 20:39, 9 March 2010 (EST)
* The Zombie is rated the same as a tank, a Chrysallid/Tentaculat or an effective Psi alien (-50). I think this is too high, as Zombies are much weaker than those units. A Zombie should be maybe -25.
: Disagree. the zombie should be slightly higher then a Chrysallid/Tentaculat as it will become one and you have to kill it twice. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:: OK good point! [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
* Area effect weapons (HE, IN, Small Launcher) should have at least the same bonus as effective-on-Auto weapons (+5). This is because they can damage/kill multiple targets. (The AC/HjC should not get both bonuses however.)

//Area Weapons. ToDo: compensating bonus for aliens. should not be cumulative. check if "effective?"
+5 u:-2 W:-4 W:-6 // Human w/HE ammo and launcher HC/GC-HE
+5 u:-2 W:-8 W:-10 // Human w/HE ammo and launcher AC/HjC-HE
+10 u:-2 W:-12 W:-13 // Human w/HE ammo and launcher Sm HE Rkt/Torp
+10 u:-2 W:-12 W:-13 // Human w/HE ammo and launcher Lg HE Rkt/Torp
+10 u:-2 W:-42 W:-43 // Human w/ Stun/Shok Launcher and ammo
+25 u:-2 W:-40 W:-41 // Human w/ Blaster/DP Launcher and ammo

-10 u:4-14 W:-42 W:-43 // Alien w/ Stun/Shok Launcher and ammo
-25 u:4-14 W:-40 W:-41 // Alien w/ Blaster/DP Launcher and ammo

::Having tested the first 2 rules, the first rule (HC-HE) does not work unless you remove the ammo specifier W:-6, making it just a test for an HC. But weirdly the second rule (AC-HE) works fine with its ammo specifier in place. Odd. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
::: The problem was due to [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Ammo loaded into a weapon by the game automatically prior to the equip phase is not caught by the W: function. When the ammo is loaded manually, both rules works fine. [[User:Spike|Spike]] 18:16, 13 March 2010 (EST)

* Pistols with the burst mode option should not count as Auto weapons (maybe they don't).
: Burst and snap are based on default stats --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
* Blaster Launchers / DPLs (with ammo) should be worth as much as a tank, e.g. +/- 50 (including the single shot effective bonus it should already get - see suggested rule above under area weapons)
* Should distinguish between tanks. Even with improved armour, a Tank/Cannon is not the same as a Fusion Hovertank. I would suggest a range of 25 for a Tank/Cannon to 75 for a Hovertank/Fusion. Maybe 40 for a Tank/Rocket, 50 for Tank/Laser, 60 for a Hovertank/Plasma?
:This does not seem to be possible with the existing ruleset as all Tanks are unit type 3
::Hmm, byte 42 of [[UNITREF.DAT]] is Rank but also Tank chassis. So this ''might'' allow distinguishing tracked tanks from hover tanks, at least. An alternative approach would be to pick some stat (that has a StatStrings statid) and set it to a different unique value for each tank type. [[User:Spike|Spike]] 18:32, 9 March 2010 (EST)
::This rule set might work:

// Tanks - distinguish chassis types.
+40 u:3-3 R:0-0 // Tank, Tracked (Cannon, Rocket, Laser)//To Test
+60 u:3-3 R:1-1 // Tank, Hover (Plasma, Fusion) //To Test

* Flying units (either side) should be worth say +/- 5
:Not possible for XCom as no statid makes a distinction between Power Suit and Flying Suit. Would be possible for aliens eg:

-5 T:0- u:6-6 // Flying Alien - Ethereal
-5 T:0- u:8-8 // Flying Alien - Floater
-5 T:1- u:13-13 // "Flying" Alien - Hallucinoid
-5 T:1- u:11-11 // "Flying" Alien - Tentaculat

* If the squad is carrying some Smoke or Dye that should be worth maybe +5 - +10. But since the aliens don't ever carry that, you need some balancing factor for them.

+1 u:-2 W:-20 // +1 per human with smoke grenade(s) (hopefully not +1 per grenade!)

* Effective melee weapons should be counted. This is particularly important in TFTD when ranged weapons may be ineffective, e.g. vs Lobstermen.
* Similarly if the enemy are in heavy armour and therefore a soldier/alien does not have an effective weapon, any HE Pack / Alien Grenade / Sonic Pulser should be counted for something (if it is "effective").

//Melee weapons
+5 u:-2 W:1- W:-26 // Human w/o effective ranged weapon but w/ Stun Rod
<s>+5 u:-2 W:3-26 // Human w/ effective Stun Rod (cumulative to above)</s>

::The second rule doesn't work at all, it looks like it counts all items of types 3-6. The "superiority" function (first value before the hyphen) does not seem to operate, probably because it is a melee weapon. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
::: did you try W:255-26 ? not that I know if it would work. AutoCombat doesn't recognize stun rods as weapons when applying damage.--[[User:BladeFireLight|BladeFireLight]] 21:01, 9 March 2010 (EST)
:::: OK, if AutoCombat rates stun rods as doing no damage, the lower range of the W: function ("superiority") will likely never work. So we can't tell whether or not a Stun Rod is "effective" vs the current enemy. In general, the Stun Rod is a pretty effective weapon. So instead we generalise and just use something like this rule set:

//Melee weapons
+5 u:-2 W:1- W:-26 // Human w/o effective ranged weapon but w/ Stun Rod
+5 u:-2 W:-26 // Human w/ effective Stun Rod (cumulative to above)

//It would be nice if AutoCombat checked for the presence of Stun Rods and used them to increase the chance of an alien casualty being stunned rather than killed.

//To Do: check if TFTD melee weapons are included in "effective" weapons by the W: statid.

//Grenades
+5 u:-2 W:1- W:-19 // Human w/o effective ranged weapon but w/ effective grenade(s)
+5 u:-2 W:1- W:-21 // Human w/o effective ranged weapon but w/ effective prox grenade(s)
+5 u:-2 W:1- W:-22 // Human w/o effective ranged weapon but w/ effective HE pack(s)
+5 u:-2 W:1- W:-44 // Human w/o effective ranged weapon but w/ effective Alien grenade(s)

-5 u:4-14 W:3-44 // -5 per Alien with effective Alien Grenade(s) (hope not -5 per grenade!)
:: Only one per unit. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)
::: Tested ok too! [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
* AutoCombat victories should award all UFO Components, not just some Navigation, Elerium and Alloys.
* Every Civilian on the map should be a penalty to XCom of maybe -5, due to the distraction effects of trying to save them / avoid killing them.

-5 u:15-16 U:- // Civilian distraction effect, no further effect

Let me know if I should try to work some of this up as AutoCombat rules. Some of it requires new coding of course, but a lot of it could probably be done with existing rules. [[User:Spike|Spike]] 13:15, 7 March 2010 (EST)
: I dont plan on any changing to the underlying code yet. Your welcome to make up a new set of rules and testing them out. --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
:: OK added some rules above. I have not tested them yet, some of the syntax might not work. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)
::: Syntax looks good to me. Give them a test and let me know how they go.
::: Just a quick note on how AutoCombat works. First the success percent chance is calculated using the AutoCombat StatStrings, dead and unconscious units dont count. (those that bleed to death are considers alive, need to fix this). If it's below AbortThreshold it aborts. If it's 100-199 then change to 90. 200+ change to 95 (success is never a guarantee.) Aliens roll d100, if over your success chance you lose. If You win. Then average damage by each side is calculated based on Loaded weapon being carried and time units. All aliens are killed or stunned by X-Com unit chosen at random. Each Alien gets a chance to wound an X-Com unit based on Success Percentage. Randomly choose unit using random damage (max is average alien damage) Leave at least one X-Com Unit alive. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)

== Features for 9.8+ - New features ==

=== TFTD Gause Tank Research Fix ===
*Have the option to make the Gauss Tank require only Gauss Cannon research - this can make it more distinct than the Sonic Displacer and maybe slightly useful for a while
:*I plan on it. just not this version. --[[User:BladeFireLight|BladeFireLight]] 20:53, 18 January 2010 (EST)

=== Improved Base Comes At Cost ===

The Improved Base is supposed to be a "faster start" option rather than a "make the game easier" option. But it does make the game easier, not least because it gives you a load of free base facility improvements. (Not to mention not having to struggle along the first month with only Small Radar and no Alien Containment) To partly avoid making the game easier, please add a sub-option that subtracts the cost of the extra facilities from your starting cash. This should be the ''full'' cost of the extra facilities, not just the difference between e.g. a Small Radar and a Large Radar.
[[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
: I dont have the offsets to the starting money ranges. so I cant do this. --[[User:BladeFireLight|BladeFireLight]] 19:13, 10 March 2010 (EST)
:: I never realised that the starting money is slightly random, I see ranges from $4,125,000 to $4,153,000, in ten samples. Does not seem to depend on Difficulty or starting base location. That is going to be a hard offset to find. [[User:Spike|Spike]] 20:36, 11 March 2010 (EST)
::: I believe there is no "starting money" anywhere to be found, or rather the starting money is effectively zero but it soon changes: the first thing the game does when you begin a new game is perform a hidden monthly report which grants you money from the funding nations. Only way to decrease it is to lower your rating toward countries (you should be able to hack the starting diplomacy data located at 0x4728F8). Or I could just patch the initial money to be negative instead of zero thus providing lower overall starting money. [[User:Seb76|Seb76]] 15:52, 12 March 2010 (EST)
:::: That makes a lot of sense. The initial money is the same as the initial funding. Doh! I should've realised that. The solution to poke a negative number into the money field, prior to the "hidden funding round", sounds a great idea.
:::: Looking at initial money vs funding, your initial cash is always $1,860,000 less than your initial funding. This $1.86M is probably made up of the first 3 rows (only) of your initial Monthly Costs: $500K transport rental, $1200K Interceptor rental, and $160K salary (not hiring fees) for 8 Soldiers. The salary (and hiring fees) for 10 Scientists and 10 Engineers are ignored. The Base Maintenance costs, $224K for a standard starting base, are also ignored. This generosity saves you at least $774K. Could this be considered a bug? Possibly.
:::: The cash value of the XComUtil Improved Base is a whopping $4.5M. This is $1.6M of facilities (Alien Containment, Large Radar, 2nd Living Quarters) and $2.9M of personnel (+10 Engineers, +40 Scientists). $4.5M would wipe out all starting cash and players would begin the game with a negative balance - quite challenging! For XComUtil, it might be best to break improved Facilities and Extra Starting Personnel into 2 options, with each having a sub-option to pay for the improvements. ''"These extra facilities/staff would cost $1.6M/$2.9M, do you want to deduct that amount from your starting cash?"'' [[User:Spike|Spike]] 20:48, 12 March 2010 (EST)

=== Easier Inventory Management ===
Inventory management is one of the things I hate about the first two X-Coms. I was hired to be a commander, not a supply clerk! A mod which made general stores have 10000 space (like Apoc) would be nice.. [[User:Cesium|Cesium]] 21:39, 9 February 2010 (EST)
: The manager of any facility has to deal with generalities of space issues. The clerk tells you if that fancy new tank you just bought will fit. He has to put it in storage and keep track of what shelf the ammo is on. --[[User:BladeFireLight|BladeFireLight]] 22:27, 9 February 2010 (EST)
:: That's the clerk's problem and if he complains too much I'll have him peel potatoes until his hands drop. In any event, the limit doesn't make any sense:
::* General stores size is 8x8x2 (8x8x3 in TFTD) per base defence map, and should have no problem storing more than 50 items.
::: The items taking up 1 item unit are typically about the size of humanoid body. I think it's not unreasonable to have no more than 50 of those in the area that the General Stores takes up.
:::: I can't find a list on the wiki of storage space requirements for items, so I'm not sure which items take up 1 item unit. Typically the main space wasters are Heavy Plasma ammo/Blaster Bombs/Stun Bombs (late game) and/or HWPs and avalanches (early game). These either are definitely not the size of a human body (ammo/Bombs), or shouldn't be stored in stores at all (HWPs gain nothing, and might as well lay around somewhere else in base).
::* The size of a fully built X-Com base is about the size of a city block (judging by comparison of base defence to terror missions), and should easily be able to hold hundreds of items even in the starting base if it's willing to put some stuff not in the general stores.
::* The space limit makes no sense. Why do Blaster Bombs and Heavy Plasma ammo take so much space whereas in the inventory view it doesn't take any more than normal ammo? Who stores <s>mini tanks</s> HWPs in the same compartment as light weapons? And the way X-Com (probably) stores ammo and explosives is scary...
::: As you suggest, extremely powerful ammunition probably requires a lot more space for safe and secure storage in-base, versus on a tactical mission. Imagine what would happen if a Blaster Bomb exploded in a base? Or was stolen? They probably use nuclear warhead style storage facilities for those. And similarly for Avalanche warheads, alien artifacts, Elerium, etc. Segregating dangerous/explosive items from other items probably uses up a lot of overhead in the construction of the storage space - think armoured, bomb-proof lockers and bulkheads, advanced security systems, airlocks, scanners, etc. This is not just like piling stuff up in your shed! And the Commander who left Elerium or Avalanche warheads lying around in his hanger or corridors would justifiably be sacked on the spot by XCom High Command. [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Well, judging by all the explosives in the hangar during base defence and the X-COM 1.0 Elerium bug, Elerium and explosive warheads ''are'' lying around in the base... And all the equipment in the General Stores is stored in ordinary lockers according to the General Stores map ;-) More to the point, if X-COM wants to store explosives safely (judging by said warheads X-COM doesn't care too much) they need a special facility for this, not to store them in the room which also contains all the base's weapons and priceless alien artifacts.

:::: Furthermore, I expect X-COM to improvise on storage in the interest of actually winning the war. X-COM does do this and ignore the limit when manufacturing stuff in-base or getting loot from missions. All that's needed is that X-COM will improvise for transfers too. I can't imagine a quartermaster informing the commander there isn't any room for the new armour and that the troops should go without. Maybe the reason X-COM doesn't pay quartermasters each month is that they keep getting themselves lynched by enraged X-COM troops...
::* Gameplay wise, inventory micromanagement is just no fun, especially in the late game when you have all the cash you need but still has to sell stuff after each combat (which can be prolonged if you haven't sold for awhile), otherwise you can't transfer items to the base where your main team is at.
::* Maybe this entire "stores" thing is a plot by the CFN to force X-Com to share its technology with them by forcing X-Com to sell sell sell. It's not like they pay X-Com the real worth of the technology anyway. [[User:Cesium|Cesium]] 23:47, 9 February 2010 (EST)
::: I think a lot of people do find the inventory management tedious, or unrealistically low. Personally I think it's about right for large equipment (missiles, tanks, bodies), but too low for small arms and personal equipment. And yes, it only reflects using the General Stores modules, not storing stuff at random points in the base - maybe fair enough. If the right offset to patch can be found, the storage limits could easily be raised. The last few bytes of [[BASE.DAT]] could be a good place to look for this offset. BASE.DAT can store up to 9,999 units of each item per base. The total limit for items per base would need to be found by experiment, but 9,999 might work for those who want to ignore inventory. For those who feel inventory management is OK but the limits set too tight, the capacity of each General Stores could be increased from 50 to 100 - assuming we can find the offset for this to patch it. [[User:Spike|Spike]] 19:50, 10 February 2010 (EST)
::::Maybe you can try there:
.text:00439C85 66 81 C5 F4 01 add bp, 500
::::[[User:Seb76|Seb76]] 13:03, 11 February 2010 (EST)
::::: Yes that works nicely. E.g. patch '''66 81 C5 E8 03''' at that location and you get 100 space per General Stores. Thanks Seb! [[User:Spike|Spike]] 18:21, 13 February 2010 (EST)
:::::: Now if only I had the offsets or search signature so we can add that as an options --[[User:BladeFireLight|BladeFireLight]] 18:24, 13 February 2010 (EST)
::::::: UFO 1.4 dos: offset 143748. TFTD 2.1 dos: offset 178462. TFTD v1 dos: offset 176861. TFTD CE: offset 252795. UFO CE: offset 236680. (all offsets are in decimal and point to the "F4 01" value to be patched).
::::::: Patching to "E8 03" has been tested on dos versions (not on CE) and it works. The "base information" screen will display the correct value, though the values to line length scale is such that the line will max at 250. [[User:Cesium|Cesium]] 05:57, 14 February 2010 (EST)
::::::::Are the preceding bytes the same from TFTD 1 and 2x? --[[User:BladeFireLight|BladeFireLight]] 17:26, 15 February 2010 (EST)
::::::::: Yes they are. '''81 C3 F4 01''' is the add instruction. [[User:Cesium|Cesium]] 17:48, 15 February 2010 (EST)
::::::::: Sig for UFO Dos is '''81 C6 F4 01''' --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
:::::::::: Do you also have the preceding bytes for UFO? with the signatures I can create a patch file for all versions --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
::::::::::: I am not sure I understand your question.. Judging the the two UFO versions I have available (1.3 per xcusetup and 1.4) the common preceding bytes are ''80 78 16 07 75 0C 80 78 3A 00 75 06'' (followed by the sig). You could try to use the sig alone - it exists only once in the file. [[User:Cesium|Cesium]] 19:35, 15 February 2010 (EST)
:::::::::::: Offset Locations are something I'm collecting but also the unique series of bytes to find them for the two geoscape/tactical that I dont have. (UFO Spanish, TFTD Italian) I hope to add a lot more options in the in the future. I do feel this one nerfs the storage system anything to get the game up and going faster is always a plus. --[[User:BladeFireLight|BladeFireLight]] 22:01, 15 February 2010 (EST)
::::::::::::: Well, you may want to add another General Stores to the improved starting base if you want to achieve the faster startup effect without "nerfing" storage system for rest of game (I prefer a "nerf" due to late-game reasons). Also, I suggest you add an message in Xcusetup to ask people to get in contact with you if they use an unknown/unrecognized version. [[User:Cesium|Cesium]] 14:27, 16 February 2010 (EST)
::: Inventory management is just as much a pain in the early game, where you almost always are out of space until your 2nd general stores is built. I like realistic constraints, but not tedium. Maybe upping the space per Stores from 50 units to 100 units would be a generally acceptable approach (now that Seb76 has kindly found the offset)? [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Yeah, that would be a great improvement. [[User:Cesium|Cesium]] 15:45, 13 February 2010 (EST)

:I can confirm Seb76 is correct, as ever. The 2 bytes at offsets '''0x39c88''' and '''0x39c89''' in geoscape.exe code for the capacity of each General Stores. Default value is 500 ('''F4 01''') which equates to 50 in-game internal capacity units. (Smallest item uses 0.1 in game capacity so I guess that is 1 unit in internal units). I am not sure about a signature. From what I can tell, the preceding bytes '''66 81 C5''' are unique in geoscape.exe, which seems pretty odd, so someone else should verify that. [[User:Spike|Spike]] 19:48, 13 February 2010 (EST)
:: Yes it is unique to CE. it does not exist in any DOS EXE, but "F4 01" can be found in 79 places. Trial and error could locate it. --[[User:BladeFireLight|BladeFireLight]] 20:50, 13 February 2010 (EST)

=== AutoCombat ===

==== Firepower Factors ====
You might want to consider replacing the weapon offensive weighting factors for Autocombat with some factors that are (inversely) related to the [[Weapon_Analysis#Quantitative_Analysis|% TUs Per Kill]]. I've tabulated these for each weapon (including tanks) vs each alien race. You would still need to account for Psi, light/darkness, and XCom armour. Plus you would need a similar offensive factor for the aliens' attacks. But I could probably help with that, I have the data that's directly comparable to the % TUs per Kill for XCom weapons. [[User:Spike|Spike]] 22:06, 12 February 2010 (EST)

==== AutoWithdrawal ====

One of the most tedious things you can try to do in XCom is to scavenge the battlefield and retreat to landing craft for an Abort. A great option would be an AutoWithdrawal, similar to an AutoCombat, but with an easier threshold of XCom vs Alien combat power.

Basically it would scavenge all loose equipment off the Battlescape - dropped friendly and alien items, friendly and alien corpses and wounded, all go back into the landing craft. Elerium, Alloys, and UFO Components would not be recovered, as this is (normally) impossible apart from full tactical victory. All friendly troops return to the landing craft. Friendly losses, and equipment recovered, would be proportional to the offensive factor ratios but much more favourable than for AutoCombat. E.g. as long as XCom factors were at least equal to Alien factors, they would be able to scavenge everything and recover without casualties. If the aliens were stronger than XCom, they would only recover part of the scavenged equipment, and risk partial casualties, at say one third the rate of AutoCombat. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

: It's too easy compared to actual game IMHO. Every time a battle went FUBAR for me, it got FUBAR all the way and I was lucky if I could salvage my own team/equipment and maybe a single alien weapon/body. An AutoWithdrawal without salvage might be useful, but perhaps instead we should change AutoCombat failure mode to work better (e.g. Make some X-COM people survive a failed AutoCombat, depending on strength vs aliens). [[User:Cesium|Cesium]] 15:00, 7 March 2010 (EST)

:: Yes fair point. I was not thinking of the FUBAR situations, and you are right about how hairy those are. I was thinking of the situation where you control a certain part of the battlefield, but you either don't want to go on an endless hunt for the last few aliens, or you pretty much know you can't take on the aliens that are left (e.g. in the UFO or some other stronghold) without getting creamed. You can exercise a safe withdrawal, it's just tedious to carry out all the bodies and equipment. But it's pretty hard for an AutoCombat algorithm to detect which of those situations it is - FUBAR, boredom, or tactical withdrawal. I'll have to think about that, there may be no realistic solution at all. And there is the existing "teleport loose items back to base" command line option to XComUtil, maybe that's enough. [[User:Spike|Spike]] 16:08, 7 March 2010 (EST)

=== Tougher UFOs ===

[[Wish_List_(EU)#Tougher_UFOs|Tougher UFOs]]
As this is entirely implemented by patching data and data files it is a good candidate for XComUtil rather than [[UFO Extender]].
: That would definitely make the game harder. 9.7 is about the installer and the bug fixes. This would be a good candidate for 9.8. --[[User:BladeFireLight|BladeFireLight]] 01:38, 19 February 2010 (EST)
:: Cool! [[User:Spike|Spike]] 02:25, 19 February 2010 (EST)

=== Rebalanced Craft Weapons ===

This fits under the "making useless things usefull" category. It would be a 9.8 or later option. The idea is to make the Cannon, Stingray, Laser Cannon and Fusion Ball Launcher useful. Hopefully it breaks up the monotony of Dual Avalanches followed by Dual Plasma Beams, every game.

There is one common element in the approach, and two options. The common element is to fix the stats on the Fusion Ball Launcher. The two options are to use a stat-based approach, or a cost-based approach, to fix the other weapons.

NB This proposal is still a draft and will need tweaking, but I've got it to the point where it is worth discussing. Feedback is welcome!

''(Ultimately, the Plasma Beam still ends up being pretty much the optimum weapon in the end game. To mitigate this, it is a good idea to select the existing Alternate Energy Weapons Manufacturing option in XComUtil.)''

==== Fusion Ball Launcher ====

Increase the ammo capacity from 2 to 3. Don't mess with the damage. Job done.

See [[User:Spike#Fusion_Ball_Launcher]] and discussions linked from there.

==== Cost Based Approach ====

This uses historically realistic costs to restore game balance between different craft weapons. The stand off advantage of Avalanche missiles is now purchased at a price which is significant in terms of XCom budgets and mission yields. Stingrays and Cannons become significantly cheaper alternatives. The Laser Cannon, with similar capabilities to Stingrays but free to operate, also becomes very attractive. Mounting dual launched weapons becomes a very expensive luxury.

*Increase Avalanche missile Purchase cost to $386,000
*Increase Stingray missile Purchase cost to $125,000
*Leave Sell prices unmodified (to avoid creating a cash reservoir at the start of the game)
*Leave Launcher buy/sell prices unmodified

See [[User:Spike#Cost_Based_Rebalancing]]

==== Stat Based Approach ====

This provides a benefit trade-off to shorter range weapons, by increasing their firepower or effectiveness relative to longer range weapons.

*Increase Cannon stats to 15 Damage, 50% hit. Firepower is tripled, slightly ahead of (unmodified) Avalanches launching in Aggressive mode. Increase rearming rate to 200.
*Increase Stingray accuracy to 80%. Decrease Avalanche accuracy to 60%. Stingray now has 50% more firepower relative to Avalanche. Increase Stingray rearming rate to 2, so a full craft can be re-armed in the same time period with either weapon (instead of twice as long for Stingray).
*Increase Laser Cannon stats to 100 Damage, 50% hit. Firepower is doubled, 20% more than (unmodified) Avalanches launching in Aggressive mode, 2/3rds of Plasma Beam firepower.

To avoid advanced XCom aircraft exploiting the extra firepower of the Cannon weapons and disregarding the return fire from UFOs, this is best used alongside the Tougher UFOs option.

See [[User:Spike#Stat_Based_Rebalancing]]

=== Rebalanced Infantry Weapons ===

See [[User:Spike#Balancing_Infantry_Weapons]]

Primarily this means making the Rifle a bit stronger, and probably making the Pistol a bit weaker.

==See Also==

[[Wish List]]

= Completed Wish List Items =

=== BFG Default To Unchanged ===

Is it possible when using the BattleFieldGenerator, for it to detect the actual conditions for the mission (terrain, enemy craft, and light level) and offer these as defaults? [[User:Spike|Spike]] 08:22, 13 February 2010 (EST)
:Press The esc key at the prompt. (Line 719 in Xcomutil.txt, not that I expect anyone to read the manual :) ) Enter should also work. --[[User:BladeFireLight|BladeFireLight]] 12:34, 13 February 2010 (EST)
:: RTFM eh? My biggest failing. Maybe you could add an explicit prompt "Esc or Enter = [whatever the unmodified value would be]". [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)
::: From what I can see, hitting Escape during BFG makes it continue with ''all'' values reverting to the original conditions. It would be nice to be able to select some but not all original conditions. My main use of this is to turn a night mission into a day mission without the hassle of keeping the landing craft hovering around until the terminator crosses the landing site. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
:::: You could just use the force all daylight option.
:::: After reviewing Scott's code. Esc leaves all setting as-is. Pressing enter or any other key not listed will randomly choose for you. I will see if I can change enter to leave as is. --[[User:BladeFireLight|BladeFireLight]] 11:00, 7 March 2010 (EST)
::::: This has been added --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)

= MISC =

* It's actually quite hard to downgrade to DOSBox 0.72 in Ubuntu. Only 0.73 is offered, there is no ability to Force back to a lower package level with Synaptic Package Manager. Unix guru skilz are required to rollback to 0.72, and I guess 0.74 is not around yet, or not packaged for Ubunut APT? Is there any way to fudge around this, e.g. by providing the command line arguments in an optional text file for xcusetup.bat to parse? Having said that, even with no command line arguments, xcusetup hangs on my 0.73 DOSBox while executing SDUMP. I had to reboot in Windows to run xcusetup.bat - something that is only possible on a dual boot machine / Wubi machine. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
** Try using a different batch interpreter like 4DOS [http://www.4dos.info] to execute xcusetup inside DosBox. I tested this throughly before under DosBox/Linux and it works well with recent 9.7 builds. I suggest running "config -set cpu core=dynamic" and "config -set cpu cycles=max" before xcusetup to speed it up (xcusetup doesn't detect DosBox when 4Dos is run, so it doesn't run these automatically unlike normal DosBox case). [[User:Cesium|Cesium]] 09:48, 7 March 2010 (EST)
** Oh, and downgrading isn't that difficult: Get a dosbox 0.72 deb, and run "dpkg -i" on it, and then do "echo dosbox hold | dpkg --set-selections" to prevent future upgrades. [[User:Cesium|Cesium]] 09:50, 7 March 2010 (EST)
** Another option is to install the dosemu package, and run xcusetup under that. EU/TFTD can be run under that, but it doesn't work as well there. (Oh, and there's no mount command there. UFO/TFTD needs to exist under ~/.dosemu/drive_c which is C:) [[User:Cesium|Cesium]] 11:42, 7 March 2010 (EST)

:Thanks Cesium I will check this out. I still think it would be good to have a solution that works for people who are not knowledgeable with the unix command line though. [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)

:: Why use Linux if you dont know how to use the console? It is a text mode OS with a separate GUI. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)

::: Well Ubuntu is a bit different, as it's supposed to be an OS for the general public, where you never need to touch text mode! Incidentally I can't find any DEB or other packages for 0.72, all that is available on the DOSBox website is the source code. They really don't seem to realise that 0.73 is buggy! So I guess I will need to '''make''' it. Or just wait for 0.74 as I think it's out soon. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)

:::: See [http://archive.ubuntu.com/ubuntu/pool/universe/d/dosbox/] for 0.72 debs. Unlike Windows, package systems in Unix land are centralized, so best location to search is typically a package server mirror or a distro mirror, not a vendor's website. [[User:Cesium|Cesium]] 17:36, 9 March 2010 (EST)

GEODATA.DAT

2010-03-14T22:45:44Z

BladeFireLight: /* Structure */ Flags Array explained.

Created in the MissDat folder when you start a battlescape mission, also copied to the savegame folder of choice when saving mid-mission. Primarily used for [[Battlescape Map Generation]] and to determine which [[TERRAIN|MCD files]] to load.

File is 92 bytes long for both UFO and TFTD. Values are presented according to byte offset (0 to 91) followed by the equivalent hex offset (00 to 5B) in bold.

= Structure =

0-1/00-01: Amount of map modules to place vertically (Y dimension of the map / 10).

2-3/02-03: Amount of map modules to place horizontally (X dimension of the map / 10).

4-5/04-05: Z dimension of the map.

6-7/06-07: X-Com craft type (ignore this if a base mission):

UFO TFTD
0: SkyRanger 0: Triton
1: Lightning 1: Hammerhead
2: Avenger 2: Leviathan
3: Interceptor *1 3: Barracuda *2
4: Firestorm *1 4: Manta *2
5: Small Scout 5: Survey Ship
6: Medium Scout 6: Escort
7: Large Scout 7: Cruiser
8: Harvestor 8: Heavy Cruiser
9: Abductor 9: Hunter
10: Terror Ship 10: Battleship
11: Battleship 11: Dreadnought
12: Supply Ship 12: Fleet Supply Cruiser

*1 Requires maps "Interc" and "Fires". These don't exist normally, though XcomUtil adds versions similar to the SkyRanger and Lightning.

*2 Requires maps "Barracud" and "Manta". These don't exist normally, though XcomUtil adds versions similar to the Triton and Hammerhead 

8-9/08-09: Alien craft type (ignore this if not a UFO mission). Uses the above values.

10-11/0A-0B: Terrain type. Typically depends on the mission [[Missions|type]] and [[WORLD.DAT|location]].

UFO TFTD
0: Jungle 0: Seabed
1: Farm 1: Pipes
2: Forest 2: Crashed Plane
3: X-Com Base 3: Atlantis
4: Alien Base 4: Mu
5: Urban 5: Sunken Galleon
6: Desert 6: Sunken Liner
7: Mountains 7: Volcanic
8: Polar 8: Coral
9: Mars 9: Artefact Site Stage 1
10: Artefact Site Stage 2
11: Cargo Ship Stage 1 & 2 (Check [[MISDATA.DAT]][20-21] for which)
12: Port Attack
13: Island Attack
14: Colony Stage 2
15: T'leth Stage 1
16: T'leth Stage 2
17: T'leth Stage 3
18: X-Com Base
19: Passenger Ship Stage 1
20: Passenger Ship Stage 2
21: Colony Stage 1

12-XX/0C-XX: The next [0-1]*[2-3] bytes list the [[MAPS_Terrain|map modules]] used to build the battlescape. Reads in order from west to east, north to south. For example, in the case of the largest map (50x50), this list would be 25 bytes.

Values of 253/254/255 mean that the a module does not need to be placed in that area because a large 2x2 module (eg. An X-Com hangar) has already covered it.

I've often observed the Tactical engine partly generating it's own maps, so there must be a way to have some - or all - of these values ignored.

- [[User:Bomb Bloke|Bomb Bloke]] 19:21, 6 February 2008 (PST)

...

37-83/25-53: These values are currently unknown, but they all seem to flag as either 0 or 1.

I thought one of them might determine if victim UFOs had been shot down or not, but I can't seem to see any consistant values that would indicate that.

Some might have something to do with the units present - Although this wouldn't account for all values, I can't think of anything else at the moment.

- [[User:Bomb Bloke|Bomb Bloke]] 19:21, 6 February 2008 (PST)

This is the RMP (or LZ depending on how you look at it) flag. It says if the craft or ground RMP file is used. --[[User:BladeFireLight|BladeFireLight]] 18:45, 14 March 2010 (EDT)

...

84/54: Amount of craft to be placed on the map.
0: None.
1: X-Com craft only.
2: X-Com and alien craft.

85/55: Mirror of [6-7] (X-Com craft type).

86/56: Y location of X-Com craft on map. Usually a multiple of 10.

87/57: X location of X-Com craft on map. Usually a multiple of 10.

88/58: Mirror of [8-9] (alien craft type).

89/59: Y location of alien craft on map. Usually a multiple of 10.

90/5A: X location of alien craft on map. Usually a multiple of 10.

91/5B: Unknown, never seen it flag.

==See Also==
* [[Saved_Game_Files#Missdat_Files|Missdat Files]]
* [[Battlescape Map Generation]]
[[Category:Game Files]]

XcomUtil

2010-03-14T07:14:23Z

BladeFireLight: /* The XcuSetup configuration program */

==What is XcomUtil?==

XcomUtil is an utility written by Scott T. Jones to enhance both UFO Defense and Terror From The Deep. It works with either both the DOS or the CE (Windows) version of each game.
Quoting from Scott T. Jones' [http://xcomutil.scotttjones.com/ page]: "XcomUtil is a game enhancer. It is not really an editor and it is certainly not a cheat program. The original purpose of XcomUtil was to make the game more difficult, because there was a bug in the original game that forced all games to the Beginner difficulty level, regardless of what level you chose."

Scott T. Jones worked on this software for years. On Jan 23 2007 he announced that he had passed development of XComUtil to [[User:BladeFireLight|BladeFireLight]] since his work prevented him from developing it anymore. The latest stable version (9.60) and the current beta version (9.7) can be downloaded from [http://www.bladefirelight.com/ www.bladefirelight.com].

==XcomUtil's features==

Most features are optional, others are not. Useing XcuSetup you can change what features you want to use at any time:
This list includes items in 9.7 currently in beta.

Fixed features:
*Fixes the difficulty bug mentioned above.
*Removes copy protection for UFO.
*Recovers MIA solders if you win combat (units under mind control when the last alien dies)
*Sets the soldiers to face different directions at the start inside the craft, giving better initial visibility.
*Changes the placement of the troops inside the Avenger, Lightning, Hammerhead and Leviathan.
*The 2 last features can be modified by changes to the files in XcomUtil\cfg (but be sure of knowing what you are doing)

Optional features:
*Allows for hybrid games, where UFO's maps can be played on TFTD and vice-versa.
*Allows to add [[statstrings]] and [[rank]] in soldier's names, for a quick overview of their abilities.
*Saves soldiers [[equipment]] configuration. [[Known Bugs#XComUtil Inventory Stacking Bug]]
*Allows you to control the order of which troops will exit the craft first/last.
*Has an option for a enhanced set of the original [[weapons]].
*Has an option to make the manufacture and use of laser and plasma weapons more difficult.
*Has an option to make [[research]] more difficult by making it highly dependent on capturing aliens.
*Allows to play only Day Missions or only [[Night Missions]].
*Allows to choose the light level, [[terrain]] and UFO/USO before each [[Battlescape|tactical mission]].
*Allows for world terrain and UFO/USO floorplans/shapes randomization.
*Permits players/modders to use new terrains and other features.
*Adds an AutoCombat feature to automatically resolve a combat.
*Allows for all 5 X-COM ships to carry troops.
*Allows for Skyrander/Triton to carry one [[Craft Armaments]]
*Option to fixe a number of bugs in maps, terrain and routes.
*Includes Vista/Windows 7 Blank Screen Fix.

Command line features:
*Allows to change the aliens and their weapons during tactical missions.
*Allows for changing difficulty levels on a saved game.

For a complete list see the XcomUtil.txt file included with the program.

==How to use XcomUtil==

Warning: this indications are merely for a quick use/explanation of some of its features. For full documentation read the XcomUtil.txt file included with the program. It is always recommended to make a backup copy of the game to restore it to its original configuration.

First, you will need to download XcomUtil from Blade FireLight's site and install it to your UFO/TFTD folder. If you want to change your options or skiped the setup dueing install, run XcuSetup and choose the options you want (there's an explaining list below).
For more advanced options you will need to use the xcomutil command (instructions on that below).
Finally, to load the game with XcomUtil fully working you will need to use the RunXcom command (or run XcomUtil\SteamSetup to configure Steam).

===The XcuSetup configuration program===

Before you can use XcomUtil first run the XcuSetup program (this will run during install). There is a number of optional command-line arguments to XcuSetup.

:XCUSETUP [uninstall] | [hybrid path] [debug] [options file] [skip] [nobackup]

:*"uninstall" : This options is used by itself and restores all backup files and removes any temp, config files or other files created by XCUSETUP and XcomUtil.

:*hybrid path : If you give it the path to the directory of TFTD (or the path to XCOM, if you are install XComUtil for TFTD), XcuSetup will import all the terrain from the other game. This makes it possible to play hybrid games which combine units and terrain from both games. This only needs to be done once.

:*"debug" : This option turns on logging of what options chooses and the file copy results to a log file. It also displays a list of all options chosen before applying the changes.

:*options file : This is a bath to a .BAT file overriding the defaults and skipping the questions. Each time XcuSetup is ran it creates XcomUtil\lastOp.bat file. This can be renamed and customized for this. DO NOT MODIFY XcomUtil\LastOp.bat directly, always copy to a new file.

:*"skip" : This options skips the continue prompts. Used with an options files this allows for silent install. (except on beta versions)

:*"nobackup" : This option will skip the backup IF a backup has already been made. If you have added any map packs or new terrain files you should not use this.

XcuSetup will then prompt you to choose a number of options:
*Do you want to Split the EXE? - The Windows version of XCOM and TFTD don't have separate executable (EXE) files for GEOSCAPE and TACTICAL. Choosing NO will disable most of XcuSetup's options.
*Run Patch Program? - If playing X-Com CE on Vista or Win7 You will need this patch to fix the blank screen on startup.
*Do you want to enable f0dder's loader? - This is in case you are having video problems with the Windows edition.
*Do you want to enable the use of UFO Extender? - Seb67 has created a loader for Windows UFO to enhance the game.
*Do you want to apply the fixes? - A number of fan made fixes to data files can be applied. Either all together or individually selected.
*Do you want to enable Fighter Transports? - This adds space into the two xcom fighter ships to carry a small number of men.
*Do you want to add one Hard Point to the Triton/Skyranger? - This adds 1 gun mount to either the Skyranger or the Triton
*Do you want to use the defensive starting base? - The starting base will have a different configuration better suited for defense
*Do you want to use the improved starting base? - The starting base will have the scientists and engineers will be increased to 50 each. It will also upgrade the Small Radar to a Large Radar (or their TFTD equivalents) and build an Alien Containment
*Do you want fix the Disjointed base bug? - This solves the disjointed base bug by removing the adjoining walls in various maps. This will result in some hallways ending in solid rock. The disjointed base bug is where the walls between base modules on the bottom row and left column are not correctly removed.
*Do you want to use the improved tank armor? -The HWP will have the same stats as the Hovertanks, if Yes is chosen. It also works for Coelacanths/Displacers in TFTD.
*-Do you want to use Improved Pistol/DartGun? - gives auto-fire
*Do you want to use Improved Heavy Laser? - Improve the accuracy of the Heavy Laser.
*Do you want to use Improved High Explosive/Magna-Pack Explosive? - damage increased (200) to the point that they can blow open UFOs' outer walls
*Do you want to use Improved Gauss Weapons? - Double the clip size of Gauss Rifle and Heavy Gauss, plus increase the damage of the Heavy Gauss from 75 to 80.
*Do you want to Remove Gauss Weapon Clips? - Remove the need for clips from Gauss weapons, and increase the damage of the Heavy Gauss from 75 to 80.
* Increase the damage of the Dye Grenade? - This makes it more useful for cover with out waiting 3 turns for the cloud to get big enough.
*Do you want to use the alternate laser Tech? - Lasers now require Elerium to be built (and Alloys for Heavy Lasers), plus it is not possible to build Plasma beam weapons (with the exception of the aircraft Plasma Cannon, which takes ''much'' longer to build, and clips for hand weapons). This alters [[Manufacturing Profitability]] significantly - Laser Cannon and Plasma Cannon are no longer a cash cow to be milked. This makes the strategic and economic game much more challenging.
*Do you want XcomUtil to attempt to fix TFTD Research Bugs? - This options attempts checks for an fixes issues in the TFTD Research after each combat. Research of MC Reader, Sub Construction and Aquaplastics are made available if they should be.
*Do you want to get research help from captured aliens? - This will ''greatly'' increase the research times for all technologies, and you will need to capture aliens to speed up your research and get your technology progression back to anywhere near what you are used to. It would be better stated as "Do you want research to depend largely on capturing aliens?". This is a great feature for those who want the game to be much more challenging both strategically and tactically.
*Do you want to see XcomUtil messages after combat? - This enables the display of messages between the tactical and world views to report AutoCombat results and any research help acquired by capturing aliens.
*Do you want stat strings added to the names of your troops? - To help distinguish them in combat, on equipment screens, and Base screens. Other suboptions will appear if you choose Yes. It is possible to auto-equip your troops, based on their stat strings or other labels.
*Do you want rank indicators added to the names of your troops? - This adds :a through :f after the name, to be used as a rank indicator, where a=rookie/seaman, b=squaddie/able-seaman, etc. This was chosen over traditional rank abbreviations both to save space and to create unique indicators.
*Do you want their number of kills added to the names of your troops? - This adds the number of kills after the rank indicator at the end of the name of your soldier.
*Do you want your troops automatically sorted before combat? - Places the rookies and high reaction soldiers at first to disembark the craft. (Or set up your own, custom sort order.)
*Do you want to automatically re-equip your troops before combat? - Saves the equipment for each soldier at the end of each mission and reequips them on their next mission.
*Do you want to eliminate mind control? - Completely removes Psionics/Molecular Control from the game. Neither Aliens nor X-COM have access to it. When not using Xcomutil.bat X-COM units can still use psionics/M.C.
*Do you want automatic screening for Psi ability? - Optional to always displays all soldiers Psi ability or Just after Psi/MC lab is resaerched.
*Do you want to fight all battles in daylight/darkness? - what it says: makes the game easier/harder.
''(skipping 2 options - dealt with below)''
*Do you want to use the XcomUtil BFG? - XcomUtil can generate the battlefield instead of letting the game do it.
*Do you want to be prompted before every ship attack? - this lets you set the terrain, ship, and type of alien ship before each battle.
*Do you want the world map terrain to be randomized? - This option is only avalible if you dont use BFG. This can make the world map look very weird, but it evenly distributes the occurrences of the various terrains without making them totally random.
*Do you want to use Random Alien Craft Floor Plans? - XcomUtil can randomize the floor plan on alien craft. Options for randomizing floor plans include randomizing once during setup, or if using the BFG before every combat. Using Random shapes or filling in the dead spaces with small rooms to create rectangle exterior shapes.

===The XcomUtil command===

In addition to XcuSetup and RunXcom. Another way to use XcomUtil is by running the xcomutil command to change a saved game. This command allow for specific modifications to the files (XcuSetup makes nearly all general modifications), especially to games saved while on tactical.
If you are going to edit the game through this command remember to make backup files of your saved game directories before using it. You should also read XComUtil's manual (XcomUtil\XcomUstil.txt) concerning each flag, otherwise you might end up your saved games.

====How to use the command====

The syntax for the command is :

''XCOMUTIL path [flags] [WRT]''

''path'' Where your game is located. If xcomutil is on the same folder then you will simply have to specify which saved game you want to be changed

''[flags]'' These are the specific commands. More on those below.

''[WRT]'' To make changes permanent you will need to put WRT at the end, otherwise XcomUtil will simulate only the effects (which is great to practice).

An example of a command would be:

''XCOMUTIL GAME_1 DXC WRT'' - This would eliminate all extra clips carried by the aliens on the first saved game.

====Flags affecting tactical missions====

These flags will change only elements of a saved tactical game. There are other flags that affect also Geoscape, although most of those changes can be made already with XcuSetup. For more information on the flags consult the XcomUtil.txt file.

*''DXC'' - This flag deletes all of the extra plasma clips carried by the aliens to make more room for extra aliens.
*''S2B'' - Changes stun launchers (SL) to blaster launchers (BL). Other similar flags include ''B2S'' (changes BLs to SLs); ''W2H'' which changes alien pistols and rifles to heavy plasmas; ''W2R'' changes alien weapons to rifles; ''W2P'' changes alien weapons to pistols.
*''CHG:old:new'' - This will change objects carried by the aliens from old to new. As an example it is possible to change plasma weapons to lasers or any other object on the inventory.
*''DEL:name'' - Deletes all objects carried by the aliens of the name type.
*''RPL:oldrace:newrace:oldrank:newrank'' - Allows to replace aliens and to change their ranks.
*''typ:#'' - This will add new alien units, if there is space for them. The possible flags are SEC, FLO, SNA, MUT, ETH, CEL, SIL, CHR, CIV or ALL. It is not possible to add large aliens.
*''VIS'' - Makes the entire battlefield visible, including the aliens.
*''WIN'' - Kills all alien units at the end of your turn.
*''ARM'' - Equips all unarmed aliens with a Heavy Plasma
*''SWP'' - Allows you to switch sides with the aliens (Warning: this flag can be very dangerous do your game, read the instructions to further details).

====Flags affecting Geoscape====

These flags make changes into a game saved on Geoscape. The changes aren't permanent and some of them can be used to cheat.

*''ACT:n'' - Sets the X-COM activity on each area to n.
*''MSK'' - Reveals the Psi level of Soldiers/Aquanauts.
*''TEC:xyz'' - Allows for unresearched technologies to be used/built. XYZ can be HUMAN, HYBRID or ALL
*''MNY:n'' - Sets the money to n.
*''FND:n'' - Sets the funding for each country to n times $1000.

====Flags affecting the game executable====

These flags make permanent changes to the game.

*''TNK'' - Adds improved HWP/SWS, with the stats of the Hovertanks/Displacers.
*''FLY'' - Allows Celatids, Silacoids, Engineers and Tentaculats to fly.
*''PSI'' - Gives Psi abilities to all alien Leaders/Commanders. Doesn't work with TFTD.
*''BAS'' - Uses the improved base.

===How To Start The Game Using XComUtil - RunXCom.bat===

After you have changed the game using XcuSetUp or/and xcomutil you must use the RunXCom.bat command.
If you are running the CE version on XP then you may need to install fodder's patch using XcuSetup. If you had already chosen No on that simply run XcuSetup again. For more information on this read the XcomUtil manual where the proper procedure for installing CE is explained.

If your playing X-Com through STEAM. The Installer will give you an option to change STEAM to ruse RunXcom to start the game, or run XcuSetup to change options. If you chose "NO" to configureing STEAM, or you ran "Validate Game Cashe" in STEAM then use XcomUtil\SteamSetup.bat to enable the XcomUtil STEAM menu.

==But I Don't Want Some Features==

This section is for XcomUtil 9.6. Version 9.7 adds more choice as to what changes are made.

Tested on: DOS Ver v1.4

As much as XcomUtil being a game enchancer, some aspects of the program cannot be easily disabled. Once installed via Xcusetup.bat, some features are implemented that may not be welcome (even if you answered 'No' to all questions). Such as, the soldier carrying capacity of the Interceptor and the Firestorm. If you were not wanting these additions, or any other, but want the Difficulty Bug squashed, you must use a different editor (for example: Khor Chin Heong's XCOM2 MultiEditor v0.2) to change values within the geoscape.exe back to originals. As much as this is a pain, it only needs to be done once if you keep a backup of the edited and corrected geoscape.exe.

How To:

Run Xcusetup.bat, when you are asked your first question, just close the program as you would any other windows program. Windows will come up with a message: "Cannot close this program normally, are you sure you want to end this program?" (or something similiar to that wording). Once closed, run XCOM2 MultiEditor. (NOTE: this editor works for Xcom1, even though its written for Xcom2 in mind) and change values to what they are originally. Look inside "Sub Editor" within the editor and change "Craft Weapons" to 0 for the Triton. Once you have edited the values back to originals, save it. Cut geoscape.exe from the currnt game install and move it to a new installation of Xcom1. Just overwrite geoscape.exe with your patched and edited file. Keep it somewhere else as a backup, just in case.

'''Original Ships''':
Remove SHP:CFG from Xcusetup.bat, before running the first time. (There is another flag that can be removed to bypass the base disjoint bug fix, but if that doesn't run then Xcomutil acts like Xcusetup.bat was never run at all.)

'''Making use of the Base Disjoint Bug - restoring the original base map files''':

XCUSetup forces a fix on the base map files when it is run, without prompting you if you want to do this or not. It effectively knocks out all the walls that would otherwise be sealed off when placed along the left and lower most edges of the base map grid.

While most players are content with the crude looking base maps and the complete unrestricted access to and from the various modules, some players may already know how the base disjoint bug works and will want to make use of the sealed off walls to control the flow of alien movement. If this sounds like you, read on.

To restore the old maps, you must make a backup of the xbase*.map files stored in the MAPS\ directory. You can also do this to the ubase*.map files to keep the alien base maps intact as well. Or if you can get access to these files on your installation CD, or a second copy of the game, you can take copies directly from there when you want to restore them.

Run xcusetup as per normal, then overwrite the map files with the backup copies.

==Advanced Statstrings==
Statstrings allow to rename your soldiers. For example, "Anton Miller /wMr" would be a '''w'''eak squaddie of excellent firing accuracy ('''m'''arksmanship) and decent '''r'''eactions. However, like almost everything in XcomUtil, this is fully configurable. Custom sets of statstring definitions can be found [[statstrings|here]].

==Troubleshooting FAQ==

===I have UFO/TFTD CE. How can I use f0dder's patch and XComUtil?===

XComUtil's package includes f0dder's patch. To install it, run XcuSetup and choose Yes on the f0dder's patch query.

===I have chosen No before and now XcuSetup doesn't show the option again (9.6 only)===

Delete the XCom4Win.xcf file from the UFO/TFTD folder. It will now show up again on XcuSetup.

===Is it possible to incorporate alien components (alien food, alien surgery, etc.) into XcomUtil/cfg/xcomutil.rm(x,t) for use in random maps?===

If you know the corrent HEX values then you can add any terrain tile. Items Listed in XcomUtil.txt are just the short list.

===I am using version 9.60, but it locks up when entering combat===

Find the file RunXComW.bat and open it with Notepad. Use the search function to locate every line that starts with the term xcopy, then add /y as a third parameter. For example:

xcopy xcubef missdat >nul

Becomes:

xcopy xcubef missdat /y >nul

Save the edited batch and you'll have no further problems.

XcomUtil 9.7 does not have this issue.

=See Also=

[[Manufacturing_Profitability#XComUtil_manufacturing_profitability|XcomUtil Manufacturing Profitability]]

[[Game Editors]]

[[Making the Game Harder]]

XcomUtil

2010-03-14T07:13:37Z

BladeFireLight:

==What is XcomUtil?==

XcomUtil is an utility written by Scott T. Jones to enhance both UFO Defense and Terror From The Deep. It works with either both the DOS or the CE (Windows) version of each game.
Quoting from Scott T. Jones' [http://xcomutil.scotttjones.com/ page]: "XcomUtil is a game enhancer. It is not really an editor and it is certainly not a cheat program. The original purpose of XcomUtil was to make the game more difficult, because there was a bug in the original game that forced all games to the Beginner difficulty level, regardless of what level you chose."

Scott T. Jones worked on this software for years. On Jan 23 2007 he announced that he had passed development of XComUtil to [[User:BladeFireLight|BladeFireLight]] since his work prevented him from developing it anymore. The latest stable version (9.60) and the current beta version (9.7) can be downloaded from [http://www.bladefirelight.com/ www.bladefirelight.com].

==XcomUtil's features==

Most features are optional, others are not. Useing XcuSetup you can change what features you want to use at any time:
This list includes items in 9.7 currently in beta.

Fixed features:
*Fixes the difficulty bug mentioned above.
*Removes copy protection for UFO.
*Recovers MIA solders if you win combat (units under mind control when the last alien dies)
*Sets the soldiers to face different directions at the start inside the craft, giving better initial visibility.
*Changes the placement of the troops inside the Avenger, Lightning, Hammerhead and Leviathan.
*The 2 last features can be modified by changes to the files in XcomUtil\cfg (but be sure of knowing what you are doing)

Optional features:
*Allows for hybrid games, where UFO's maps can be played on TFTD and vice-versa.
*Allows to add [[statstrings]] and [[rank]] in soldier's names, for a quick overview of their abilities.
*Saves soldiers [[equipment]] configuration. [[Known Bugs#XComUtil Inventory Stacking Bug]]
*Allows you to control the order of which troops will exit the craft first/last.
*Has an option for a enhanced set of the original [[weapons]].
*Has an option to make the manufacture and use of laser and plasma weapons more difficult.
*Has an option to make [[research]] more difficult by making it highly dependent on capturing aliens.
*Allows to play only Day Missions or only [[Night Missions]].
*Allows to choose the light level, [[terrain]] and UFO/USO before each [[Battlescape|tactical mission]].
*Allows for world terrain and UFO/USO floorplans/shapes randomization.
*Permits players/modders to use new terrains and other features.
*Adds an AutoCombat feature to automatically resolve a combat.
*Allows for all 5 X-COM ships to carry troops.
*Allows for Skyrander/Triton to carry one [[Craft Armaments]]
*Option to fixe a number of bugs in maps, terrain and routes.
*Includes Vista/Windows 7 Blank Screen Fix.

Command line features:
*Allows to change the aliens and their weapons during tactical missions.
*Allows for changing difficulty levels on a saved game.

For a complete list see the XcomUtil.txt file included with the program.

==How to use XcomUtil==

Warning: this indications are merely for a quick use/explanation of some of its features. For full documentation read the XcomUtil.txt file included with the program. It is always recommended to make a backup copy of the game to restore it to its original configuration.

First, you will need to download XcomUtil from Blade FireLight's site and install it to your UFO/TFTD folder. If you want to change your options or skiped the setup dueing install, run XcuSetup and choose the options you want (there's an explaining list below).
For more advanced options you will need to use the xcomutil command (instructions on that below).
Finally, to load the game with XcomUtil fully working you will need to use the RunXcom command (or run XcomUtil\SteamSetup to configure Steam).

===The XcuSetup configuration program===

Before you can use XcomUtil first run the XcuSetup program (this will run during install). There is a number of optional command-line arguments to XcuSetup.

:XCUSETUP [uninstall] | [hybrid path] [debug] [options file] [skip] [nobackup]

::"uninstall" : This options is used by itself and restores all backup files and removes any temp, config files or other files created by XCUSETUP and XcomUtil.

::hybrid path : If you give it the path to the directory of TFTD (or the path to XCOM, if you are install XComUtil for TFTD), XcuSetup will import all the terrain from the other game. This makes it possible to play hybrid games which combine units and terrain from both games. This only needs to be done once.

::"debug" : This option turns on logging of what options chooses and the file copy results to a log file. It also displays a list of all options chosen before applying the changes.

::options file : This is a bath to a .BAT file overriding the defaults and skipping the questions. Each time XcuSetup is ran it creates XcomUtil\lastOp.bat file. This can be renamed and customized for this. DO NOT MODIFY XcomUtil\LastOp.bat directly, always copy to a new file.

::"skip" : This options skips the continue prompts. Used with an options files this allows for silent install. (except on beta versions)

::"nobackup" : This option will skip the backup IF a backup has already been made. If you have added any map packs or new terrain files you should not use this.

XcuSetup will then prompt you to choose a number of options:
*Do you want to Split the EXE? - The Windows version of XCOM and TFTD don't have separate executable (EXE) files for GEOSCAPE and TACTICAL. Choosing NO will disable most of XcuSetup's options.
*Run Patch Program? - If playing X-Com CE on Vista or Win7 You will need this patch to fix the blank screen on startup.
*Do you want to enable f0dder's loader? - This is in case you are having video problems with the Windows edition.
*Do you want to enable the use of UFO Extender? - Seb67 has created a loader for Windows UFO to enhance the game.
*Do you want to apply the fixes? - A number of fan made fixes to data files can be applied. Either all together or individually selected.
*Do you want to enable Fighter Transports? - This adds space into the two xcom fighter ships to carry a small number of men.
*Do you want to add one Hard Point to the Triton/Skyranger? - This adds 1 gun mount to either the Skyranger or the Triton
*Do you want to use the defensive starting base? - The starting base will have a different configuration better suited for defense
*Do you want to use the improved starting base? - The starting base will have the scientists and engineers will be increased to 50 each. It will also upgrade the Small Radar to a Large Radar (or their TFTD equivalents) and build an Alien Containment
*Do you want fix the Disjointed base bug? - This solves the disjointed base bug by removing the adjoining walls in various maps. This will result in some hallways ending in solid rock. The disjointed base bug is where the walls between base modules on the bottom row and left column are not correctly removed.
*Do you want to use the improved tank armor? -The HWP will have the same stats as the Hovertanks, if Yes is chosen. It also works for Coelacanths/Displacers in TFTD.
*-Do you want to use Improved Pistol/DartGun? - gives auto-fire
*Do you want to use Improved Heavy Laser? - Improve the accuracy of the Heavy Laser.
*Do you want to use Improved High Explosive/Magna-Pack Explosive? - damage increased (200) to the point that they can blow open UFOs' outer walls
*Do you want to use Improved Gauss Weapons? - Double the clip size of Gauss Rifle and Heavy Gauss, plus increase the damage of the Heavy Gauss from 75 to 80.
*Do you want to Remove Gauss Weapon Clips? - Remove the need for clips from Gauss weapons, and increase the damage of the Heavy Gauss from 75 to 80.
* Increase the damage of the Dye Grenade? - This makes it more useful for cover with out waiting 3 turns for the cloud to get big enough.
*Do you want to use the alternate laser Tech? - Lasers now require Elerium to be built (and Alloys for Heavy Lasers), plus it is not possible to build Plasma beam weapons (with the exception of the aircraft Plasma Cannon, which takes ''much'' longer to build, and clips for hand weapons). This alters [[Manufacturing Profitability]] significantly - Laser Cannon and Plasma Cannon are no longer a cash cow to be milked. This makes the strategic and economic game much more challenging.
*Do you want XcomUtil to attempt to fix TFTD Research Bugs? - This options attempts checks for an fixes issues in the TFTD Research after each combat. Research of MC Reader, Sub Construction and Aquaplastics are made available if they should be.
*Do you want to get research help from captured aliens? - This will ''greatly'' increase the research times for all technologies, and you will need to capture aliens to speed up your research and get your technology progression back to anywhere near what you are used to. It would be better stated as "Do you want research to depend largely on capturing aliens?". This is a great feature for those who want the game to be much more challenging both strategically and tactically.
*Do you want to see XcomUtil messages after combat? - This enables the display of messages between the tactical and world views to report AutoCombat results and any research help acquired by capturing aliens.
*Do you want stat strings added to the names of your troops? - To help distinguish them in combat, on equipment screens, and Base screens. Other suboptions will appear if you choose Yes. It is possible to auto-equip your troops, based on their stat strings or other labels.
*Do you want rank indicators added to the names of your troops? - This adds :a through :f after the name, to be used as a rank indicator, where a=rookie/seaman, b=squaddie/able-seaman, etc. This was chosen over traditional rank abbreviations both to save space and to create unique indicators.
*Do you want their number of kills added to the names of your troops? - This adds the number of kills after the rank indicator at the end of the name of your soldier.
*Do you want your troops automatically sorted before combat? - Places the rookies and high reaction soldiers at first to disembark the craft. (Or set up your own, custom sort order.)
*Do you want to automatically re-equip your troops before combat? - Saves the equipment for each soldier at the end of each mission and reequips them on their next mission.
*Do you want to eliminate mind control? - Completely removes Psionics/Molecular Control from the game. Neither Aliens nor X-COM have access to it. When not using Xcomutil.bat X-COM units can still use psionics/M.C.
*Do you want automatic screening for Psi ability? - Optional to always displays all soldiers Psi ability or Just after Psi/MC lab is resaerched.
*Do you want to fight all battles in daylight/darkness? - what it says: makes the game easier/harder.
''(skipping 2 options - dealt with below)''
*Do you want to use the XcomUtil BFG? - XcomUtil can generate the battlefield instead of letting the game do it.
*Do you want to be prompted before every ship attack? - this lets you set the terrain, ship, and type of alien ship before each battle.
*Do you want the world map terrain to be randomized? - This option is only avalible if you dont use BFG. This can make the world map look very weird, but it evenly distributes the occurrences of the various terrains without making them totally random.
*Do you want to use Random Alien Craft Floor Plans? - XcomUtil can randomize the floor plan on alien craft. Options for randomizing floor plans include randomizing once during setup, or if using the BFG before every combat. Using Random shapes or filling in the dead spaces with small rooms to create rectangle exterior shapes.

===The XcomUtil command===

In addition to XcuSetup and RunXcom. Another way to use XcomUtil is by running the xcomutil command to change a saved game. This command allow for specific modifications to the files (XcuSetup makes nearly all general modifications), especially to games saved while on tactical.
If you are going to edit the game through this command remember to make backup files of your saved game directories before using it. You should also read XComUtil's manual (XcomUtil\XcomUstil.txt) concerning each flag, otherwise you might end up your saved games.

====How to use the command====

The syntax for the command is :

''XCOMUTIL path [flags] [WRT]''

''path'' Where your game is located. If xcomutil is on the same folder then you will simply have to specify which saved game you want to be changed

''[flags]'' These are the specific commands. More on those below.

''[WRT]'' To make changes permanent you will need to put WRT at the end, otherwise XcomUtil will simulate only the effects (which is great to practice).

An example of a command would be:

''XCOMUTIL GAME_1 DXC WRT'' - This would eliminate all extra clips carried by the aliens on the first saved game.

====Flags affecting tactical missions====

These flags will change only elements of a saved tactical game. There are other flags that affect also Geoscape, although most of those changes can be made already with XcuSetup. For more information on the flags consult the XcomUtil.txt file.

*''DXC'' - This flag deletes all of the extra plasma clips carried by the aliens to make more room for extra aliens.
*''S2B'' - Changes stun launchers (SL) to blaster launchers (BL). Other similar flags include ''B2S'' (changes BLs to SLs); ''W2H'' which changes alien pistols and rifles to heavy plasmas; ''W2R'' changes alien weapons to rifles; ''W2P'' changes alien weapons to pistols.
*''CHG:old:new'' - This will change objects carried by the aliens from old to new. As an example it is possible to change plasma weapons to lasers or any other object on the inventory.
*''DEL:name'' - Deletes all objects carried by the aliens of the name type.
*''RPL:oldrace:newrace:oldrank:newrank'' - Allows to replace aliens and to change their ranks.
*''typ:#'' - This will add new alien units, if there is space for them. The possible flags are SEC, FLO, SNA, MUT, ETH, CEL, SIL, CHR, CIV or ALL. It is not possible to add large aliens.
*''VIS'' - Makes the entire battlefield visible, including the aliens.
*''WIN'' - Kills all alien units at the end of your turn.
*''ARM'' - Equips all unarmed aliens with a Heavy Plasma
*''SWP'' - Allows you to switch sides with the aliens (Warning: this flag can be very dangerous do your game, read the instructions to further details).

====Flags affecting Geoscape====

These flags make changes into a game saved on Geoscape. The changes aren't permanent and some of them can be used to cheat.

*''ACT:n'' - Sets the X-COM activity on each area to n.
*''MSK'' - Reveals the Psi level of Soldiers/Aquanauts.
*''TEC:xyz'' - Allows for unresearched technologies to be used/built. XYZ can be HUMAN, HYBRID or ALL
*''MNY:n'' - Sets the money to n.
*''FND:n'' - Sets the funding for each country to n times $1000.

====Flags affecting the game executable====

These flags make permanent changes to the game.

*''TNK'' - Adds improved HWP/SWS, with the stats of the Hovertanks/Displacers.
*''FLY'' - Allows Celatids, Silacoids, Engineers and Tentaculats to fly.
*''PSI'' - Gives Psi abilities to all alien Leaders/Commanders. Doesn't work with TFTD.
*''BAS'' - Uses the improved base.

===How To Start The Game Using XComUtil - RunXCom.bat===

After you have changed the game using XcuSetUp or/and xcomutil you must use the RunXCom.bat command.
If you are running the CE version on XP then you may need to install fodder's patch using XcuSetup. If you had already chosen No on that simply run XcuSetup again. For more information on this read the XcomUtil manual where the proper procedure for installing CE is explained.

If your playing X-Com through STEAM. The Installer will give you an option to change STEAM to ruse RunXcom to start the game, or run XcuSetup to change options. If you chose "NO" to configureing STEAM, or you ran "Validate Game Cashe" in STEAM then use XcomUtil\SteamSetup.bat to enable the XcomUtil STEAM menu.

==But I Don't Want Some Features==

This section is for XcomUtil 9.6. Version 9.7 adds more choice as to what changes are made.

Tested on: DOS Ver v1.4

As much as XcomUtil being a game enchancer, some aspects of the program cannot be easily disabled. Once installed via Xcusetup.bat, some features are implemented that may not be welcome (even if you answered 'No' to all questions). Such as, the soldier carrying capacity of the Interceptor and the Firestorm. If you were not wanting these additions, or any other, but want the Difficulty Bug squashed, you must use a different editor (for example: Khor Chin Heong's XCOM2 MultiEditor v0.2) to change values within the geoscape.exe back to originals. As much as this is a pain, it only needs to be done once if you keep a backup of the edited and corrected geoscape.exe.

How To:

Run Xcusetup.bat, when you are asked your first question, just close the program as you would any other windows program. Windows will come up with a message: "Cannot close this program normally, are you sure you want to end this program?" (or something similiar to that wording). Once closed, run XCOM2 MultiEditor. (NOTE: this editor works for Xcom1, even though its written for Xcom2 in mind) and change values to what they are originally. Look inside "Sub Editor" within the editor and change "Craft Weapons" to 0 for the Triton. Once you have edited the values back to originals, save it. Cut geoscape.exe from the currnt game install and move it to a new installation of Xcom1. Just overwrite geoscape.exe with your patched and edited file. Keep it somewhere else as a backup, just in case.

'''Original Ships''':
Remove SHP:CFG from Xcusetup.bat, before running the first time. (There is another flag that can be removed to bypass the base disjoint bug fix, but if that doesn't run then Xcomutil acts like Xcusetup.bat was never run at all.)

'''Making use of the Base Disjoint Bug - restoring the original base map files''':

XCUSetup forces a fix on the base map files when it is run, without prompting you if you want to do this or not. It effectively knocks out all the walls that would otherwise be sealed off when placed along the left and lower most edges of the base map grid.

While most players are content with the crude looking base maps and the complete unrestricted access to and from the various modules, some players may already know how the base disjoint bug works and will want to make use of the sealed off walls to control the flow of alien movement. If this sounds like you, read on.

To restore the old maps, you must make a backup of the xbase*.map files stored in the MAPS\ directory. You can also do this to the ubase*.map files to keep the alien base maps intact as well. Or if you can get access to these files on your installation CD, or a second copy of the game, you can take copies directly from there when you want to restore them.

Run xcusetup as per normal, then overwrite the map files with the backup copies.

==Advanced Statstrings==
Statstrings allow to rename your soldiers. For example, "Anton Miller /wMr" would be a '''w'''eak squaddie of excellent firing accuracy ('''m'''arksmanship) and decent '''r'''eactions. However, like almost everything in XcomUtil, this is fully configurable. Custom sets of statstring definitions can be found [[statstrings|here]].

==Troubleshooting FAQ==

===I have UFO/TFTD CE. How can I use f0dder's patch and XComUtil?===

XComUtil's package includes f0dder's patch. To install it, run XcuSetup and choose Yes on the f0dder's patch query.

===I have chosen No before and now XcuSetup doesn't show the option again (9.6 only)===

Delete the XCom4Win.xcf file from the UFO/TFTD folder. It will now show up again on XcuSetup.

===Is it possible to incorporate alien components (alien food, alien surgery, etc.) into XcomUtil/cfg/xcomutil.rm(x,t) for use in random maps?===

If you know the corrent HEX values then you can add any terrain tile. Items Listed in XcomUtil.txt are just the short list.

===I am using version 9.60, but it locks up when entering combat===

Find the file RunXComW.bat and open it with Notepad. Use the search function to locate every line that starts with the term xcopy, then add /y as a third parameter. For example:

xcopy xcubef missdat >nul

Becomes:

xcopy xcubef missdat /y >nul

Save the edited batch and you'll have no further problems.

XcomUtil 9.7 does not have this issue.

=See Also=

[[Manufacturing_Profitability#XComUtil_manufacturing_profitability|XcomUtil Manufacturing Profitability]]

[[Game Editors]]

[[Making the Game Harder]]

Talk:XcomUtil

2010-03-14T06:16:27Z

BladeFireLight: /* MISC */

=XcomUtil 9.7 Beta=

9.7 Beta is available on www.bladefirelight.com

==Release Notes==

This is a Beta, so backup your files before using. And check back often for newer builds.

New in this version.

*Major overhall of the installer (XcuSetup) and the inclusion of 16/32bit exe's to support both DOSBox and Windows Vista/7 x64.
*New subfolders added to hold supporting files making the install cleaner
*New XcuSetup command line arguments were added to XcuSetup allowing for silent install and uninstallation.
*New XcuSetup option for debugging the install (XcuSetup debug) creating XcomUtil\debug.txt.
*New command line argument "nobackup" skips backup only if it has been ran atleast once.
*XcuSetup can now have minimal impact on the game.
**Almost all options default to NO (Only Split Windows EXE set to Yes).
**Almost all changes are now prompted for (skyranger guns, interceptor as transport, Disjointed Base Bug, etc...).
***Items still done by default:
***Copy protection questions set to 0000000 for UFO 1.0-1.3 and X-Com 1.0
***Difficulty bug fixed in UFO 1.0-1.4 and X-Com 1.0-1.4
***Unique names for all maps in TFTD, Used for Hybrid Games
***Placement of X-Com Units on the Battlefield based on XcomUtil.cfg
***MIA Recovery on Won Combat (Units under mind\MC control when last controling alien killed are returned to X-Com control)
*XcomUtil.cfg is now pieced together and overwritten by XcuSetup (see XcomUtil\XcomUtil.txt for how to make permanent changes).
*All game files are restored to the pre-XcomUtil state each time XcuSetup is ran. Any modifications by other utilities will have to be re-applied.
*Vista/Win7 patch now an option for XcuSetup.
**This will fix the blank screen issue.
**Updated to support the split EXE.
**Will set X-Com to use CPU 0.
*XcuSetup attempts to fix UAC issues by resetting folder permissions.
*A number of community made fixes are included and selectable with XcuSetup.
*Support for the DOS/Window STEAM Install.
**Installer will detect STEAM and change steam launcher to start the XcomUtil Steam Menu (can be re-installed with XcomUtil\SteamSetup.bat
*Out of the box support for UFO Extender. XcuSetup will detect it and ask if you want RunXcom to use it.
*XcuSetup can be run from windows and RunXcom run from DosBox
*Hybrid Colors updated based on BombBloke's pallets.
*EQL flag allowed any turn.
*Add Xcom UFO Italian Support.
*Auto Combat will not run on second half of two part using first parts saved data.
*Auto Combat will no longer run if combat was won.
*MIA Recovery on won combat only.
*MIA Recovery no longer recovering units that bleed to death.
*Auto equip no longer triggers on second part of 2 stage missions.
*Combine clips skiped if between stages of 2-3 part missions.
*Updated f0dders ReadMe per his request. (XcomUtil\bugfix-readme.txt)
*Add-on support added. see XcomUtil\XcomUtil.txt and XcomUtil\Addon\Example.txt
*Prompted Terrain in BattleField Generator allows to abort or use of current setting.
*Beta versions include
**XcomUtil\XcomUtil.log includes lots of debug info
**XcomUtil\Debug.txt created by default (Release will need "debug" command argument)

Removed from this versions

*New Desert and Urban terrain. (Will be added once I have a C++ version of the Java Terrain Edit.)
*Expanded capacity Laviathan, Hammerhead and Avenger (maps avalible in XcomUtil\Patches)

NOTE: If you use DosBox, this requires DosBox 0.72 (Does not work on 0.73 due to buffer overflow setting ERRORLVEL)

===Build 435===

Original Sound Effects from UFO were re-sampled to work with 1.4 and CE.

*Add Category to option headers.
*Improve randomness by using current time instead of game date/time in srand()
*Added Option to keep Current terrain/UFO to BFG.
*Original UFO 1.2 Sounds for Geoscape and Tactical added as an option for UFO 1.4 and CE.
*Force Split EXE on STEAM. Fixes issues with setup failing.
*Reset Laser/Gauss craft weapons stats to be default.
*Example addon now uses different flag extension to avoid deletion by XcuSetup
*fix issue with Lab Screen on DosBox always screening

==Beta Disscusion==

===Build 435===
: I hope the improved randomness doesn't apply to the Aliens' d100 during AutoCombat. Otherwise, one could load-scum for success. [[User:Cesium|Cesium]] 06:33, 11 March 2010 (EST)
:: Actually it does. I can see what your getting at, but why do it that way. if you want to win the "WIN" command line option is faster and you get better loot from the UFO. also using the combat date would also swing the other way with an unwindable autocombat with an fully loaded avenger vs a survey ship. --[[User:BladeFireLight|BladeFireLight]] 17:41, 11 March 2010 (EST)
: In the setup question for sound files: "were replace" should be "were replaced". [[User:Cesium|Cesium]] 06:53, 11 March 2010 (EST)

Excellent! For the first time xcusetup.bat completed for me in Dosbox in Ubuntu. Previously the SDUMP commands were hanging it.

For the first time ever, I ran the sound setup utility. It did not response to any cursor keys, enter, tab, etc. The only key that worked was Escape, and I'm not sure what this did.

One point on the xcusetup.bat script - Ctrl C does not seem to work. On all those "press a key to continue" prompts could we also have "or 'q' to quit"?

[[User:Spike|Spike]] 18:41, 13 March 2010 (EST)

: "press a key to continue" is the Pause command. Ctrl + C works fine in Windows. DOSBox does not. The reason for the use of Pause is because an number of new players kept exiting setup early when I gave the option. Aborting early makes a mess and I dont want to have to troubleshoot it for Joe user. --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)

==Open Bugs==
*FreeDOS breaks horribly dering Setup
:*This is mostlikely an issue with the limits of FreeDOS.
*There's no Italian text for the Alternate Laser Weapons option. Applying the patch seems to work, but it displays the text for the default laser weapons.
:*Anyone want to translate the text into Italian? --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
*The number of aliens in the mission report is inconsistent with the number of live aliens captured per research help. See [[Image:Alien_numbers_mismatch.zip]] and [[Image:Dead_alien_count.zip]].
* Morale is random at start of second stage after autocombat of first stage?
:* Actually Morale is used as the clip size and time units as the weapon damage. Don't ask me why. It would take a major re-write of auto combat to fix this. --[[User:BladeFireLight|BladeFireLight]] 19:34, 23 February 2010 (EST)
* All Civilians are dead if AutoCombat is used to end a Terror mission. It's too not much of a problem, since score is likely to be positive anyway. It would possibly be an improvement to assume all civs from first stage are dead (if ran at second stage) and get a random number (using mission seed) for dead civs at current stage? [[User:Cesium|Cesium]] 07:00, 22 February 2010 (EST)
:* This is odd. Autocombat is supposed to skip over civilians when using the kill function. --[[User:BladeFireLight|BladeFireLight]] 00:18, 24 February 2010 (EST)
::*Maybe kill civilians (or not) according to the force ratios. If XCom has only enough force to win the mission, all Civilians are dead. If XCom bring a certain amount of "excessive force", all or nearly all Civilians are saved. By the way I love AutoCombat, it is great for avoiding repetitive combat and only playing the new, interesting bits. [[User:Spike|Spike]] 15:53, 22 February 2010 (EST)
:::* Thinking about this, I recalled the scenario where someone fights the mission and uses AutoCombat to hunt the last aliens (another reason AutoCombat is great). Spike's suggestion is better from pure RNG, since in this case probably all civs that were at risk already died. So lets see what we suggest XcomUtil do:
:::# Count civs from first stage if there was one as dead (since IIRC XcomUtil has no memory of first stage when exiting second stage, so we can't take them into account?).
:::# Deduct dead civs from current stage.
:::# Calculate extra dead civs using force ratio to bias the RNG (I prefer merely biasing the RNG rather than precluding results, since Xcom in general has a large variance in almost every gameplay mechanic). [[User:Cesium|Cesium]] 18:27, 22 February 2010 (EST)
*RPL bug, when you turn creatures into Gill Men, they are reported as Snakemen
:* Reported how? Is this consistent? The name's used are from xcomutil.cfg. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
::*Sorry. It's reported in morale failure pop up messages. Though maybe this is an original TFTD bug rather than an XComUtil bug. [[User:Spike|Spike]] 19:21, 21 February 2010 (EST)
:::* See this: [http://www.youtube.com/watch?v=uGlSghf7aTU]. In that case, all Gill man (were lobster man before RPL) were reported as snakemen.. [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST)
*RPL bug, when you turn Lobstermen into other creatures (e.g. Gill Men), they are very hard to kill despite having the stats of the creature they turned in to. Possibly they are keeping their damage resistance? Maybe the race is stored in more than one place, for different purposes, and XComUtil misses one of these places?
:: I will look into this --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: The RPL only changes the basics; The race, rank, name, TimeUnits, Health, Energy, Reactions, Armor(front,back,left,right), Strenght and PSI Strenght. All other stats are left as-is. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
:::: I'm not so sure about this. See 05:00 mark at [http://www.youtube.com/watch?v=y-_zLdjhUHI]. The armour doesn't match the one Gill man should have (per UFOpaedia, at least). [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST). See also 04:17 mark at [http://www.youtube.com/watch?v=z5LfzFSkRnI] for reason to suspect resistances aren't always changed. It's possible he just was unlucky though... [[User:Cesium|Cesium]] 19:53, 21 February 2010 (EST)
::::: Actually the function is something like this
<pre>#define UpdateStat(x,y) pur->x = (unsigned char) \
( ( (unsigned int)pur->x \
* (unsigned int)pasTo->y \
) / (unsigned int)pasFrom->y )
UpdateStat( TimeUnits0, TimeUnits );
UpdateStat( Health0, Health );
UpdateStat( Energy0, Energy );
UpdateStat( Reactions0, Reactions );
UpdateStat( AFront0, AFront2 );
UpdateStat( ALeft0, ALeft2 );
UpdateStat( ARight0, ARight2 );
UpdateStat( ARear0, ARear2 );
UpdateStat( AUnder0, AUnder2 );
UpdateStat( Strength, Strength );
UpdateStat( PsiStrength, PsiStrength );
</pre>
::::: the 0's are values at start of tactical.
::::: I read that as Current(from game_x) * Target default(from xcomutil.cfg) / source default (from Xcomutil.cfg) so the stats will be different. --[[User:BladeFireLight|BladeFireLight]] 21:33, 21 February 2010 (EST)
:::::: I'd have expected Current(game_x) == Source default if applied on first turn? This would end up with result == Target default, no? Hmmm... We already saw some compiler multiplication wackiness with the research help bug. Possibly this affected these calculations too?
:::::: As for the code, you're not updating PsiSkill, so non Psi-users can't get Psi after RPL. [[User:Cesium|Cesium]] 22:03, 21 February 2010 (EST)
::::::: I didn't write this. I'm amusing Scott did it this way to adjust for difficulty because XcomUtil.cfg has the beginner level stats. It need's an overhaul to use the full stat entries including the unknowns adjusted correctly for the level. Something for latter. --[[User:BladeFireLight|BladeFireLight]] 22:09, 21 February 2010 (EST)
:::::::: For this specific issue I think you will need to update 0x37 of [[UNITREF.DAT]] which is the Damage Modifier. In addition to the Psi Strength. Also Firing Accuracy, energy regen rate, movement class... loads of stuff. And of course LOFTEMPS. So with current RPL not changing LOFTEMPS, changed aliens are the wrong size and shape probably. This would be visible using the LOFTEMPS map viewer I suppose. [[User:Spike|Spike]] 18:39, 9 March 2010 (EST)
*[[Known Bugs#XComUtil Inventory Stacking Bug]]
:* I hope to overcome this but Scott's notes point to a technical limitation. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*Was it really intended to '''not''' have nerfed the [[Manufacturing_Profitability#XComUtil_manufacturing_profitability|Profitability]] of the Fusion Ball Launcher along with everything else? More generally, the profit nerfing could be revised to be more orderly and more systematic.
:: I dont really know what Scott intended as for the profiteering off of the changed items. If you want to suggest alternative values I'm open to discussion. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: A preliminary suggestion would be to make the Fusion Ball Launcher similarly difficult to manufacture as the Plasma Beam, so about ten times harder vs the unmodified game. E.g. Workshop space 6 -> 60, 400 -> 4000 Engineer hours. And perhaps require 4 Elerium and 20 Alloys, placing it midway between Laser Cannon and Plasma Beams. These changes (even without the materials) make the FBL unprofitable, like the (modified) Plasma Beam. I'm sure part of Scott's intent was to prevent "Laser Cannon Factories", but "FBL Factories" are 75% as profitable.
::: General reform of the profitability of manufacturing would require a lot of thought. Suffice to say I don't think '''any''' thought went into this for the original game. In reforming the economics of XCom, a basic problem is that realism is at odds with game balance. Realistically, governments would pay handsomely for almost anything XCom can produce. What would be reasonable is to get a moderate rate of return, rising more or less linear with investment (research effort), for ''all'' items. For game balance, this could be tweaked down for items that are useful in the game, or have research predecessors / successors that are useful in the game. A simpler case is to say that no item has negative profit, you can at least get 'cost price' back for it. Aircraft should arguably be in this category (since they would sell for 100s of millions which would be totally unbalancing). A rationalisation for nerfing any prices is that the money received by XCom is not the whole sale amount, but just a small commission paid by the Council of Funding Nations, which actually controls the sales and takes (in exchange for its funding) most of the profits. [[User:Spike|Spike]] 19:40, 8 February 2010 (EST)
:::: FBLs are already pretty useless, and you want to nerf these further? I'd rather think of a way to make them more useful in-game, otherwise the profit should be kept (Note how it's the mostly useless craft weapons which are profitable - I suspect there was some thought into this..). In comparison, the Laser Cannon profit does get nerfed with XcomUtil, but we get a useful weapon instead. I'd suggest a modified FBL will have a very high elerium requirement, and the power of the weapon should be raised a bit to compensate. [[User:Cesium|Cesium]] 20:04, 8 February 2010 (EST)
::::: For example: Raise power to 240, and add another charge (almost enough to sink a battleship if a craft has two FBLs loaded), but make it cost 100 elerium to make launcher. Raise hours for Balls by factor of 10. [[User:Cesium|Cesium]] 20:16, 8 February 2010 (EST)
::: Actually you're right, it makes more sense to make FBLs viable, instead of (just) nerfing the profits. Obviously high Elerium requirements will make them non-profitable. But of the 2 problems - making things useful and preventing 'factory farming' - I think making things useful is more important. I didn't realise FBLs were not tactically useful. I've never built them, only Plasma Beams. 3 ammo is reasonable, it means that 2 FBL armed aircraft have a good chance to take down a Battleship, if they can fire 9-10 out of 12 fusion balls before they are both killed. But 100 Elerium is way too much for an improved FBL that's only slightly more powerful. I think my suggestion (4 Elerium, 20 Alloys, 10x hours, 10x space) fits with the requirements of other XComUtil-modified weapons. Combined with your suggestion of 3 ammo and 240 damage, I think it would make FBLs ''useful'' again, which is one of the original goals of XComUtil.
::: Of course, it's ''possible'' that Scott was cleverly making FBLs useful, by making them so much cheaper (net) to manufacture than Plasma Beams. In an XComUtil modified game, you might well deploy FBLs first, and only work your way up to Plasma Beams later, because of the huge manufacturing costs of Plasma Beams. But personally I think it was an oversight. [[User:Spike|Spike]] 17:21, 9 February 2010 (EST)
:::: I've never played with XcomUtil modified lasers, so if you say this fits in better that's fine with me. It's unfortunate it involves increasing space: inventory management is one of the things I hate about the first two X-Coms. I was hired to be a commander, not a supply clerk! A mod which made general stores have 10000 space (like Apoc) would be nice.. [[User:Cesium|Cesium]] 21:39, 9 February 2010 (EST)
:::: Actually the energy weapon mod means they uses more ''workshop'' space to build but not more inventory space to store.
::::However "An army marches on its stomach ", Napoleon said, by which he meant that wars are won or lost on logistics. Other famous commanders have said similar things. So a general should pay attention to logistics. One of the great things about XCOM is it's not just a tactical game, it's a combined political - strategic - operational - tactical game. [[User:Spike|Spike]] 04:37, 14 February 2010 (EST)
*Zrbite lying around in odd places. Objects lying around in odd places in general - these are map modifying errors, probably only occur when customising terrain etc.
:: Will be part of an overhaul of the BFG --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*There is a small problem in editing/customising craft using '''XComUtil.cfg'''. Certain X-Com craft weapon values - the rate of fire value - can't be set. Or more specifically, they can be set (patched) in the executable but it has no effect in the game. To avoid confusion they should perhaps be removed from the format of custom craft, or commented out. (This rate of fire patching ''might'' work on UFOs, haven't tested it).
:: Can you be more specific? --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: There is a section in '''xcomutil.cfg''' which is used for patching XCom craft weapon characteristics. This is where Scott changed values for the Laser Cannon, etc. Probably very few people use these fields. I only used them because I was doing research into the game mechanics. One of the values changed in this section is the reload time. These values are present in the executable, and can be patched, but patching them has no effect (other than to change the UFOPaedia entry). The reload time seems to be hard coded elsewhere in the executable, based (broadly) on the class of weapon. So you might want to comment this column with an a note saying "cannot be modified for combat". On the other hand I could be wrong, or someone still might want to modify these fields. Discussion is at [[Talk:UFO_Interception#Observed_Rates_of_Fire]]. Offsets are at [[Talk:GEOSCAPE.EXE#Craft_weapon_stats]]. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
:::: Or maybe change these display-only values so that they reflect the [[Talk:UFO_Interception#Observed_Rates_of_Fire|observed reload rates]]? I am not yet 100% sure I have got these right, might want to wait until I do some more confirmation tests. [[User:Spike|Spike]] 15:26, 22 February 2010 (EST)
*EQL only works on turn 1 (see discussion above)
::: Added to my to do list. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)

==Fixed Bugs==
*don't prevent patching windows version while running in dosbox, or vice versa
:*Fixed: XcuSetup can be run independantly to the OS RunXcom is used in.
*4DOS and MS-DOS 5 dont like "-" in variable names.
:*Fixed
*Enviroment space reached quickly on most DOS envirments.
:*Partly Fixed: Requirement has been drasticly reduced to to ~1024 use of Command.com /e:xxxx still may be required
*EnvClean.bat has an error in line 172: ser -> set.
:* Fixed in build 204.
*ANSI escape sequences aren't necessarily supported on a real dos environment/emulation
:*Fixed: ANSI only used in DOSBox
*If all the aliens are down (some of them stunned), the last save is named "AutoCombat" and I end turn, XcomUtil may still run "AutoCombat" phase. This may have slightly different results than end of combat would have had
:*Fixed: Autocombat will not run if you have already won.
*A fully loaded Hammerhead's initial deployment has three aquanauts outside the craft.
:*Fixed: the unit placement for the default 12 unit craft has been added to XcomUtil.cfg
*Select terrain: dosent apear untill after I select a terrain in BFG prompting
:*Fixed
*geodata/obdata.dat get's trunkated with slecting any improved weapon.
:*Fixed: This happend because a full backup did not complete but XcuSetup does not detect it. Backup script's changed to avoid xcopy timeout on some versions of DOS. (Backups are required by SDUMP to apply patches)
*I get this error dureing backup "16-bit MS-DOS Subsystem NTVDM has encountered a System Error The handle is invalid."
:*Fixed: All NT based OS's now useing 32bit EXE's
* You can get X-COM MIA if you abort a mission, even if everyone is in the exit. Possibly a second stage bug only? See [[Image:X-COM_MIA.zip]]. Note that this only affects the report - after mission all the X-COM troops are still available.
:*NOT Fixed: This happens even on vanilla TFTD with that save. Given it's TFTD it could be an issue with the mapfiles. --[[User:BladeFireLight|BladeFireLight]] 00:23, 24 February 2010 (EST)
:*Various second stage bugs - ammo clip recovery, crashes after autocombat of first stage, etc. Mainly for TFTD, but possibly Cydonia in UFO is also affected.
:*Fixed: Clip recoverty no longer ran between parts of 2-3 part missions. Autocombat only crashes on two part if you are aborting the second stage and the save in slot 10 is from the first stage. Stage comparisons are now done to abort autocmbat if you do this.
*Removal of Small Scout map / Survey Ship map, making it impossible to do these Battlescape missions.
:*Fixed: 9.7 only removes the maps if you use the BFG. I hope to have 9.8 not remove them at all. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*The XcuSetup prompt for the option of less-profitable weapons manufacturing is misleadingly called "new laser weapons".
:*Fixed: Renamed to Alternate Lasor weapons.
* SteamSetup.bat won't run from DOSBox. It says "This needs to be run from Windows". Though, does it make any sense to run SteamSetup.bat under DOSBox (eg for a linux system with no Steam)? [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
:*NOT Fixed: STEAM dosent give access by default to the command prompt. If you know how to add that then you should know enought of DOS not to need the STEAM menu. --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
* '''cfg/ShipDefU.txt''' has the XCU values for improved Laser Cannon (35/35/35), not the original values (21/35/70). Is this correct - is this file supposed to be the original defaults? [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)
:*Fixed: I was unawhare that this had been changed. The weapons are not prompted for any change so they should not be changed. I'm reseting them all to defaults and looking to see if Scott had anything about them in the notes. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
* standalone patches the fix the difficulty bug
:*Partialy Fixed: 9.7 min install is the dificulty patch and changeing Copy protection questions to all 0's.
*Version detection issues with obscure versions (Italian, 1.2a, etc.) causing corruption or lack of patching.
:*Fixed: Added support and patching offsets.
*Various default options make the game easier, not harder (''harder'' being the intent of XComUtil, right?). These should not be defaults. (More discussion at [[Talk:Enemy_Unknown_Extended#Standard_Config_Discussions]]) E.g.
::: 9.7 only has 3 items on by default. Remove copy protection. Fix Difficulty bug and Split EXE (split EXE can be skiped but not the others). All other options are default to NO.
::: As for the intent of XcomUtil. Scott added features to
:::# Increase difficulty.
:::# Make useless items useful.
:::# Get the game Started faster.
::: I have added:
:::# Don't make unwanted changes.
:::# Fix game bugs
:::::Yes all of those are very sensible. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
::::Latter versions of XcomUtil will turn the last two forced items to prompted. with only the Difficulty bug and the split EXE as Default=Yes. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Basic tanks using advanced tank stats
**Improved High Explosive - very powerful in favour of X-Com, especially as alien spawn points and routes aren't set up to cover holes in UFO hulls.
:*Gauss weapons have infinite ammo
::: 9.7 has a second option to just the increase power to closer match UFO.
:*Using fighters as transports (carrying soldiers)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Using transports as fighters (weapon hardpoints)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Improved Heavy Laser / Heavy Gauss. OK, this should maybe be a ''recommended'' option since the unpatched weapons are nearly pointless. But, it does make the game easier. [[User:Spike|Spike]] 20:12, 7 February 2010 (EST)

=XComUtil Wish List=
Things that are not bugs or inconsistencies in XComUtil but would be Nice To Have

== Features for 9.7 - Interface, consistency and bug fixes ==

=== Categorise Config Options ===

For each option, in the prompt, note which category of option this is, according your list above. E.g. faster start, making the game harder, making useless items useful, bug fix, variant game, etc. [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)

:Actually it might be even better to organise the options questions into sections, thematically grouped by these categories. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

:: Items are currently sorted like this.
* Windows EXE
* Game Fixes
* Game Mods
** Sound
** Craft
** Base
** Equipment
** Research
** Units
** Battlefield
** Alien Craft
** Misc
--[[User:BladeFireLight|BladeFireLight]] 19:25, 10 March 2010 (EST)

=== Improved Pistole Modification ===
*Remove 3rd burst for Pistol - it's already good enough, as NKF has shown
::: do you have a link to NKF's comments? --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:::: Having trouble finding his comments, maybe he'll show up here! See [[Rifle_vs_Pistol]], also [[Talk:Squad_Composition_and_Tactics#Starting_Sniper_Weapon]]. If anything there is a case for the Pistol to be nerfed slightly (eg Damage=20, Ammo=8), or for the Rifle to be buffed. Also worth looking through [[Weapon Analysis]] for general thoughts on weapon power and balance. The weapon set in EU is actually remarkably well balanced already.
::::: Further to this - not a bug but it's really wrong for a projectile weapon, a firearm, to have the same accuracy on Auto as on Snap fire (60). Even plasma weapons have Auto accuracy somewhat lower than Snap. If you reduce the Pistol burst mode accuracy by anything less than 2/3rds, the burst function is still useful, but more balanced. Actually even with a reduction of ''greater'' than 2/3rds, it would be useful, because of the increased damage at point blank range. Which is perhaps realistic for a burst-mode pistol. 60 Accuracy is higher than any Auto weapon in the game, for what ought to be the least accurate auto weapon. The best auto firearm is the Rifle at 35. Anything over 20 is still a bonus for the Pistol. How about 25? This still gives burst mode a 25% edge over Snap mode at long ranges, and a big improvement at close/point blank. 30 would make it more accurate than a Laser Pistol is on Auto (28), which is hard to justify. Admittedly the Pistol burst mode uses 3x (?) the TUs, so maybe some latitude can be given. Maybe go to 30 Accuracy, then, but no higher. [[User:Spike|Spike]] 19:49, 11 February 2010 (EST)
:::::: An interesting idea. Scott felt that this was just to make the pistol useful by allowing three snaps to be treated as one action so you dont deal with Reaction fire. The end results is the massive time units and same accuracy. If I lowered the accuracy I would have to lower the time to. I believe there is a reason the pistol doesn't have full auto in the vanilla game. You have seen a military issue full auto pistol? --[[User:BladeFireLight|BladeFireLight]] 21:15, 11 February 2010 (EST)
: Indent reset! I can't remember what my comments were either, but it's probably has to do with the weapon anaylsis and how useful snap shots already are. 'tis a jolly good weapon. I agree that you can't just make the auto mode identical to three snaps - you've got the added bonus of uninterrupted fire for the first two shots. You need to pay this off either with reduced accuracy or increase the usage cost.
: For consideration, I was actually fiddling with the weapons a few months back and was testing a 10% accuracy burst mode at 15% TU costs. I think 10 or 15 AP damage. Turned out way-way too powerful a weapon (against soft enemies) - and this was on a rookie I just picked randomly. It was probably too fast, but it still worked fairly well at 10% accuracy. 60% accuracy does feel quite high. -[[User:NKF|NKF]] 00:14, 12 February 2010 (EST)
:: Exactly. The point is that a 3-rd burst makes the Pistol more useful, ''even if the per-shot accuracy is lower'', because you get 3 attempts to kill the target before it Reaction Fires, rather than just one. As long as the ''net'' 3-rd accuracy isn't less than a single Snap shot, the weapon has been improved. The break-even point is about 26% accuracy on auto. At this level, 3 rounds have a ~60% chance of getting ''at least one'' hit. Even if the 3-rd accuracy was lower than a single Snap shot, you would still get the advantage of multiple hits at very close range. I would strongly suggest no more than 25% accuracy for Pistol auto burst, at the same level of TUs (3x Snap right?). This will definitely still be a significant improvement for the Pistol. Probably what was not fully understood at the time Scott did the original mod, is that the Pistol is arguably ''already'' the most effective starting weapon, certainly against the initial opponents. [[User:Spike|Spike]] 13:19, 12 February 2010 (EST)

=== Fusion weapons inconsistently exempted from Alternate Laser Tech ===
* Fusion weapons inconsistently exempted from the "more difficult" energy weapons manufacturing option ("alternate laser Tech"). Blaster Bombs and Blaster Launchers, Fusion hovertanks and ammo, and Fusion Balls and Fusion Ball Launchers - none of these are harder to build or use with the "alternate Tech" option. Why make laser weapons/tanks and plasma weapons/tanks harder but not Fusion weapons? It's not consistent. I wonder if Scott didn't look at these because he never used Blaster Launchers or Fusion Hovertanks, as he considered them to unbalancing already? And ignored FBLs because, well, most people ignore them? But this should be consistent. Or, the "harder weapons" option could be broken down into sub options, e.g. for each weapon technology:
** Much more expensive (typically: add some exotic materials, 10x workshop space and 10x Engineer hours)
** Can/can't manufacture the battlescape weapons/tanks (pure alien weapons only)
** Can/can't manufacture the ammo (pure alien weapons only)
:Personally I would prefer it to be all-or-nothing but include the Fusion weapons as being more difficult to make and use. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)

=== AutoCombat issues ===
* Day vs Night
** The Day/night algorithm breaks. For example, at any point when XCom has more than twice as many flare-carrying soldiers than there are remaining aliens, XCom is actually ''stronger'' in darkness than it would be in full daylight. Toward the end of a battle this is a very common situation. But fixing the algorithm is tricky. What might work is to give -10 for each Soldier in darkness, reduce from -20 to -10 for each Alien in darkness, then add back +10 for every soldier with a light source. Thus there is no way XCom can go 'net positive' from light sources.
:: If you have more units then they do you can see more of the battle field. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:::It never makes sense for XCom to be stronger at night, than during the day, for the same force ratio. But that is what happens. An example. 10 XCom soldiers with flares and 3 aliens. At night there is an extra -30 modifier for the aliens, but a +100 modifier for XCom, net +70. The same 10 soldiers against the same 3 aliens are +70 ''more'' effective in darkness than they would be in daylight. It does not make any sense. [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
** The definition of a light source should be expanded to include a Flare ''or'' an Incendiary weapon. In fact, one Incendiary-capable weapon of any type (AC/HC/HjC/GC), with appropriate Incendiary rounds carried, should be enough for the entire squad to be considered as having a light source. But this may be hard to implement without a special flag and a special pre-search for a valid Incendiary weapon, since AutoCombat normally scores by individual soldiers, not by whole squads.
:: This would take a rewrite. currently the ammo is not used by W: --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
** To be honest I would prefer that each soldier without a light source in darkness is 50% effective, each soldier with a light source (personal or squad), is 75% effective. Meanwhile how about this:

//Darkness
-10 L:-9 u:-2 // Human in Darkness

+10 L:-9 u:-2 W:-27 U:- // Human in Darkness w/Flare -OR-
+10 L:-9 u:-2 W:-4 W:-7 U:- // Human in Darkness w/In ammo and launcher HC/GC-IN -OR-
+10 L:-9 u:-2 W:-8 W:-11 U:- // Human in Darkness w/In ammo and launcher AC/HjC-IN -OR-
+10 L:-9 u:-2 W:-12 W:-15 U:- // Human in Darkness w/In ammo and launcher IN Rkt/Torp

-10 L:-9 u:4-14 // Alien in Darkness
:: Only thing I see is that this ''must'' come at the end. The U:- removes the unit from further consideration. --[[User:BladeFireLight|BladeFireLight]] 19:58, 9 March 2010 (EST)
::: Yes, to use the U: flag for this "OR" function, it must come at the end of the section for humans. That's how I have it my updated AutCombt.txt, these fragments are a bit out of context. It's not critical to have the "OR", it's just nice-to-have as it stops someone cheating by having a flare and one of each loaded incendiary launcher weapon in each hand and in their backpack, to get quadruple score. But hopefully people are unlikely to cheat at AutoCombat, there are easier ways such as the WIN flag. [[User:Spike|Spike]] 20:39, 9 March 2010 (EST)
* The Zombie is rated the same as a tank, a Chrysallid/Tentaculat or an effective Psi alien (-50). I think this is too high, as Zombies are much weaker than those units. A Zombie should be maybe -25.
: Disagree. the zombie should be slightly higher then a Chrysallid/Tentaculat as it will become one and you have to kill it twice. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:: OK good point! [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
* Area effect weapons (HE, IN, Small Launcher) should have at least the same bonus as effective-on-Auto weapons (+5). This is because they can damage/kill multiple targets. (The AC/HjC should not get both bonuses however.)

//Area Weapons. ToDo: compensating bonus for aliens. should not be cumulative. check if "effective?"
+5 u:-2 W:-4 W:-6 // Human w/HE ammo and launcher HC/GC-HE
+5 u:-2 W:-8 W:-10 // Human w/HE ammo and launcher AC/HjC-HE
+10 u:-2 W:-12 W:-13 // Human w/HE ammo and launcher Sm HE Rkt/Torp
+10 u:-2 W:-12 W:-13 // Human w/HE ammo and launcher Lg HE Rkt/Torp
+10 u:-2 W:-42 W:-43 // Human w/ Stun/Shok Launcher and ammo
+25 u:-2 W:-40 W:-41 // Human w/ Blaster/DP Launcher and ammo

-10 u:4-14 W:-42 W:-43 // Alien w/ Stun/Shok Launcher and ammo
-25 u:4-14 W:-40 W:-41 // Alien w/ Blaster/DP Launcher and ammo

::Having tested the first 2 rules, the first rule (HC-HE) does not work unless you remove the ammo specifier W:-6, making it just a test for an HC. But weirdly the second rule (AC-HE) works fine with its ammo specifier in place. Odd. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
::: The problem was due to [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Ammo loaded into a weapon by the game automatically prior to the equip phase is not caught by the W: function. When the ammo is loaded manually, both rules works fine. [[User:Spike|Spike]] 18:16, 13 March 2010 (EST)

* Pistols with the burst mode option should not count as Auto weapons (maybe they don't).
: Burst and snap are based on default stats --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
* Blaster Launchers / DPLs (with ammo) should be worth as much as a tank, e.g. +/- 50 (including the single shot effective bonus it should already get - see suggested rule above under area weapons)
* Should distinguish between tanks. Even with improved armour, a Tank/Cannon is not the same as a Fusion Hovertank. I would suggest a range of 25 for a Tank/Cannon to 75 for a Hovertank/Fusion. Maybe 40 for a Tank/Rocket, 50 for Tank/Laser, 60 for a Hovertank/Plasma?
:This does not seem to be possible with the existing ruleset as all Tanks are unit type 3
::Hmm, byte 42 of [[UNITREF.DAT]] is Rank but also Tank chassis. So this ''might'' allow distinguishing tracked tanks from hover tanks, at least. An alternative approach would be to pick some stat (that has a StatStrings statid) and set it to a different unique value for each tank type. [[User:Spike|Spike]] 18:32, 9 March 2010 (EST)
::This rule set might work:

// Tanks - distinguish chassis types.
+40 u:3-3 R:0-0 // Tank, Tracked (Cannon, Rocket, Laser)//To Test
+60 u:3-3 R:1-1 // Tank, Hover (Plasma, Fusion) //To Test

* Flying units (either side) should be worth say +/- 5
:Not possible for XCom as no statid makes a distinction between Power Suit and Flying Suit. Would be possible for aliens eg:

-5 T:0- u:6-6 // Flying Alien - Ethereal
-5 T:0- u:8-8 // Flying Alien - Floater
-5 T:1- u:13-13 // "Flying" Alien - Hallucinoid
-5 T:1- u:11-11 // "Flying" Alien - Tentaculat

* If the squad is carrying some Smoke or Dye that should be worth maybe +5 - +10. But since the aliens don't ever carry that, you need some balancing factor for them.

+1 u:-2 W:-20 // +1 per human with smoke grenade(s) (hopefully not +1 per grenade!)

* Effective melee weapons should be counted. This is particularly important in TFTD when ranged weapons may be ineffective, e.g. vs Lobstermen.
* Similarly if the enemy are in heavy armour and therefore a soldier/alien does not have an effective weapon, any HE Pack / Alien Grenade / Sonic Pulser should be counted for something (if it is "effective").

//Melee weapons
+5 u:-2 W:1- W:-26 // Human w/o effective ranged weapon but w/ Stun Rod
<s>+5 u:-2 W:3-26 // Human w/ effective Stun Rod (cumulative to above)</s>

::The second rule doesn't work at all, it looks like it counts all items of types 3-6. The "superiority" function (first value before the hyphen) does not seem to operate, probably because it is a melee weapon. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
::: did you try W:255-26 ? not that I know if it would work. AutoCombat doesn't recognize stun rods as weapons when applying damage.--[[User:BladeFireLight|BladeFireLight]] 21:01, 9 March 2010 (EST)
:::: OK, if AutoCombat rates stun rods as doing no damage, the lower range of the W: function ("superiority") will likely never work. So we can't tell whether or not a Stun Rod is "effective" vs the current enemy. In general, the Stun Rod is a pretty effective weapon. So instead we generalise and just use something like this rule set:

//Melee weapons
+5 u:-2 W:1- W:-26 // Human w/o effective ranged weapon but w/ Stun Rod
+5 u:-2 W:-26 // Human w/ effective Stun Rod (cumulative to above)

//It would be nice if AutoCombat checked for the presence of Stun Rods and used them to increase the chance of an alien casualty being stunned rather than killed.

//To Do: check if TFTD melee weapons are included in "effective" weapons by the W: statid.

//Grenades
+5 u:-2 W:1- W:-19 // Human w/o effective ranged weapon but w/ effective grenade(s)
+5 u:-2 W:1- W:-21 // Human w/o effective ranged weapon but w/ effective prox grenade(s)
+5 u:-2 W:1- W:-22 // Human w/o effective ranged weapon but w/ effective HE pack(s)
+5 u:-2 W:1- W:-44 // Human w/o effective ranged weapon but w/ effective Alien grenade(s)

-5 u:4-14 W:3-44 // -5 per Alien with effective Alien Grenade(s) (hope not -5 per grenade!)
:: Only one per unit. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)
::: Tested ok too! [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
* AutoCombat victories should award all UFO Components, not just some Navigation, Elerium and Alloys.
* Every Civilian on the map should be a penalty to XCom of maybe -5, due to the distraction effects of trying to save them / avoid killing them.

-5 u:15-16 U:- // Civilian distraction effect, no further effect

Let me know if I should try to work some of this up as AutoCombat rules. Some of it requires new coding of course, but a lot of it could probably be done with existing rules. [[User:Spike|Spike]] 13:15, 7 March 2010 (EST)
: I dont plan on any changing to the underlying code yet. Your welcome to make up a new set of rules and testing them out. --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
:: OK added some rules above. I have not tested them yet, some of the syntax might not work. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)
::: Syntax looks good to me. Give them a test and let me know how they go.
::: Just a quick note on how AutoCombat works. First the success percent chance is calculated using the AutoCombat StatStrings, dead and unconscious units dont count. (those that bleed to death are considers alive, need to fix this). If it's below AbortThreshold it aborts. If it's 100-199 then change to 90. 200+ change to 95 (success is never a guarantee.) Aliens roll d100, if over your success chance you lose. If You win. Then average damage by each side is calculated based on Loaded weapon being carried and time units. All aliens are killed or stunned by X-Com unit chosen at random. Each Alien gets a chance to wound an X-Com unit based on Success Percentage. Randomly choose unit using random damage (max is average alien damage) Leave at least one X-Com Unit alive. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)

== Features for 9.8+ - New features ==

=== TFTD Gause Tank Research Fix ===
*Have the option to make the Gauss Tank require only Gauss Cannon research - this can make it more distinct than the Sonic Displacer and maybe slightly useful for a while
:*I plan on it. just not this version. --[[User:BladeFireLight|BladeFireLight]] 20:53, 18 January 2010 (EST)

=== Improved Base Comes At Cost ===

The Improved Base is supposed to be a "faster start" option rather than a "make the game easier" option. But it does make the game easier, not least because it gives you a load of free base facility improvements. (Not to mention not having to struggle along the first month with only Small Radar and no Alien Containment) To partly avoid making the game easier, please add a sub-option that subtracts the cost of the extra facilities from your starting cash. This should be the ''full'' cost of the extra facilities, not just the difference between e.g. a Small Radar and a Large Radar.
[[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
: I dont have the offsets to the starting money ranges. so I cant do this. --[[User:BladeFireLight|BladeFireLight]] 19:13, 10 March 2010 (EST)
:: I never realised that the starting money is slightly random, I see ranges from $4,125,000 to $4,153,000, in ten samples. Does not seem to depend on Difficulty or starting base location. That is going to be a hard offset to find. [[User:Spike|Spike]] 20:36, 11 March 2010 (EST)
::: I believe there is no "starting money" anywhere to be found, or rather the starting money is effectively zero but it soon changes: the first thing the game does when you begin a new game is perform a hidden monthly report which grants you money from the funding nations. Only way to decrease it is to lower your rating toward countries (you should be able to hack the starting diplomacy data located at 0x4728F8). Or I could just patch the initial money to be negative instead of zero thus providing lower overall starting money. [[User:Seb76|Seb76]] 15:52, 12 March 2010 (EST)
:::: That makes a lot of sense. The initial money is the same as the initial funding. Doh! I should've realised that. The solution to poke a negative number into the money field, prior to the "hidden funding round", sounds a great idea.
:::: Looking at initial money vs funding, your initial cash is always $1,860,000 less than your initial funding. This $1.86M is probably made up of the first 3 rows (only) of your initial Monthly Costs: $500K transport rental, $1200K Interceptor rental, and $160K salary (not hiring fees) for 8 Soldiers. The salary (and hiring fees) for 10 Scientists and 10 Engineers are ignored. The Base Maintenance costs, $224K for a standard starting base, are also ignored. This generosity saves you at least $774K. Could this be considered a bug? Possibly.
:::: The cash value of the XComUtil Improved Base is a whopping $4.5M. This is $1.6M of facilities (Alien Containment, Large Radar, 2nd Living Quarters) and $2.9M of personnel (+10 Engineers, +40 Scientists). $4.5M would wipe out all starting cash and players would begin the game with a negative balance - quite challenging! For XComUtil, it might be best to break improved Facilities and Extra Starting Personnel into 2 options, with each having a sub-option to pay for the improvements. ''"These extra facilities/staff would cost $1.6M/$2.9M, do you want to deduct that amount from your starting cash?"'' [[User:Spike|Spike]] 20:48, 12 March 2010 (EST)

=== Easier Inventory Management ===
Inventory management is one of the things I hate about the first two X-Coms. I was hired to be a commander, not a supply clerk! A mod which made general stores have 10000 space (like Apoc) would be nice.. [[User:Cesium|Cesium]] 21:39, 9 February 2010 (EST)
: The manager of any facility has to deal with generalities of space issues. The clerk tells you if that fancy new tank you just bought will fit. He has to put it in storage and keep track of what shelf the ammo is on. --[[User:BladeFireLight|BladeFireLight]] 22:27, 9 February 2010 (EST)
:: That's the clerk's problem and if he complains too much I'll have him peel potatoes until his hands drop. In any event, the limit doesn't make any sense:
::* General stores size is 8x8x2 (8x8x3 in TFTD) per base defence map, and should have no problem storing more than 50 items.
::: The items taking up 1 item unit are typically about the size of humanoid body. I think it's not unreasonable to have no more than 50 of those in the area that the General Stores takes up.
:::: I can't find a list on the wiki of storage space requirements for items, so I'm not sure which items take up 1 item unit. Typically the main space wasters are Heavy Plasma ammo/Blaster Bombs/Stun Bombs (late game) and/or HWPs and avalanches (early game). These either are definitely not the size of a human body (ammo/Bombs), or shouldn't be stored in stores at all (HWPs gain nothing, and might as well lay around somewhere else in base).
::* The size of a fully built X-Com base is about the size of a city block (judging by comparison of base defence to terror missions), and should easily be able to hold hundreds of items even in the starting base if it's willing to put some stuff not in the general stores.
::* The space limit makes no sense. Why do Blaster Bombs and Heavy Plasma ammo take so much space whereas in the inventory view it doesn't take any more than normal ammo? Who stores <s>mini tanks</s> HWPs in the same compartment as light weapons? And the way X-Com (probably) stores ammo and explosives is scary...
::: As you suggest, extremely powerful ammunition probably requires a lot more space for safe and secure storage in-base, versus on a tactical mission. Imagine what would happen if a Blaster Bomb exploded in a base? Or was stolen? They probably use nuclear warhead style storage facilities for those. And similarly for Avalanche warheads, alien artifacts, Elerium, etc. Segregating dangerous/explosive items from other items probably uses up a lot of overhead in the construction of the storage space - think armoured, bomb-proof lockers and bulkheads, advanced security systems, airlocks, scanners, etc. This is not just like piling stuff up in your shed! And the Commander who left Elerium or Avalanche warheads lying around in his hanger or corridors would justifiably be sacked on the spot by XCom High Command. [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Well, judging by all the explosives in the hangar during base defence and the X-COM 1.0 Elerium bug, Elerium and explosive warheads ''are'' lying around in the base... And all the equipment in the General Stores is stored in ordinary lockers according to the General Stores map ;-) More to the point, if X-COM wants to store explosives safely (judging by said warheads X-COM doesn't care too much) they need a special facility for this, not to store them in the room which also contains all the base's weapons and priceless alien artifacts.

:::: Furthermore, I expect X-COM to improvise on storage in the interest of actually winning the war. X-COM does do this and ignore the limit when manufacturing stuff in-base or getting loot from missions. All that's needed is that X-COM will improvise for transfers too. I can't imagine a quartermaster informing the commander there isn't any room for the new armour and that the troops should go without. Maybe the reason X-COM doesn't pay quartermasters each month is that they keep getting themselves lynched by enraged X-COM troops...
::* Gameplay wise, inventory micromanagement is just no fun, especially in the late game when you have all the cash you need but still has to sell stuff after each combat (which can be prolonged if you haven't sold for awhile), otherwise you can't transfer items to the base where your main team is at.
::* Maybe this entire "stores" thing is a plot by the CFN to force X-Com to share its technology with them by forcing X-Com to sell sell sell. It's not like they pay X-Com the real worth of the technology anyway. [[User:Cesium|Cesium]] 23:47, 9 February 2010 (EST)
::: I think a lot of people do find the inventory management tedious, or unrealistically low. Personally I think it's about right for large equipment (missiles, tanks, bodies), but too low for small arms and personal equipment. And yes, it only reflects using the General Stores modules, not storing stuff at random points in the base - maybe fair enough. If the right offset to patch can be found, the storage limits could easily be raised. The last few bytes of [[BASE.DAT]] could be a good place to look for this offset. BASE.DAT can store up to 9,999 units of each item per base. The total limit for items per base would need to be found by experiment, but 9,999 might work for those who want to ignore inventory. For those who feel inventory management is OK but the limits set too tight, the capacity of each General Stores could be increased from 50 to 100 - assuming we can find the offset for this to patch it. [[User:Spike|Spike]] 19:50, 10 February 2010 (EST)
::::Maybe you can try there:
.text:00439C85 66 81 C5 F4 01 add bp, 500
::::[[User:Seb76|Seb76]] 13:03, 11 February 2010 (EST)
::::: Yes that works nicely. E.g. patch '''66 81 C5 E8 03''' at that location and you get 100 space per General Stores. Thanks Seb! [[User:Spike|Spike]] 18:21, 13 February 2010 (EST)
:::::: Now if only I had the offsets or search signature so we can add that as an options --[[User:BladeFireLight|BladeFireLight]] 18:24, 13 February 2010 (EST)
::::::: UFO 1.4 dos: offset 143748. TFTD 2.1 dos: offset 178462. TFTD v1 dos: offset 176861. TFTD CE: offset 252795. UFO CE: offset 236680. (all offsets are in decimal and point to the "F4 01" value to be patched).
::::::: Patching to "E8 03" has been tested on dos versions (not on CE) and it works. The "base information" screen will display the correct value, though the values to line length scale is such that the line will max at 250. [[User:Cesium|Cesium]] 05:57, 14 February 2010 (EST)
::::::::Are the preceding bytes the same from TFTD 1 and 2x? --[[User:BladeFireLight|BladeFireLight]] 17:26, 15 February 2010 (EST)
::::::::: Yes they are. '''81 C3 F4 01''' is the add instruction. [[User:Cesium|Cesium]] 17:48, 15 February 2010 (EST)
::::::::: Sig for UFO Dos is '''81 C6 F4 01''' --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
:::::::::: Do you also have the preceding bytes for UFO? with the signatures I can create a patch file for all versions --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
::::::::::: I am not sure I understand your question.. Judging the the two UFO versions I have available (1.3 per xcusetup and 1.4) the common preceding bytes are ''80 78 16 07 75 0C 80 78 3A 00 75 06'' (followed by the sig). You could try to use the sig alone - it exists only once in the file. [[User:Cesium|Cesium]] 19:35, 15 February 2010 (EST)
:::::::::::: Offset Locations are something I'm collecting but also the unique series of bytes to find them for the two geoscape/tactical that I dont have. (UFO Spanish, TFTD Italian) I hope to add a lot more options in the in the future. I do feel this one nerfs the storage system anything to get the game up and going faster is always a plus. --[[User:BladeFireLight|BladeFireLight]] 22:01, 15 February 2010 (EST)
::::::::::::: Well, you may want to add another General Stores to the improved starting base if you want to achieve the faster startup effect without "nerfing" storage system for rest of game (I prefer a "nerf" due to late-game reasons). Also, I suggest you add an message in Xcusetup to ask people to get in contact with you if they use an unknown/unrecognized version. [[User:Cesium|Cesium]] 14:27, 16 February 2010 (EST)
::: Inventory management is just as much a pain in the early game, where you almost always are out of space until your 2nd general stores is built. I like realistic constraints, but not tedium. Maybe upping the space per Stores from 50 units to 100 units would be a generally acceptable approach (now that Seb76 has kindly found the offset)? [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Yeah, that would be a great improvement. [[User:Cesium|Cesium]] 15:45, 13 February 2010 (EST)

:I can confirm Seb76 is correct, as ever. The 2 bytes at offsets '''0x39c88''' and '''0x39c89''' in geoscape.exe code for the capacity of each General Stores. Default value is 500 ('''F4 01''') which equates to 50 in-game internal capacity units. (Smallest item uses 0.1 in game capacity so I guess that is 1 unit in internal units). I am not sure about a signature. From what I can tell, the preceding bytes '''66 81 C5''' are unique in geoscape.exe, which seems pretty odd, so someone else should verify that. [[User:Spike|Spike]] 19:48, 13 February 2010 (EST)
:: Yes it is unique to CE. it does not exist in any DOS EXE, but "F4 01" can be found in 79 places. Trial and error could locate it. --[[User:BladeFireLight|BladeFireLight]] 20:50, 13 February 2010 (EST)

=== AutoCombat ===

==== Firepower Factors ====
You might want to consider replacing the weapon offensive weighting factors for Autocombat with some factors that are (inversely) related to the [[Weapon_Analysis#Quantitative_Analysis|% TUs Per Kill]]. I've tabulated these for each weapon (including tanks) vs each alien race. You would still need to account for Psi, light/darkness, and XCom armour. Plus you would need a similar offensive factor for the aliens' attacks. But I could probably help with that, I have the data that's directly comparable to the % TUs per Kill for XCom weapons. [[User:Spike|Spike]] 22:06, 12 February 2010 (EST)

==== AutoWithdrawal ====

One of the most tedious things you can try to do in XCom is to scavenge the battlefield and retreat to landing craft for an Abort. A great option would be an AutoWithdrawal, similar to an AutoCombat, but with an easier threshold of XCom vs Alien combat power.

Basically it would scavenge all loose equipment off the Battlescape - dropped friendly and alien items, friendly and alien corpses and wounded, all go back into the landing craft. Elerium, Alloys, and UFO Components would not be recovered, as this is (normally) impossible apart from full tactical victory. All friendly troops return to the landing craft. Friendly losses, and equipment recovered, would be proportional to the offensive factor ratios but much more favourable than for AutoCombat. E.g. as long as XCom factors were at least equal to Alien factors, they would be able to scavenge everything and recover without casualties. If the aliens were stronger than XCom, they would only recover part of the scavenged equipment, and risk partial casualties, at say one third the rate of AutoCombat. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

: It's too easy compared to actual game IMHO. Every time a battle went FUBAR for me, it got FUBAR all the way and I was lucky if I could salvage my own team/equipment and maybe a single alien weapon/body. An AutoWithdrawal without salvage might be useful, but perhaps instead we should change AutoCombat failure mode to work better (e.g. Make some X-COM people survive a failed AutoCombat, depending on strength vs aliens). [[User:Cesium|Cesium]] 15:00, 7 March 2010 (EST)

:: Yes fair point. I was not thinking of the FUBAR situations, and you are right about how hairy those are. I was thinking of the situation where you control a certain part of the battlefield, but you either don't want to go on an endless hunt for the last few aliens, or you pretty much know you can't take on the aliens that are left (e.g. in the UFO or some other stronghold) without getting creamed. You can exercise a safe withdrawal, it's just tedious to carry out all the bodies and equipment. But it's pretty hard for an AutoCombat algorithm to detect which of those situations it is - FUBAR, boredom, or tactical withdrawal. I'll have to think about that, there may be no realistic solution at all. And there is the existing "teleport loose items back to base" command line option to XComUtil, maybe that's enough. [[User:Spike|Spike]] 16:08, 7 March 2010 (EST)

=== Tougher UFOs ===

[[Wish_List_(EU)#Tougher_UFOs|Tougher UFOs]]
As this is entirely implemented by patching data and data files it is a good candidate for XComUtil rather than [[UFO Extender]].
: That would definitely make the game harder. 9.7 is about the installer and the bug fixes. This would be a good candidate for 9.8. --[[User:BladeFireLight|BladeFireLight]] 01:38, 19 February 2010 (EST)
:: Cool! [[User:Spike|Spike]] 02:25, 19 February 2010 (EST)

=== Rebalanced Craft Weapons ===

This fits under the "making useless things usefull" category. It would be a 9.8 or later option. The idea is to make the Cannon, Stingray, Laser Cannon and Fusion Ball Launcher useful. Hopefully it breaks up the monotony of Dual Avalanches followed by Dual Plasma Beams, every game.

There is one common element in the approach, and two options. The common element is to fix the stats on the Fusion Ball Launcher. The two options are to use a stat-based approach, or a cost-based approach, to fix the other weapons.

NB This proposal is still a draft and will need tweaking, but I've got it to the point where it is worth discussing. Feedback is welcome!

''(Ultimately, the Plasma Beam still ends up being pretty much the optimum weapon in the end game. To mitigate this, it is a good idea to select the existing Alternate Energy Weapons Manufacturing option in XComUtil.)''

==== Fusion Ball Launcher ====

Increase the ammo capacity from 2 to 3. Don't mess with the damage. Job done.

See [[User:Spike#Fusion_Ball_Launcher]] and discussions linked from there.

==== Cost Based Approach ====

This uses historically realistic costs to restore game balance between different craft weapons. The stand off advantage of Avalanche missiles is now purchased at a price which is significant in terms of XCom budgets and mission yields. Stingrays and Cannons become significantly cheaper alternatives. The Laser Cannon, with similar capabilities to Stingrays but free to operate, also becomes very attractive. Mounting dual launched weapons becomes a very expensive luxury.

*Increase Avalanche missile Purchase cost to $386,000
*Increase Stingray missile Purchase cost to $125,000
*Leave Sell prices unmodified (to avoid creating a cash reservoir at the start of the game)
*Leave Launcher buy/sell prices unmodified

See [[User:Spike#Cost_Based_Rebalancing]]

==== Stat Based Approach ====

This provides a benefit trade-off to shorter range weapons, by increasing their firepower or effectiveness relative to longer range weapons.

*Increase Cannon stats to 15 Damage, 50% hit. Firepower is tripled, slightly ahead of (unmodified) Avalanches launching in Aggressive mode. Increase rearming rate to 200.
*Increase Stingray accuracy to 80%. Decrease Avalanche accuracy to 60%. Stingray now has 50% more firepower relative to Avalanche. Increase Stingray rearming rate to 2, so a full craft can be re-armed in the same time period with either weapon (instead of twice as long for Stingray).
*Increase Laser Cannon stats to 100 Damage, 50% hit. Firepower is doubled, 20% more than (unmodified) Avalanches launching in Aggressive mode, 2/3rds of Plasma Beam firepower.

To avoid advanced XCom aircraft exploiting the extra firepower of the Cannon weapons and disregarding the return fire from UFOs, this is best used alongside the Tougher UFOs option.

See [[User:Spike#Stat_Based_Rebalancing]]

=== Rebalanced Infantry Weapons ===

See [[User:Spike#Balancing_Infantry_Weapons]]

Primarily this means making the Rifle a bit stronger, and probably making the Pistol a bit weaker.

==See Also==

[[Wish List]]

= Completed Wish List Items =

=== BFG Default To Unchanged ===

Is it possible when using the BattleFieldGenerator, for it to detect the actual conditions for the mission (terrain, enemy craft, and light level) and offer these as defaults? [[User:Spike|Spike]] 08:22, 13 February 2010 (EST)
:Press The esc key at the prompt. (Line 719 in Xcomutil.txt, not that I expect anyone to read the manual :) ) Enter should also work. --[[User:BladeFireLight|BladeFireLight]] 12:34, 13 February 2010 (EST)
:: RTFM eh? My biggest failing. Maybe you could add an explicit prompt "Esc or Enter = [whatever the unmodified value would be]". [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)
::: From what I can see, hitting Escape during BFG makes it continue with ''all'' values reverting to the original conditions. It would be nice to be able to select some but not all original conditions. My main use of this is to turn a night mission into a day mission without the hassle of keeping the landing craft hovering around until the terminator crosses the landing site. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
:::: You could just use the force all daylight option.
:::: After reviewing Scott's code. Esc leaves all setting as-is. Pressing enter or any other key not listed will randomly choose for you. I will see if I can change enter to leave as is. --[[User:BladeFireLight|BladeFireLight]] 11:00, 7 March 2010 (EST)
::::: This has been added --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)

= MISC =

* It's actually quite hard to downgrade to DOSBox 0.72 in Ubuntu. Only 0.73 is offered, there is no ability to Force back to a lower package level with Synaptic Package Manager. Unix guru skilz are required to rollback to 0.72, and I guess 0.74 is not around yet, or not packaged for Ubunut APT? Is there any way to fudge around this, e.g. by providing the command line arguments in an optional text file for xcusetup.bat to parse? Having said that, even with no command line arguments, xcusetup hangs on my 0.73 DOSBox while executing SDUMP. I had to reboot in Windows to run xcusetup.bat - something that is only possible on a dual boot machine / Wubi machine. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
** Try using a different batch interpreter like 4DOS [http://www.4dos.info] to execute xcusetup inside DosBox. I tested this throughly before under DosBox/Linux and it works well with recent 9.7 builds. I suggest running "config -set cpu core=dynamic" and "config -set cpu cycles=max" before xcusetup to speed it up (xcusetup doesn't detect DosBox when 4Dos is run, so it doesn't run these automatically unlike normal DosBox case). [[User:Cesium|Cesium]] 09:48, 7 March 2010 (EST)
** Oh, and downgrading isn't that difficult: Get a dosbox 0.72 deb, and run "dpkg -i" on it, and then do "echo dosbox hold | dpkg --set-selections" to prevent future upgrades. [[User:Cesium|Cesium]] 09:50, 7 March 2010 (EST)
** Another option is to install the dosemu package, and run xcusetup under that. EU/TFTD can be run under that, but it doesn't work as well there. (Oh, and there's no mount command there. UFO/TFTD needs to exist under ~/.dosemu/drive_c which is C:) [[User:Cesium|Cesium]] 11:42, 7 March 2010 (EST)

:Thanks Cesium I will check this out. I still think it would be good to have a solution that works for people who are not knowledgeable with the unix command line though. [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)

:: Why use Linux if you dont know how to use the console? It is a text mode OS with a separate GUI. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)

::: Well Ubuntu is a bit different, as it's supposed to be an OS for the general public, where you never need to touch text mode! Incidentally I can't find any DEB or other packages for 0.72, all that is available on the DOSBox website is the source code. They really don't seem to realise that 0.73 is buggy! So I guess I will need to '''make''' it. Or just wait for 0.74 as I think it's out soon. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)

:::: See [http://archive.ubuntu.com/ubuntu/pool/universe/d/dosbox/] for 0.72 debs. Unlike Windows, package systems in Unix land are centralized, so best location to search is typically a package server mirror or a distro mirror, not a vendor's website. [[User:Cesium|Cesium]] 17:36, 9 March 2010 (EST)

Talk:XcomUtil

2010-03-14T06:15:56Z

BladeFireLight: /* Easier Inventory Management */

=XcomUtil 9.7 Beta=

9.7 Beta is available on www.bladefirelight.com

==Release Notes==

This is a Beta, so backup your files before using. And check back often for newer builds.

New in this version.

*Major overhall of the installer (XcuSetup) and the inclusion of 16/32bit exe's to support both DOSBox and Windows Vista/7 x64.
*New subfolders added to hold supporting files making the install cleaner
*New XcuSetup command line arguments were added to XcuSetup allowing for silent install and uninstallation.
*New XcuSetup option for debugging the install (XcuSetup debug) creating XcomUtil\debug.txt.
*New command line argument "nobackup" skips backup only if it has been ran atleast once.
*XcuSetup can now have minimal impact on the game.
**Almost all options default to NO (Only Split Windows EXE set to Yes).
**Almost all changes are now prompted for (skyranger guns, interceptor as transport, Disjointed Base Bug, etc...).
***Items still done by default:
***Copy protection questions set to 0000000 for UFO 1.0-1.3 and X-Com 1.0
***Difficulty bug fixed in UFO 1.0-1.4 and X-Com 1.0-1.4
***Unique names for all maps in TFTD, Used for Hybrid Games
***Placement of X-Com Units on the Battlefield based on XcomUtil.cfg
***MIA Recovery on Won Combat (Units under mind\MC control when last controling alien killed are returned to X-Com control)
*XcomUtil.cfg is now pieced together and overwritten by XcuSetup (see XcomUtil\XcomUtil.txt for how to make permanent changes).
*All game files are restored to the pre-XcomUtil state each time XcuSetup is ran. Any modifications by other utilities will have to be re-applied.
*Vista/Win7 patch now an option for XcuSetup.
**This will fix the blank screen issue.
**Updated to support the split EXE.
**Will set X-Com to use CPU 0.
*XcuSetup attempts to fix UAC issues by resetting folder permissions.
*A number of community made fixes are included and selectable with XcuSetup.
*Support for the DOS/Window STEAM Install.
**Installer will detect STEAM and change steam launcher to start the XcomUtil Steam Menu (can be re-installed with XcomUtil\SteamSetup.bat
*Out of the box support for UFO Extender. XcuSetup will detect it and ask if you want RunXcom to use it.
*XcuSetup can be run from windows and RunXcom run from DosBox
*Hybrid Colors updated based on BombBloke's pallets.
*EQL flag allowed any turn.
*Add Xcom UFO Italian Support.
*Auto Combat will not run on second half of two part using first parts saved data.
*Auto Combat will no longer run if combat was won.
*MIA Recovery on won combat only.
*MIA Recovery no longer recovering units that bleed to death.
*Auto equip no longer triggers on second part of 2 stage missions.
*Combine clips skiped if between stages of 2-3 part missions.
*Updated f0dders ReadMe per his request. (XcomUtil\bugfix-readme.txt)
*Add-on support added. see XcomUtil\XcomUtil.txt and XcomUtil\Addon\Example.txt
*Prompted Terrain in BattleField Generator allows to abort or use of current setting.
*Beta versions include
**XcomUtil\XcomUtil.log includes lots of debug info
**XcomUtil\Debug.txt created by default (Release will need "debug" command argument)

Removed from this versions

*New Desert and Urban terrain. (Will be added once I have a C++ version of the Java Terrain Edit.)
*Expanded capacity Laviathan, Hammerhead and Avenger (maps avalible in XcomUtil\Patches)

NOTE: If you use DosBox, this requires DosBox 0.72 (Does not work on 0.73 due to buffer overflow setting ERRORLVEL)

===Build 435===

Original Sound Effects from UFO were re-sampled to work with 1.4 and CE.

*Add Category to option headers.
*Improve randomness by using current time instead of game date/time in srand()
*Added Option to keep Current terrain/UFO to BFG.
*Original UFO 1.2 Sounds for Geoscape and Tactical added as an option for UFO 1.4 and CE.
*Force Split EXE on STEAM. Fixes issues with setup failing.
*Reset Laser/Gauss craft weapons stats to be default.
*Example addon now uses different flag extension to avoid deletion by XcuSetup
*fix issue with Lab Screen on DosBox always screening

==Beta Disscusion==

===Build 435===
: I hope the improved randomness doesn't apply to the Aliens' d100 during AutoCombat. Otherwise, one could load-scum for success. [[User:Cesium|Cesium]] 06:33, 11 March 2010 (EST)
:: Actually it does. I can see what your getting at, but why do it that way. if you want to win the "WIN" command line option is faster and you get better loot from the UFO. also using the combat date would also swing the other way with an unwindable autocombat with an fully loaded avenger vs a survey ship. --[[User:BladeFireLight|BladeFireLight]] 17:41, 11 March 2010 (EST)
: In the setup question for sound files: "were replace" should be "were replaced". [[User:Cesium|Cesium]] 06:53, 11 March 2010 (EST)

Excellent! For the first time xcusetup.bat completed for me in Dosbox in Ubuntu. Previously the SDUMP commands were hanging it.

For the first time ever, I ran the sound setup utility. It did not response to any cursor keys, enter, tab, etc. The only key that worked was Escape, and I'm not sure what this did.

One point on the xcusetup.bat script - Ctrl C does not seem to work. On all those "press a key to continue" prompts could we also have "or 'q' to quit"?

[[User:Spike|Spike]] 18:41, 13 March 2010 (EST)

: "press a key to continue" is the Pause command. Ctrl + C works fine in Windows. DOSBox does not. The reason for the use of Pause is because an number of new players kept exiting setup early when I gave the option. Aborting early makes a mess and I dont want to have to troubleshoot it for Joe user. --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)

==Open Bugs==
*FreeDOS breaks horribly dering Setup
:*This is mostlikely an issue with the limits of FreeDOS.
*There's no Italian text for the Alternate Laser Weapons option. Applying the patch seems to work, but it displays the text for the default laser weapons.
:*Anyone want to translate the text into Italian? --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
*The number of aliens in the mission report is inconsistent with the number of live aliens captured per research help. See [[Image:Alien_numbers_mismatch.zip]] and [[Image:Dead_alien_count.zip]].
* Morale is random at start of second stage after autocombat of first stage?
:* Actually Morale is used as the clip size and time units as the weapon damage. Don't ask me why. It would take a major re-write of auto combat to fix this. --[[User:BladeFireLight|BladeFireLight]] 19:34, 23 February 2010 (EST)
* All Civilians are dead if AutoCombat is used to end a Terror mission. It's too not much of a problem, since score is likely to be positive anyway. It would possibly be an improvement to assume all civs from first stage are dead (if ran at second stage) and get a random number (using mission seed) for dead civs at current stage? [[User:Cesium|Cesium]] 07:00, 22 February 2010 (EST)
:* This is odd. Autocombat is supposed to skip over civilians when using the kill function. --[[User:BladeFireLight|BladeFireLight]] 00:18, 24 February 2010 (EST)
::*Maybe kill civilians (or not) according to the force ratios. If XCom has only enough force to win the mission, all Civilians are dead. If XCom bring a certain amount of "excessive force", all or nearly all Civilians are saved. By the way I love AutoCombat, it is great for avoiding repetitive combat and only playing the new, interesting bits. [[User:Spike|Spike]] 15:53, 22 February 2010 (EST)
:::* Thinking about this, I recalled the scenario where someone fights the mission and uses AutoCombat to hunt the last aliens (another reason AutoCombat is great). Spike's suggestion is better from pure RNG, since in this case probably all civs that were at risk already died. So lets see what we suggest XcomUtil do:
:::# Count civs from first stage if there was one as dead (since IIRC XcomUtil has no memory of first stage when exiting second stage, so we can't take them into account?).
:::# Deduct dead civs from current stage.
:::# Calculate extra dead civs using force ratio to bias the RNG (I prefer merely biasing the RNG rather than precluding results, since Xcom in general has a large variance in almost every gameplay mechanic). [[User:Cesium|Cesium]] 18:27, 22 February 2010 (EST)
*RPL bug, when you turn creatures into Gill Men, they are reported as Snakemen
:* Reported how? Is this consistent? The name's used are from xcomutil.cfg. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
::*Sorry. It's reported in morale failure pop up messages. Though maybe this is an original TFTD bug rather than an XComUtil bug. [[User:Spike|Spike]] 19:21, 21 February 2010 (EST)
:::* See this: [http://www.youtube.com/watch?v=uGlSghf7aTU]. In that case, all Gill man (were lobster man before RPL) were reported as snakemen.. [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST)
*RPL bug, when you turn Lobstermen into other creatures (e.g. Gill Men), they are very hard to kill despite having the stats of the creature they turned in to. Possibly they are keeping their damage resistance? Maybe the race is stored in more than one place, for different purposes, and XComUtil misses one of these places?
:: I will look into this --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: The RPL only changes the basics; The race, rank, name, TimeUnits, Health, Energy, Reactions, Armor(front,back,left,right), Strenght and PSI Strenght. All other stats are left as-is. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
:::: I'm not so sure about this. See 05:00 mark at [http://www.youtube.com/watch?v=y-_zLdjhUHI]. The armour doesn't match the one Gill man should have (per UFOpaedia, at least). [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST). See also 04:17 mark at [http://www.youtube.com/watch?v=z5LfzFSkRnI] for reason to suspect resistances aren't always changed. It's possible he just was unlucky though... [[User:Cesium|Cesium]] 19:53, 21 February 2010 (EST)
::::: Actually the function is something like this
<pre>#define UpdateStat(x,y) pur->x = (unsigned char) \
( ( (unsigned int)pur->x \
* (unsigned int)pasTo->y \
) / (unsigned int)pasFrom->y )
UpdateStat( TimeUnits0, TimeUnits );
UpdateStat( Health0, Health );
UpdateStat( Energy0, Energy );
UpdateStat( Reactions0, Reactions );
UpdateStat( AFront0, AFront2 );
UpdateStat( ALeft0, ALeft2 );
UpdateStat( ARight0, ARight2 );
UpdateStat( ARear0, ARear2 );
UpdateStat( AUnder0, AUnder2 );
UpdateStat( Strength, Strength );
UpdateStat( PsiStrength, PsiStrength );
</pre>
::::: the 0's are values at start of tactical.
::::: I read that as Current(from game_x) * Target default(from xcomutil.cfg) / source default (from Xcomutil.cfg) so the stats will be different. --[[User:BladeFireLight|BladeFireLight]] 21:33, 21 February 2010 (EST)
:::::: I'd have expected Current(game_x) == Source default if applied on first turn? This would end up with result == Target default, no? Hmmm... We already saw some compiler multiplication wackiness with the research help bug. Possibly this affected these calculations too?
:::::: As for the code, you're not updating PsiSkill, so non Psi-users can't get Psi after RPL. [[User:Cesium|Cesium]] 22:03, 21 February 2010 (EST)
::::::: I didn't write this. I'm amusing Scott did it this way to adjust for difficulty because XcomUtil.cfg has the beginner level stats. It need's an overhaul to use the full stat entries including the unknowns adjusted correctly for the level. Something for latter. --[[User:BladeFireLight|BladeFireLight]] 22:09, 21 February 2010 (EST)
:::::::: For this specific issue I think you will need to update 0x37 of [[UNITREF.DAT]] which is the Damage Modifier. In addition to the Psi Strength. Also Firing Accuracy, energy regen rate, movement class... loads of stuff. And of course LOFTEMPS. So with current RPL not changing LOFTEMPS, changed aliens are the wrong size and shape probably. This would be visible using the LOFTEMPS map viewer I suppose. [[User:Spike|Spike]] 18:39, 9 March 2010 (EST)
*[[Known Bugs#XComUtil Inventory Stacking Bug]]
:* I hope to overcome this but Scott's notes point to a technical limitation. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*Was it really intended to '''not''' have nerfed the [[Manufacturing_Profitability#XComUtil_manufacturing_profitability|Profitability]] of the Fusion Ball Launcher along with everything else? More generally, the profit nerfing could be revised to be more orderly and more systematic.
:: I dont really know what Scott intended as for the profiteering off of the changed items. If you want to suggest alternative values I'm open to discussion. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: A preliminary suggestion would be to make the Fusion Ball Launcher similarly difficult to manufacture as the Plasma Beam, so about ten times harder vs the unmodified game. E.g. Workshop space 6 -> 60, 400 -> 4000 Engineer hours. And perhaps require 4 Elerium and 20 Alloys, placing it midway between Laser Cannon and Plasma Beams. These changes (even without the materials) make the FBL unprofitable, like the (modified) Plasma Beam. I'm sure part of Scott's intent was to prevent "Laser Cannon Factories", but "FBL Factories" are 75% as profitable.
::: General reform of the profitability of manufacturing would require a lot of thought. Suffice to say I don't think '''any''' thought went into this for the original game. In reforming the economics of XCom, a basic problem is that realism is at odds with game balance. Realistically, governments would pay handsomely for almost anything XCom can produce. What would be reasonable is to get a moderate rate of return, rising more or less linear with investment (research effort), for ''all'' items. For game balance, this could be tweaked down for items that are useful in the game, or have research predecessors / successors that are useful in the game. A simpler case is to say that no item has negative profit, you can at least get 'cost price' back for it. Aircraft should arguably be in this category (since they would sell for 100s of millions which would be totally unbalancing). A rationalisation for nerfing any prices is that the money received by XCom is not the whole sale amount, but just a small commission paid by the Council of Funding Nations, which actually controls the sales and takes (in exchange for its funding) most of the profits. [[User:Spike|Spike]] 19:40, 8 February 2010 (EST)
:::: FBLs are already pretty useless, and you want to nerf these further? I'd rather think of a way to make them more useful in-game, otherwise the profit should be kept (Note how it's the mostly useless craft weapons which are profitable - I suspect there was some thought into this..). In comparison, the Laser Cannon profit does get nerfed with XcomUtil, but we get a useful weapon instead. I'd suggest a modified FBL will have a very high elerium requirement, and the power of the weapon should be raised a bit to compensate. [[User:Cesium|Cesium]] 20:04, 8 February 2010 (EST)
::::: For example: Raise power to 240, and add another charge (almost enough to sink a battleship if a craft has two FBLs loaded), but make it cost 100 elerium to make launcher. Raise hours for Balls by factor of 10. [[User:Cesium|Cesium]] 20:16, 8 February 2010 (EST)
::: Actually you're right, it makes more sense to make FBLs viable, instead of (just) nerfing the profits. Obviously high Elerium requirements will make them non-profitable. But of the 2 problems - making things useful and preventing 'factory farming' - I think making things useful is more important. I didn't realise FBLs were not tactically useful. I've never built them, only Plasma Beams. 3 ammo is reasonable, it means that 2 FBL armed aircraft have a good chance to take down a Battleship, if they can fire 9-10 out of 12 fusion balls before they are both killed. But 100 Elerium is way too much for an improved FBL that's only slightly more powerful. I think my suggestion (4 Elerium, 20 Alloys, 10x hours, 10x space) fits with the requirements of other XComUtil-modified weapons. Combined with your suggestion of 3 ammo and 240 damage, I think it would make FBLs ''useful'' again, which is one of the original goals of XComUtil.
::: Of course, it's ''possible'' that Scott was cleverly making FBLs useful, by making them so much cheaper (net) to manufacture than Plasma Beams. In an XComUtil modified game, you might well deploy FBLs first, and only work your way up to Plasma Beams later, because of the huge manufacturing costs of Plasma Beams. But personally I think it was an oversight. [[User:Spike|Spike]] 17:21, 9 February 2010 (EST)
:::: I've never played with XcomUtil modified lasers, so if you say this fits in better that's fine with me. It's unfortunate it involves increasing space: inventory management is one of the things I hate about the first two X-Coms. I was hired to be a commander, not a supply clerk! A mod which made general stores have 10000 space (like Apoc) would be nice.. [[User:Cesium|Cesium]] 21:39, 9 February 2010 (EST)
:::: Actually the energy weapon mod means they uses more ''workshop'' space to build but not more inventory space to store.
::::However "An army marches on its stomach ", Napoleon said, by which he meant that wars are won or lost on logistics. Other famous commanders have said similar things. So a general should pay attention to logistics. One of the great things about XCOM is it's not just a tactical game, it's a combined political - strategic - operational - tactical game. [[User:Spike|Spike]] 04:37, 14 February 2010 (EST)
*Zrbite lying around in odd places. Objects lying around in odd places in general - these are map modifying errors, probably only occur when customising terrain etc.
:: Will be part of an overhaul of the BFG --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*There is a small problem in editing/customising craft using '''XComUtil.cfg'''. Certain X-Com craft weapon values - the rate of fire value - can't be set. Or more specifically, they can be set (patched) in the executable but it has no effect in the game. To avoid confusion they should perhaps be removed from the format of custom craft, or commented out. (This rate of fire patching ''might'' work on UFOs, haven't tested it).
:: Can you be more specific? --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: There is a section in '''xcomutil.cfg''' which is used for patching XCom craft weapon characteristics. This is where Scott changed values for the Laser Cannon, etc. Probably very few people use these fields. I only used them because I was doing research into the game mechanics. One of the values changed in this section is the reload time. These values are present in the executable, and can be patched, but patching them has no effect (other than to change the UFOPaedia entry). The reload time seems to be hard coded elsewhere in the executable, based (broadly) on the class of weapon. So you might want to comment this column with an a note saying "cannot be modified for combat". On the other hand I could be wrong, or someone still might want to modify these fields. Discussion is at [[Talk:UFO_Interception#Observed_Rates_of_Fire]]. Offsets are at [[Talk:GEOSCAPE.EXE#Craft_weapon_stats]]. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
:::: Or maybe change these display-only values so that they reflect the [[Talk:UFO_Interception#Observed_Rates_of_Fire|observed reload rates]]? I am not yet 100% sure I have got these right, might want to wait until I do some more confirmation tests. [[User:Spike|Spike]] 15:26, 22 February 2010 (EST)
*EQL only works on turn 1 (see discussion above)
::: Added to my to do list. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)

==Fixed Bugs==
*don't prevent patching windows version while running in dosbox, or vice versa
:*Fixed: XcuSetup can be run independantly to the OS RunXcom is used in.
*4DOS and MS-DOS 5 dont like "-" in variable names.
:*Fixed
*Enviroment space reached quickly on most DOS envirments.
:*Partly Fixed: Requirement has been drasticly reduced to to ~1024 use of Command.com /e:xxxx still may be required
*EnvClean.bat has an error in line 172: ser -> set.
:* Fixed in build 204.
*ANSI escape sequences aren't necessarily supported on a real dos environment/emulation
:*Fixed: ANSI only used in DOSBox
*If all the aliens are down (some of them stunned), the last save is named "AutoCombat" and I end turn, XcomUtil may still run "AutoCombat" phase. This may have slightly different results than end of combat would have had
:*Fixed: Autocombat will not run if you have already won.
*A fully loaded Hammerhead's initial deployment has three aquanauts outside the craft.
:*Fixed: the unit placement for the default 12 unit craft has been added to XcomUtil.cfg
*Select terrain: dosent apear untill after I select a terrain in BFG prompting
:*Fixed
*geodata/obdata.dat get's trunkated with slecting any improved weapon.
:*Fixed: This happend because a full backup did not complete but XcuSetup does not detect it. Backup script's changed to avoid xcopy timeout on some versions of DOS. (Backups are required by SDUMP to apply patches)
*I get this error dureing backup "16-bit MS-DOS Subsystem NTVDM has encountered a System Error The handle is invalid."
:*Fixed: All NT based OS's now useing 32bit EXE's
* You can get X-COM MIA if you abort a mission, even if everyone is in the exit. Possibly a second stage bug only? See [[Image:X-COM_MIA.zip]]. Note that this only affects the report - after mission all the X-COM troops are still available.
:*NOT Fixed: This happens even on vanilla TFTD with that save. Given it's TFTD it could be an issue with the mapfiles. --[[User:BladeFireLight|BladeFireLight]] 00:23, 24 February 2010 (EST)
:*Various second stage bugs - ammo clip recovery, crashes after autocombat of first stage, etc. Mainly for TFTD, but possibly Cydonia in UFO is also affected.
:*Fixed: Clip recoverty no longer ran between parts of 2-3 part missions. Autocombat only crashes on two part if you are aborting the second stage and the save in slot 10 is from the first stage. Stage comparisons are now done to abort autocmbat if you do this.
*Removal of Small Scout map / Survey Ship map, making it impossible to do these Battlescape missions.
:*Fixed: 9.7 only removes the maps if you use the BFG. I hope to have 9.8 not remove them at all. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*The XcuSetup prompt for the option of less-profitable weapons manufacturing is misleadingly called "new laser weapons".
:*Fixed: Renamed to Alternate Lasor weapons.
* SteamSetup.bat won't run from DOSBox. It says "This needs to be run from Windows". Though, does it make any sense to run SteamSetup.bat under DOSBox (eg for a linux system with no Steam)? [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
:*NOT Fixed: STEAM dosent give access by default to the command prompt. If you know how to add that then you should know enought of DOS not to need the STEAM menu. --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
* '''cfg/ShipDefU.txt''' has the XCU values for improved Laser Cannon (35/35/35), not the original values (21/35/70). Is this correct - is this file supposed to be the original defaults? [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)
:*Fixed: I was unawhare that this had been changed. The weapons are not prompted for any change so they should not be changed. I'm reseting them all to defaults and looking to see if Scott had anything about them in the notes. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
* standalone patches the fix the difficulty bug
:*Partialy Fixed: 9.7 min install is the dificulty patch and changeing Copy protection questions to all 0's.
*Version detection issues with obscure versions (Italian, 1.2a, etc.) causing corruption or lack of patching.
:*Fixed: Added support and patching offsets.
*Various default options make the game easier, not harder (''harder'' being the intent of XComUtil, right?). These should not be defaults. (More discussion at [[Talk:Enemy_Unknown_Extended#Standard_Config_Discussions]]) E.g.
::: 9.7 only has 3 items on by default. Remove copy protection. Fix Difficulty bug and Split EXE (split EXE can be skiped but not the others). All other options are default to NO.
::: As for the intent of XcomUtil. Scott added features to
:::# Increase difficulty.
:::# Make useless items useful.
:::# Get the game Started faster.
::: I have added:
:::# Don't make unwanted changes.
:::# Fix game bugs
:::::Yes all of those are very sensible. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
::::Latter versions of XcomUtil will turn the last two forced items to prompted. with only the Difficulty bug and the split EXE as Default=Yes. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Basic tanks using advanced tank stats
**Improved High Explosive - very powerful in favour of X-Com, especially as alien spawn points and routes aren't set up to cover holes in UFO hulls.
:*Gauss weapons have infinite ammo
::: 9.7 has a second option to just the increase power to closer match UFO.
:*Using fighters as transports (carrying soldiers)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Using transports as fighters (weapon hardpoints)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Improved Heavy Laser / Heavy Gauss. OK, this should maybe be a ''recommended'' option since the unpatched weapons are nearly pointless. But, it does make the game easier. [[User:Spike|Spike]] 20:12, 7 February 2010 (EST)

=XComUtil Wish List=
Things that are not bugs or inconsistencies in XComUtil but would be Nice To Have

== Features for 9.7 - Interface, consistency and bug fixes ==

=== Categorise Config Options ===

For each option, in the prompt, note which category of option this is, according your list above. E.g. faster start, making the game harder, making useless items useful, bug fix, variant game, etc. [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)

:Actually it might be even better to organise the options questions into sections, thematically grouped by these categories. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

:: Items are currently sorted like this.
* Windows EXE
* Game Fixes
* Game Mods
** Sound
** Craft
** Base
** Equipment
** Research
** Units
** Battlefield
** Alien Craft
** Misc
--[[User:BladeFireLight|BladeFireLight]] 19:25, 10 March 2010 (EST)

=== Improved Pistole Modification ===
*Remove 3rd burst for Pistol - it's already good enough, as NKF has shown
::: do you have a link to NKF's comments? --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:::: Having trouble finding his comments, maybe he'll show up here! See [[Rifle_vs_Pistol]], also [[Talk:Squad_Composition_and_Tactics#Starting_Sniper_Weapon]]. If anything there is a case for the Pistol to be nerfed slightly (eg Damage=20, Ammo=8), or for the Rifle to be buffed. Also worth looking through [[Weapon Analysis]] for general thoughts on weapon power and balance. The weapon set in EU is actually remarkably well balanced already.
::::: Further to this - not a bug but it's really wrong for a projectile weapon, a firearm, to have the same accuracy on Auto as on Snap fire (60). Even plasma weapons have Auto accuracy somewhat lower than Snap. If you reduce the Pistol burst mode accuracy by anything less than 2/3rds, the burst function is still useful, but more balanced. Actually even with a reduction of ''greater'' than 2/3rds, it would be useful, because of the increased damage at point blank range. Which is perhaps realistic for a burst-mode pistol. 60 Accuracy is higher than any Auto weapon in the game, for what ought to be the least accurate auto weapon. The best auto firearm is the Rifle at 35. Anything over 20 is still a bonus for the Pistol. How about 25? This still gives burst mode a 25% edge over Snap mode at long ranges, and a big improvement at close/point blank. 30 would make it more accurate than a Laser Pistol is on Auto (28), which is hard to justify. Admittedly the Pistol burst mode uses 3x (?) the TUs, so maybe some latitude can be given. Maybe go to 30 Accuracy, then, but no higher. [[User:Spike|Spike]] 19:49, 11 February 2010 (EST)
:::::: An interesting idea. Scott felt that this was just to make the pistol useful by allowing three snaps to be treated as one action so you dont deal with Reaction fire. The end results is the massive time units and same accuracy. If I lowered the accuracy I would have to lower the time to. I believe there is a reason the pistol doesn't have full auto in the vanilla game. You have seen a military issue full auto pistol? --[[User:BladeFireLight|BladeFireLight]] 21:15, 11 February 2010 (EST)
: Indent reset! I can't remember what my comments were either, but it's probably has to do with the weapon anaylsis and how useful snap shots already are. 'tis a jolly good weapon. I agree that you can't just make the auto mode identical to three snaps - you've got the added bonus of uninterrupted fire for the first two shots. You need to pay this off either with reduced accuracy or increase the usage cost.
: For consideration, I was actually fiddling with the weapons a few months back and was testing a 10% accuracy burst mode at 15% TU costs. I think 10 or 15 AP damage. Turned out way-way too powerful a weapon (against soft enemies) - and this was on a rookie I just picked randomly. It was probably too fast, but it still worked fairly well at 10% accuracy. 60% accuracy does feel quite high. -[[User:NKF|NKF]] 00:14, 12 February 2010 (EST)
:: Exactly. The point is that a 3-rd burst makes the Pistol more useful, ''even if the per-shot accuracy is lower'', because you get 3 attempts to kill the target before it Reaction Fires, rather than just one. As long as the ''net'' 3-rd accuracy isn't less than a single Snap shot, the weapon has been improved. The break-even point is about 26% accuracy on auto. At this level, 3 rounds have a ~60% chance of getting ''at least one'' hit. Even if the 3-rd accuracy was lower than a single Snap shot, you would still get the advantage of multiple hits at very close range. I would strongly suggest no more than 25% accuracy for Pistol auto burst, at the same level of TUs (3x Snap right?). This will definitely still be a significant improvement for the Pistol. Probably what was not fully understood at the time Scott did the original mod, is that the Pistol is arguably ''already'' the most effective starting weapon, certainly against the initial opponents. [[User:Spike|Spike]] 13:19, 12 February 2010 (EST)

=== Fusion weapons inconsistently exempted from Alternate Laser Tech ===
* Fusion weapons inconsistently exempted from the "more difficult" energy weapons manufacturing option ("alternate laser Tech"). Blaster Bombs and Blaster Launchers, Fusion hovertanks and ammo, and Fusion Balls and Fusion Ball Launchers - none of these are harder to build or use with the "alternate Tech" option. Why make laser weapons/tanks and plasma weapons/tanks harder but not Fusion weapons? It's not consistent. I wonder if Scott didn't look at these because he never used Blaster Launchers or Fusion Hovertanks, as he considered them to unbalancing already? And ignored FBLs because, well, most people ignore them? But this should be consistent. Or, the "harder weapons" option could be broken down into sub options, e.g. for each weapon technology:
** Much more expensive (typically: add some exotic materials, 10x workshop space and 10x Engineer hours)
** Can/can't manufacture the battlescape weapons/tanks (pure alien weapons only)
** Can/can't manufacture the ammo (pure alien weapons only)
:Personally I would prefer it to be all-or-nothing but include the Fusion weapons as being more difficult to make and use. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)

=== AutoCombat issues ===
* Day vs Night
** The Day/night algorithm breaks. For example, at any point when XCom has more than twice as many flare-carrying soldiers than there are remaining aliens, XCom is actually ''stronger'' in darkness than it would be in full daylight. Toward the end of a battle this is a very common situation. But fixing the algorithm is tricky. What might work is to give -10 for each Soldier in darkness, reduce from -20 to -10 for each Alien in darkness, then add back +10 for every soldier with a light source. Thus there is no way XCom can go 'net positive' from light sources.
:: If you have more units then they do you can see more of the battle field. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:::It never makes sense for XCom to be stronger at night, than during the day, for the same force ratio. But that is what happens. An example. 10 XCom soldiers with flares and 3 aliens. At night there is an extra -30 modifier for the aliens, but a +100 modifier for XCom, net +70. The same 10 soldiers against the same 3 aliens are +70 ''more'' effective in darkness than they would be in daylight. It does not make any sense. [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
** The definition of a light source should be expanded to include a Flare ''or'' an Incendiary weapon. In fact, one Incendiary-capable weapon of any type (AC/HC/HjC/GC), with appropriate Incendiary rounds carried, should be enough for the entire squad to be considered as having a light source. But this may be hard to implement without a special flag and a special pre-search for a valid Incendiary weapon, since AutoCombat normally scores by individual soldiers, not by whole squads.
:: This would take a rewrite. currently the ammo is not used by W: --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
** To be honest I would prefer that each soldier without a light source in darkness is 50% effective, each soldier with a light source (personal or squad), is 75% effective. Meanwhile how about this:

//Darkness
-10 L:-9 u:-2 // Human in Darkness

+10 L:-9 u:-2 W:-27 U:- // Human in Darkness w/Flare -OR-
+10 L:-9 u:-2 W:-4 W:-7 U:- // Human in Darkness w/In ammo and launcher HC/GC-IN -OR-
+10 L:-9 u:-2 W:-8 W:-11 U:- // Human in Darkness w/In ammo and launcher AC/HjC-IN -OR-
+10 L:-9 u:-2 W:-12 W:-15 U:- // Human in Darkness w/In ammo and launcher IN Rkt/Torp

-10 L:-9 u:4-14 // Alien in Darkness
:: Only thing I see is that this ''must'' come at the end. The U:- removes the unit from further consideration. --[[User:BladeFireLight|BladeFireLight]] 19:58, 9 March 2010 (EST)
::: Yes, to use the U: flag for this "OR" function, it must come at the end of the section for humans. That's how I have it my updated AutCombt.txt, these fragments are a bit out of context. It's not critical to have the "OR", it's just nice-to-have as it stops someone cheating by having a flare and one of each loaded incendiary launcher weapon in each hand and in their backpack, to get quadruple score. But hopefully people are unlikely to cheat at AutoCombat, there are easier ways such as the WIN flag. [[User:Spike|Spike]] 20:39, 9 March 2010 (EST)
* The Zombie is rated the same as a tank, a Chrysallid/Tentaculat or an effective Psi alien (-50). I think this is too high, as Zombies are much weaker than those units. A Zombie should be maybe -25.
: Disagree. the zombie should be slightly higher then a Chrysallid/Tentaculat as it will become one and you have to kill it twice. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:: OK good point! [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
* Area effect weapons (HE, IN, Small Launcher) should have at least the same bonus as effective-on-Auto weapons (+5). This is because they can damage/kill multiple targets. (The AC/HjC should not get both bonuses however.)

//Area Weapons. ToDo: compensating bonus for aliens. should not be cumulative. check if "effective?"
+5 u:-2 W:-4 W:-6 // Human w/HE ammo and launcher HC/GC-HE
+5 u:-2 W:-8 W:-10 // Human w/HE ammo and launcher AC/HjC-HE
+10 u:-2 W:-12 W:-13 // Human w/HE ammo and launcher Sm HE Rkt/Torp
+10 u:-2 W:-12 W:-13 // Human w/HE ammo and launcher Lg HE Rkt/Torp
+10 u:-2 W:-42 W:-43 // Human w/ Stun/Shok Launcher and ammo
+25 u:-2 W:-40 W:-41 // Human w/ Blaster/DP Launcher and ammo

-10 u:4-14 W:-42 W:-43 // Alien w/ Stun/Shok Launcher and ammo
-25 u:4-14 W:-40 W:-41 // Alien w/ Blaster/DP Launcher and ammo

::Having tested the first 2 rules, the first rule (HC-HE) does not work unless you remove the ammo specifier W:-6, making it just a test for an HC. But weirdly the second rule (AC-HE) works fine with its ammo specifier in place. Odd. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
::: The problem was due to [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Ammo loaded into a weapon by the game automatically prior to the equip phase is not caught by the W: function. When the ammo is loaded manually, both rules works fine. [[User:Spike|Spike]] 18:16, 13 March 2010 (EST)

* Pistols with the burst mode option should not count as Auto weapons (maybe they don't).
: Burst and snap are based on default stats --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
* Blaster Launchers / DPLs (with ammo) should be worth as much as a tank, e.g. +/- 50 (including the single shot effective bonus it should already get - see suggested rule above under area weapons)
* Should distinguish between tanks. Even with improved armour, a Tank/Cannon is not the same as a Fusion Hovertank. I would suggest a range of 25 for a Tank/Cannon to 75 for a Hovertank/Fusion. Maybe 40 for a Tank/Rocket, 50 for Tank/Laser, 60 for a Hovertank/Plasma?
:This does not seem to be possible with the existing ruleset as all Tanks are unit type 3
::Hmm, byte 42 of [[UNITREF.DAT]] is Rank but also Tank chassis. So this ''might'' allow distinguishing tracked tanks from hover tanks, at least. An alternative approach would be to pick some stat (that has a StatStrings statid) and set it to a different unique value for each tank type. [[User:Spike|Spike]] 18:32, 9 March 2010 (EST)
::This rule set might work:

// Tanks - distinguish chassis types.
+40 u:3-3 R:0-0 // Tank, Tracked (Cannon, Rocket, Laser)//To Test
+60 u:3-3 R:1-1 // Tank, Hover (Plasma, Fusion) //To Test

* Flying units (either side) should be worth say +/- 5
:Not possible for XCom as no statid makes a distinction between Power Suit and Flying Suit. Would be possible for aliens eg:

-5 T:0- u:6-6 // Flying Alien - Ethereal
-5 T:0- u:8-8 // Flying Alien - Floater
-5 T:1- u:13-13 // "Flying" Alien - Hallucinoid
-5 T:1- u:11-11 // "Flying" Alien - Tentaculat

* If the squad is carrying some Smoke or Dye that should be worth maybe +5 - +10. But since the aliens don't ever carry that, you need some balancing factor for them.

+1 u:-2 W:-20 // +1 per human with smoke grenade(s) (hopefully not +1 per grenade!)

* Effective melee weapons should be counted. This is particularly important in TFTD when ranged weapons may be ineffective, e.g. vs Lobstermen.
* Similarly if the enemy are in heavy armour and therefore a soldier/alien does not have an effective weapon, any HE Pack / Alien Grenade / Sonic Pulser should be counted for something (if it is "effective").

//Melee weapons
+5 u:-2 W:1- W:-26 // Human w/o effective ranged weapon but w/ Stun Rod
<s>+5 u:-2 W:3-26 // Human w/ effective Stun Rod (cumulative to above)</s>

::The second rule doesn't work at all, it looks like it counts all items of types 3-6. The "superiority" function (first value before the hyphen) does not seem to operate, probably because it is a melee weapon. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
::: did you try W:255-26 ? not that I know if it would work. AutoCombat doesn't recognize stun rods as weapons when applying damage.--[[User:BladeFireLight|BladeFireLight]] 21:01, 9 March 2010 (EST)
:::: OK, if AutoCombat rates stun rods as doing no damage, the lower range of the W: function ("superiority") will likely never work. So we can't tell whether or not a Stun Rod is "effective" vs the current enemy. In general, the Stun Rod is a pretty effective weapon. So instead we generalise and just use something like this rule set:

//Melee weapons
+5 u:-2 W:1- W:-26 // Human w/o effective ranged weapon but w/ Stun Rod
+5 u:-2 W:-26 // Human w/ effective Stun Rod (cumulative to above)

//It would be nice if AutoCombat checked for the presence of Stun Rods and used them to increase the chance of an alien casualty being stunned rather than killed.

//To Do: check if TFTD melee weapons are included in "effective" weapons by the W: statid.

//Grenades
+5 u:-2 W:1- W:-19 // Human w/o effective ranged weapon but w/ effective grenade(s)
+5 u:-2 W:1- W:-21 // Human w/o effective ranged weapon but w/ effective prox grenade(s)
+5 u:-2 W:1- W:-22 // Human w/o effective ranged weapon but w/ effective HE pack(s)
+5 u:-2 W:1- W:-44 // Human w/o effective ranged weapon but w/ effective Alien grenade(s)

-5 u:4-14 W:3-44 // -5 per Alien with effective Alien Grenade(s) (hope not -5 per grenade!)
:: Only one per unit. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)
::: Tested ok too! [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
* AutoCombat victories should award all UFO Components, not just some Navigation, Elerium and Alloys.
* Every Civilian on the map should be a penalty to XCom of maybe -5, due to the distraction effects of trying to save them / avoid killing them.

-5 u:15-16 U:- // Civilian distraction effect, no further effect

Let me know if I should try to work some of this up as AutoCombat rules. Some of it requires new coding of course, but a lot of it could probably be done with existing rules. [[User:Spike|Spike]] 13:15, 7 March 2010 (EST)
: I dont plan on any changing to the underlying code yet. Your welcome to make up a new set of rules and testing them out. --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
:: OK added some rules above. I have not tested them yet, some of the syntax might not work. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)
::: Syntax looks good to me. Give them a test and let me know how they go.
::: Just a quick note on how AutoCombat works. First the success percent chance is calculated using the AutoCombat StatStrings, dead and unconscious units dont count. (those that bleed to death are considers alive, need to fix this). If it's below AbortThreshold it aborts. If it's 100-199 then change to 90. 200+ change to 95 (success is never a guarantee.) Aliens roll d100, if over your success chance you lose. If You win. Then average damage by each side is calculated based on Loaded weapon being carried and time units. All aliens are killed or stunned by X-Com unit chosen at random. Each Alien gets a chance to wound an X-Com unit based on Success Percentage. Randomly choose unit using random damage (max is average alien damage) Leave at least one X-Com Unit alive. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)

== Features for 9.8+ - New features ==

=== TFTD Gause Tank Research Fix ===
*Have the option to make the Gauss Tank require only Gauss Cannon research - this can make it more distinct than the Sonic Displacer and maybe slightly useful for a while
:*I plan on it. just not this version. --[[User:BladeFireLight|BladeFireLight]] 20:53, 18 January 2010 (EST)

=== Improved Base Comes At Cost ===

The Improved Base is supposed to be a "faster start" option rather than a "make the game easier" option. But it does make the game easier, not least because it gives you a load of free base facility improvements. (Not to mention not having to struggle along the first month with only Small Radar and no Alien Containment) To partly avoid making the game easier, please add a sub-option that subtracts the cost of the extra facilities from your starting cash. This should be the ''full'' cost of the extra facilities, not just the difference between e.g. a Small Radar and a Large Radar.
[[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
: I dont have the offsets to the starting money ranges. so I cant do this. --[[User:BladeFireLight|BladeFireLight]] 19:13, 10 March 2010 (EST)
:: I never realised that the starting money is slightly random, I see ranges from $4,125,000 to $4,153,000, in ten samples. Does not seem to depend on Difficulty or starting base location. That is going to be a hard offset to find. [[User:Spike|Spike]] 20:36, 11 March 2010 (EST)
::: I believe there is no "starting money" anywhere to be found, or rather the starting money is effectively zero but it soon changes: the first thing the game does when you begin a new game is perform a hidden monthly report which grants you money from the funding nations. Only way to decrease it is to lower your rating toward countries (you should be able to hack the starting diplomacy data located at 0x4728F8). Or I could just patch the initial money to be negative instead of zero thus providing lower overall starting money. [[User:Seb76|Seb76]] 15:52, 12 March 2010 (EST)
:::: That makes a lot of sense. The initial money is the same as the initial funding. Doh! I should've realised that. The solution to poke a negative number into the money field, prior to the "hidden funding round", sounds a great idea.
:::: Looking at initial money vs funding, your initial cash is always $1,860,000 less than your initial funding. This $1.86M is probably made up of the first 3 rows (only) of your initial Monthly Costs: $500K transport rental, $1200K Interceptor rental, and $160K salary (not hiring fees) for 8 Soldiers. The salary (and hiring fees) for 10 Scientists and 10 Engineers are ignored. The Base Maintenance costs, $224K for a standard starting base, are also ignored. This generosity saves you at least $774K. Could this be considered a bug? Possibly.
:::: The cash value of the XComUtil Improved Base is a whopping $4.5M. This is $1.6M of facilities (Alien Containment, Large Radar, 2nd Living Quarters) and $2.9M of personnel (+10 Engineers, +40 Scientists). $4.5M would wipe out all starting cash and players would begin the game with a negative balance - quite challenging! For XComUtil, it might be best to break improved Facilities and Extra Starting Personnel into 2 options, with each having a sub-option to pay for the improvements. ''"These extra facilities/staff would cost $1.6M/$2.9M, do you want to deduct that amount from your starting cash?"'' [[User:Spike|Spike]] 20:48, 12 March 2010 (EST)

=== Easier Inventory Management ===
Inventory management is one of the things I hate about the first two X-Coms. I was hired to be a commander, not a supply clerk! A mod which made general stores have 10000 space (like Apoc) would be nice.. [[User:Cesium|Cesium]] 21:39, 9 February 2010 (EST)
: The manager of any facility has to deal with generalities of space issues. The clerk tells you if that fancy new tank you just bought will fit. He has to put it in storage and keep track of what shelf the ammo is on. --[[User:BladeFireLight|BladeFireLight]] 22:27, 9 February 2010 (EST)
:: That's the clerk's problem and if he complains too much I'll have him peel potatoes until his hands drop. In any event, the limit doesn't make any sense:
::* General stores size is 8x8x2 (8x8x3 in TFTD) per base defence map, and should have no problem storing more than 50 items.
::: The items taking up 1 item unit are typically about the size of humanoid body. I think it's not unreasonable to have no more than 50 of those in the area that the General Stores takes up.
:::: I can't find a list on the wiki of storage space requirements for items, so I'm not sure which items take up 1 item unit. Typically the main space wasters are Heavy Plasma ammo/Blaster Bombs/Stun Bombs (late game) and/or HWPs and avalanches (early game). These either are definitely not the size of a human body (ammo/Bombs), or shouldn't be stored in stores at all (HWPs gain nothing, and might as well lay around somewhere else in base).
::* The size of a fully built X-Com base is about the size of a city block (judging by comparison of base defence to terror missions), and should easily be able to hold hundreds of items even in the starting base if it's willing to put some stuff not in the general stores.
::* The space limit makes no sense. Why do Blaster Bombs and Heavy Plasma ammo take so much space whereas in the inventory view it doesn't take any more than normal ammo? Who stores <s>mini tanks</s> HWPs in the same compartment as light weapons? And the way X-Com (probably) stores ammo and explosives is scary...
::: As you suggest, extremely powerful ammunition probably requires a lot more space for safe and secure storage in-base, versus on a tactical mission. Imagine what would happen if a Blaster Bomb exploded in a base? Or was stolen? They probably use nuclear warhead style storage facilities for those. And similarly for Avalanche warheads, alien artifacts, Elerium, etc. Segregating dangerous/explosive items from other items probably uses up a lot of overhead in the construction of the storage space - think armoured, bomb-proof lockers and bulkheads, advanced security systems, airlocks, scanners, etc. This is not just like piling stuff up in your shed! And the Commander who left Elerium or Avalanche warheads lying around in his hanger or corridors would justifiably be sacked on the spot by XCom High Command. [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Well, judging by all the explosives in the hangar during base defence and the X-COM 1.0 Elerium bug, Elerium and explosive warheads ''are'' lying around in the base... And all the equipment in the General Stores is stored in ordinary lockers according to the General Stores map ;-) More to the point, if X-COM wants to store explosives safely (judging by said warheads X-COM doesn't care too much) they need a special facility for this, not to store them in the room which also contains all the base's weapons and priceless alien artifacts.

:::: Furthermore, I expect X-COM to improvise on storage in the interest of actually winning the war. X-COM does do this and ignore the limit when manufacturing stuff in-base or getting loot from missions. All that's needed is that X-COM will improvise for transfers too. I can't imagine a quartermaster informing the commander there isn't any room for the new armour and that the troops should go without. Maybe the reason X-COM doesn't pay quartermasters each month is that they keep getting themselves lynched by enraged X-COM troops...
::* Gameplay wise, inventory micromanagement is just no fun, especially in the late game when you have all the cash you need but still has to sell stuff after each combat (which can be prolonged if you haven't sold for awhile), otherwise you can't transfer items to the base where your main team is at.
::* Maybe this entire "stores" thing is a plot by the CFN to force X-Com to share its technology with them by forcing X-Com to sell sell sell. It's not like they pay X-Com the real worth of the technology anyway. [[User:Cesium|Cesium]] 23:47, 9 February 2010 (EST)
::: I think a lot of people do find the inventory management tedious, or unrealistically low. Personally I think it's about right for large equipment (missiles, tanks, bodies), but too low for small arms and personal equipment. And yes, it only reflects using the General Stores modules, not storing stuff at random points in the base - maybe fair enough. If the right offset to patch can be found, the storage limits could easily be raised. The last few bytes of [[BASE.DAT]] could be a good place to look for this offset. BASE.DAT can store up to 9,999 units of each item per base. The total limit for items per base would need to be found by experiment, but 9,999 might work for those who want to ignore inventory. For those who feel inventory management is OK but the limits set too tight, the capacity of each General Stores could be increased from 50 to 100 - assuming we can find the offset for this to patch it. [[User:Spike|Spike]] 19:50, 10 February 2010 (EST)
::::Maybe you can try there:
.text:00439C85 66 81 C5 F4 01 add bp, 500
::::[[User:Seb76|Seb76]] 13:03, 11 February 2010 (EST)
::::: Yes that works nicely. E.g. patch '''66 81 C5 E8 03''' at that location and you get 100 space per General Stores. Thanks Seb! [[User:Spike|Spike]] 18:21, 13 February 2010 (EST)
:::::: Now if only I had the offsets or search signature so we can add that as an options --[[User:BladeFireLight|BladeFireLight]] 18:24, 13 February 2010 (EST)
::::::: UFO 1.4 dos: offset 143748. TFTD 2.1 dos: offset 178462. TFTD v1 dos: offset 176861. TFTD CE: offset 252795. UFO CE: offset 236680. (all offsets are in decimal and point to the "F4 01" value to be patched).
::::::: Patching to "E8 03" has been tested on dos versions (not on CE) and it works. The "base information" screen will display the correct value, though the values to line length scale is such that the line will max at 250. [[User:Cesium|Cesium]] 05:57, 14 February 2010 (EST)
::::::::Are the preceding bytes the same from TFTD 1 and 2x? --[[User:BladeFireLight|BladeFireLight]] 17:26, 15 February 2010 (EST)
::::::::: Yes they are. '''81 C3 F4 01''' is the add instruction. [[User:Cesium|Cesium]] 17:48, 15 February 2010 (EST)
::::::::: Sig for UFO Dos is '''81 C6 F4 01''' --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
:::::::::: Do you also have the preceding bytes for UFO? with the signatures I can create a patch file for all versions --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
::::::::::: I am not sure I understand your question.. Judging the the two UFO versions I have available (1.3 per xcusetup and 1.4) the common preceding bytes are ''80 78 16 07 75 0C 80 78 3A 00 75 06'' (followed by the sig). You could try to use the sig alone - it exists only once in the file. [[User:Cesium|Cesium]] 19:35, 15 February 2010 (EST)
:::::::::::: Offset Locations are something I'm collecting but also the unique series of bytes to find them for the two geoscape/tactical that I dont have. (UFO Spanish, TFTD Italian) I hope to add a lot more options in the in the future. I do feel this one nerfs the storage system anything to get the game up and going faster is always a plus. --[[User:BladeFireLight|BladeFireLight]] 22:01, 15 February 2010 (EST)
::::::::::::: Well, you may want to add another General Stores to the improved starting base if you want to achieve the faster startup effect without "nerfing" storage system for rest of game (I prefer a "nerf" due to late-game reasons). Also, I suggest you add an message in Xcusetup to ask people to get in contact with you if they use an unknown/unrecognized version. [[User:Cesium|Cesium]] 14:27, 16 February 2010 (EST)
::: Inventory management is just as much a pain in the early game, where you almost always are out of space until your 2nd general stores is built. I like realistic constraints, but not tedium. Maybe upping the space per Stores from 50 units to 100 units would be a generally acceptable approach (now that Seb76 has kindly found the offset)? [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Yeah, that would be a great improvement. [[User:Cesium|Cesium]] 15:45, 13 February 2010 (EST)

:I can confirm Seb76 is correct, as ever. The 2 bytes at offsets '''0x39c88''' and '''0x39c89''' in geoscape.exe code for the capacity of each General Stores. Default value is 500 ('''F4 01''') which equates to 50 in-game internal capacity units. (Smallest item uses 0.1 in game capacity so I guess that is 1 unit in internal units). I am not sure about a signature. From what I can tell, the preceding bytes '''66 81 C5''' are unique in geoscape.exe, which seems pretty odd, so someone else should verify that. [[User:Spike|Spike]] 19:48, 13 February 2010 (EST)
:: Yes it is unique to CE. it does not exist in any DOS EXE, but "F4 01" can be found in 79 places. Trial and error could locate it. --[[User:BladeFireLight|BladeFireLight]] 20:50, 13 February 2010 (EST)

=== AutoCombat ===

==== Firepower Factors ====
You might want to consider replacing the weapon offensive weighting factors for Autocombat with some factors that are (inversely) related to the [[Weapon_Analysis#Quantitative_Analysis|% TUs Per Kill]]. I've tabulated these for each weapon (including tanks) vs each alien race. You would still need to account for Psi, light/darkness, and XCom armour. Plus you would need a similar offensive factor for the aliens' attacks. But I could probably help with that, I have the data that's directly comparable to the % TUs per Kill for XCom weapons. [[User:Spike|Spike]] 22:06, 12 February 2010 (EST)

==== AutoWithdrawal ====

One of the most tedious things you can try to do in XCom is to scavenge the battlefield and retreat to landing craft for an Abort. A great option would be an AutoWithdrawal, similar to an AutoCombat, but with an easier threshold of XCom vs Alien combat power.

Basically it would scavenge all loose equipment off the Battlescape - dropped friendly and alien items, friendly and alien corpses and wounded, all go back into the landing craft. Elerium, Alloys, and UFO Components would not be recovered, as this is (normally) impossible apart from full tactical victory. All friendly troops return to the landing craft. Friendly losses, and equipment recovered, would be proportional to the offensive factor ratios but much more favourable than for AutoCombat. E.g. as long as XCom factors were at least equal to Alien factors, they would be able to scavenge everything and recover without casualties. If the aliens were stronger than XCom, they would only recover part of the scavenged equipment, and risk partial casualties, at say one third the rate of AutoCombat. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

: It's too easy compared to actual game IMHO. Every time a battle went FUBAR for me, it got FUBAR all the way and I was lucky if I could salvage my own team/equipment and maybe a single alien weapon/body. An AutoWithdrawal without salvage might be useful, but perhaps instead we should change AutoCombat failure mode to work better (e.g. Make some X-COM people survive a failed AutoCombat, depending on strength vs aliens). [[User:Cesium|Cesium]] 15:00, 7 March 2010 (EST)

:: Yes fair point. I was not thinking of the FUBAR situations, and you are right about how hairy those are. I was thinking of the situation where you control a certain part of the battlefield, but you either don't want to go on an endless hunt for the last few aliens, or you pretty much know you can't take on the aliens that are left (e.g. in the UFO or some other stronghold) without getting creamed. You can exercise a safe withdrawal, it's just tedious to carry out all the bodies and equipment. But it's pretty hard for an AutoCombat algorithm to detect which of those situations it is - FUBAR, boredom, or tactical withdrawal. I'll have to think about that, there may be no realistic solution at all. And there is the existing "teleport loose items back to base" command line option to XComUtil, maybe that's enough. [[User:Spike|Spike]] 16:08, 7 March 2010 (EST)

=== Tougher UFOs ===

[[Wish_List_(EU)#Tougher_UFOs|Tougher UFOs]]
As this is entirely implemented by patching data and data files it is a good candidate for XComUtil rather than [[UFO Extender]].
: That would definitely make the game harder. 9.7 is about the installer and the bug fixes. This would be a good candidate for 9.8. --[[User:BladeFireLight|BladeFireLight]] 01:38, 19 February 2010 (EST)
:: Cool! [[User:Spike|Spike]] 02:25, 19 February 2010 (EST)

=== Rebalanced Craft Weapons ===

This fits under the "making useless things usefull" category. It would be a 9.8 or later option. The idea is to make the Cannon, Stingray, Laser Cannon and Fusion Ball Launcher useful. Hopefully it breaks up the monotony of Dual Avalanches followed by Dual Plasma Beams, every game.

There is one common element in the approach, and two options. The common element is to fix the stats on the Fusion Ball Launcher. The two options are to use a stat-based approach, or a cost-based approach, to fix the other weapons.

NB This proposal is still a draft and will need tweaking, but I've got it to the point where it is worth discussing. Feedback is welcome!

''(Ultimately, the Plasma Beam still ends up being pretty much the optimum weapon in the end game. To mitigate this, it is a good idea to select the existing Alternate Energy Weapons Manufacturing option in XComUtil.)''

==== Fusion Ball Launcher ====

Increase the ammo capacity from 2 to 3. Don't mess with the damage. Job done.

See [[User:Spike#Fusion_Ball_Launcher]] and discussions linked from there.

==== Cost Based Approach ====

This uses historically realistic costs to restore game balance between different craft weapons. The stand off advantage of Avalanche missiles is now purchased at a price which is significant in terms of XCom budgets and mission yields. Stingrays and Cannons become significantly cheaper alternatives. The Laser Cannon, with similar capabilities to Stingrays but free to operate, also becomes very attractive. Mounting dual launched weapons becomes a very expensive luxury.

*Increase Avalanche missile Purchase cost to $386,000
*Increase Stingray missile Purchase cost to $125,000
*Leave Sell prices unmodified (to avoid creating a cash reservoir at the start of the game)
*Leave Launcher buy/sell prices unmodified

See [[User:Spike#Cost_Based_Rebalancing]]

==== Stat Based Approach ====

This provides a benefit trade-off to shorter range weapons, by increasing their firepower or effectiveness relative to longer range weapons.

*Increase Cannon stats to 15 Damage, 50% hit. Firepower is tripled, slightly ahead of (unmodified) Avalanches launching in Aggressive mode. Increase rearming rate to 200.
*Increase Stingray accuracy to 80%. Decrease Avalanche accuracy to 60%. Stingray now has 50% more firepower relative to Avalanche. Increase Stingray rearming rate to 2, so a full craft can be re-armed in the same time period with either weapon (instead of twice as long for Stingray).
*Increase Laser Cannon stats to 100 Damage, 50% hit. Firepower is doubled, 20% more than (unmodified) Avalanches launching in Aggressive mode, 2/3rds of Plasma Beam firepower.

To avoid advanced XCom aircraft exploiting the extra firepower of the Cannon weapons and disregarding the return fire from UFOs, this is best used alongside the Tougher UFOs option.

See [[User:Spike#Stat_Based_Rebalancing]]

=== Rebalanced Infantry Weapons ===

See [[User:Spike#Balancing_Infantry_Weapons]]

Primarily this means making the Rifle a bit stronger, and probably making the Pistol a bit weaker.

==See Also==

[[Wish List]]

= Completed Wish List Items =

=== BFG Default To Unchanged ===

Is it possible when using the BattleFieldGenerator, for it to detect the actual conditions for the mission (terrain, enemy craft, and light level) and offer these as defaults? [[User:Spike|Spike]] 08:22, 13 February 2010 (EST)
:Press The esc key at the prompt. (Line 719 in Xcomutil.txt, not that I expect anyone to read the manual :) ) Enter should also work. --[[User:BladeFireLight|BladeFireLight]] 12:34, 13 February 2010 (EST)
:: RTFM eh? My biggest failing. Maybe you could add an explicit prompt "Esc or Enter = [whatever the unmodified value would be]". [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)
::: From what I can see, hitting Escape during BFG makes it continue with ''all'' values reverting to the original conditions. It would be nice to be able to select some but not all original conditions. My main use of this is to turn a night mission into a day mission without the hassle of keeping the landing craft hovering around until the terminator crosses the landing site. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
:::: You could just use the force all daylight option.
:::: After reviewing Scott's code. Esc leaves all setting as-is. Pressing enter or any other key not listed will randomly choose for you. I will see if I can change enter to leave as is. --[[User:BladeFireLight|BladeFireLight]] 11:00, 7 March 2010 (EST)
::::: This has been added --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)

== MISC ==

* It's actually quite hard to downgrade to DOSBox 0.72 in Ubuntu. Only 0.73 is offered, there is no ability to Force back to a lower package level with Synaptic Package Manager. Unix guru skilz are required to rollback to 0.72, and I guess 0.74 is not around yet, or not packaged for Ubunut APT? Is there any way to fudge around this, e.g. by providing the command line arguments in an optional text file for xcusetup.bat to parse? Having said that, even with no command line arguments, xcusetup hangs on my 0.73 DOSBox while executing SDUMP. I had to reboot in Windows to run xcusetup.bat - something that is only possible on a dual boot machine / Wubi machine. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
** Try using a different batch interpreter like 4DOS [http://www.4dos.info] to execute xcusetup inside DosBox. I tested this throughly before under DosBox/Linux and it works well with recent 9.7 builds. I suggest running "config -set cpu core=dynamic" and "config -set cpu cycles=max" before xcusetup to speed it up (xcusetup doesn't detect DosBox when 4Dos is run, so it doesn't run these automatically unlike normal DosBox case). [[User:Cesium|Cesium]] 09:48, 7 March 2010 (EST)
** Oh, and downgrading isn't that difficult: Get a dosbox 0.72 deb, and run "dpkg -i" on it, and then do "echo dosbox hold | dpkg --set-selections" to prevent future upgrades. [[User:Cesium|Cesium]] 09:50, 7 March 2010 (EST)
** Another option is to install the dosemu package, and run xcusetup under that. EU/TFTD can be run under that, but it doesn't work as well there. (Oh, and there's no mount command there. UFO/TFTD needs to exist under ~/.dosemu/drive_c which is C:) [[User:Cesium|Cesium]] 11:42, 7 March 2010 (EST)

:Thanks Cesium I will check this out. I still think it would be good to have a solution that works for people who are not knowledgeable with the unix command line though. [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)

:: Why use Linux if you dont know how to use the console? It is a text mode OS with a separate GUI. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)

::: Well Ubuntu is a bit different, as it's supposed to be an OS for the general public, where you never need to touch text mode! Incidentally I can't find any DEB or other packages for 0.72, all that is available on the DOSBox website is the source code. They really don't seem to realise that 0.73 is buggy! So I guess I will need to '''make''' it. Or just wait for 0.74 as I think it's out soon. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)

:::: See [http://archive.ubuntu.com/ubuntu/pool/universe/d/dosbox/] for 0.72 debs. Unlike Windows, package systems in Unix land are centralized, so best location to search is typically a package server mirror or a distro mirror, not a vendor's website. [[User:Cesium|Cesium]] 17:36, 9 March 2010 (EST)

Talk:XcomUtil

2010-03-14T06:15:11Z

BladeFireLight: Rearage content and clenup the page of outdated info.

=XcomUtil 9.7 Beta=

9.7 Beta is available on www.bladefirelight.com

==Release Notes==

This is a Beta, so backup your files before using. And check back often for newer builds.

New in this version.

*Major overhall of the installer (XcuSetup) and the inclusion of 16/32bit exe's to support both DOSBox and Windows Vista/7 x64.
*New subfolders added to hold supporting files making the install cleaner
*New XcuSetup command line arguments were added to XcuSetup allowing for silent install and uninstallation.
*New XcuSetup option for debugging the install (XcuSetup debug) creating XcomUtil\debug.txt.
*New command line argument "nobackup" skips backup only if it has been ran atleast once.
*XcuSetup can now have minimal impact on the game.
**Almost all options default to NO (Only Split Windows EXE set to Yes).
**Almost all changes are now prompted for (skyranger guns, interceptor as transport, Disjointed Base Bug, etc...).
***Items still done by default:
***Copy protection questions set to 0000000 for UFO 1.0-1.3 and X-Com 1.0
***Difficulty bug fixed in UFO 1.0-1.4 and X-Com 1.0-1.4
***Unique names for all maps in TFTD, Used for Hybrid Games
***Placement of X-Com Units on the Battlefield based on XcomUtil.cfg
***MIA Recovery on Won Combat (Units under mind\MC control when last controling alien killed are returned to X-Com control)
*XcomUtil.cfg is now pieced together and overwritten by XcuSetup (see XcomUtil\XcomUtil.txt for how to make permanent changes).
*All game files are restored to the pre-XcomUtil state each time XcuSetup is ran. Any modifications by other utilities will have to be re-applied.
*Vista/Win7 patch now an option for XcuSetup.
**This will fix the blank screen issue.
**Updated to support the split EXE.
**Will set X-Com to use CPU 0.
*XcuSetup attempts to fix UAC issues by resetting folder permissions.
*A number of community made fixes are included and selectable with XcuSetup.
*Support for the DOS/Window STEAM Install.
**Installer will detect STEAM and change steam launcher to start the XcomUtil Steam Menu (can be re-installed with XcomUtil\SteamSetup.bat
*Out of the box support for UFO Extender. XcuSetup will detect it and ask if you want RunXcom to use it.
*XcuSetup can be run from windows and RunXcom run from DosBox
*Hybrid Colors updated based on BombBloke's pallets.
*EQL flag allowed any turn.
*Add Xcom UFO Italian Support.
*Auto Combat will not run on second half of two part using first parts saved data.
*Auto Combat will no longer run if combat was won.
*MIA Recovery on won combat only.
*MIA Recovery no longer recovering units that bleed to death.
*Auto equip no longer triggers on second part of 2 stage missions.
*Combine clips skiped if between stages of 2-3 part missions.
*Updated f0dders ReadMe per his request. (XcomUtil\bugfix-readme.txt)
*Add-on support added. see XcomUtil\XcomUtil.txt and XcomUtil\Addon\Example.txt
*Prompted Terrain in BattleField Generator allows to abort or use of current setting.
*Beta versions include
**XcomUtil\XcomUtil.log includes lots of debug info
**XcomUtil\Debug.txt created by default (Release will need "debug" command argument)

Removed from this versions

*New Desert and Urban terrain. (Will be added once I have a C++ version of the Java Terrain Edit.)
*Expanded capacity Laviathan, Hammerhead and Avenger (maps avalible in XcomUtil\Patches)

NOTE: If you use DosBox, this requires DosBox 0.72 (Does not work on 0.73 due to buffer overflow setting ERRORLVEL)

===Build 435===

Original Sound Effects from UFO were re-sampled to work with 1.4 and CE.

*Add Category to option headers.
*Improve randomness by using current time instead of game date/time in srand()
*Added Option to keep Current terrain/UFO to BFG.
*Original UFO 1.2 Sounds for Geoscape and Tactical added as an option for UFO 1.4 and CE.
*Force Split EXE on STEAM. Fixes issues with setup failing.
*Reset Laser/Gauss craft weapons stats to be default.
*Example addon now uses different flag extension to avoid deletion by XcuSetup
*fix issue with Lab Screen on DosBox always screening

==Beta Disscusion==

===Build 435===
: I hope the improved randomness doesn't apply to the Aliens' d100 during AutoCombat. Otherwise, one could load-scum for success. [[User:Cesium|Cesium]] 06:33, 11 March 2010 (EST)
:: Actually it does. I can see what your getting at, but why do it that way. if you want to win the "WIN" command line option is faster and you get better loot from the UFO. also using the combat date would also swing the other way with an unwindable autocombat with an fully loaded avenger vs a survey ship. --[[User:BladeFireLight|BladeFireLight]] 17:41, 11 March 2010 (EST)
: In the setup question for sound files: "were replace" should be "were replaced". [[User:Cesium|Cesium]] 06:53, 11 March 2010 (EST)

Excellent! For the first time xcusetup.bat completed for me in Dosbox in Ubuntu. Previously the SDUMP commands were hanging it.

For the first time ever, I ran the sound setup utility. It did not response to any cursor keys, enter, tab, etc. The only key that worked was Escape, and I'm not sure what this did.

One point on the xcusetup.bat script - Ctrl C does not seem to work. On all those "press a key to continue" prompts could we also have "or 'q' to quit"?

[[User:Spike|Spike]] 18:41, 13 March 2010 (EST)

: "press a key to continue" is the Pause command. Ctrl + C works fine in Windows. DOSBox does not. The reason for the use of Pause is because an number of new players kept exiting setup early when I gave the option. Aborting early makes a mess and I dont want to have to troubleshoot it for Joe user. --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)

==Open Bugs==
*FreeDOS breaks horribly dering Setup
:*This is mostlikely an issue with the limits of FreeDOS.
*There's no Italian text for the Alternate Laser Weapons option. Applying the patch seems to work, but it displays the text for the default laser weapons.
:*Anyone want to translate the text into Italian? --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
*The number of aliens in the mission report is inconsistent with the number of live aliens captured per research help. See [[Image:Alien_numbers_mismatch.zip]] and [[Image:Dead_alien_count.zip]].
* Morale is random at start of second stage after autocombat of first stage?
:* Actually Morale is used as the clip size and time units as the weapon damage. Don't ask me why. It would take a major re-write of auto combat to fix this. --[[User:BladeFireLight|BladeFireLight]] 19:34, 23 February 2010 (EST)
* All Civilians are dead if AutoCombat is used to end a Terror mission. It's too not much of a problem, since score is likely to be positive anyway. It would possibly be an improvement to assume all civs from first stage are dead (if ran at second stage) and get a random number (using mission seed) for dead civs at current stage? [[User:Cesium|Cesium]] 07:00, 22 February 2010 (EST)
:* This is odd. Autocombat is supposed to skip over civilians when using the kill function. --[[User:BladeFireLight|BladeFireLight]] 00:18, 24 February 2010 (EST)
::*Maybe kill civilians (or not) according to the force ratios. If XCom has only enough force to win the mission, all Civilians are dead. If XCom bring a certain amount of "excessive force", all or nearly all Civilians are saved. By the way I love AutoCombat, it is great for avoiding repetitive combat and only playing the new, interesting bits. [[User:Spike|Spike]] 15:53, 22 February 2010 (EST)
:::* Thinking about this, I recalled the scenario where someone fights the mission and uses AutoCombat to hunt the last aliens (another reason AutoCombat is great). Spike's suggestion is better from pure RNG, since in this case probably all civs that were at risk already died. So lets see what we suggest XcomUtil do:
:::# Count civs from first stage if there was one as dead (since IIRC XcomUtil has no memory of first stage when exiting second stage, so we can't take them into account?).
:::# Deduct dead civs from current stage.
:::# Calculate extra dead civs using force ratio to bias the RNG (I prefer merely biasing the RNG rather than precluding results, since Xcom in general has a large variance in almost every gameplay mechanic). [[User:Cesium|Cesium]] 18:27, 22 February 2010 (EST)
*RPL bug, when you turn creatures into Gill Men, they are reported as Snakemen
:* Reported how? Is this consistent? The name's used are from xcomutil.cfg. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
::*Sorry. It's reported in morale failure pop up messages. Though maybe this is an original TFTD bug rather than an XComUtil bug. [[User:Spike|Spike]] 19:21, 21 February 2010 (EST)
:::* See this: [http://www.youtube.com/watch?v=uGlSghf7aTU]. In that case, all Gill man (were lobster man before RPL) were reported as snakemen.. [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST)
*RPL bug, when you turn Lobstermen into other creatures (e.g. Gill Men), they are very hard to kill despite having the stats of the creature they turned in to. Possibly they are keeping their damage resistance? Maybe the race is stored in more than one place, for different purposes, and XComUtil misses one of these places?
:: I will look into this --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: The RPL only changes the basics; The race, rank, name, TimeUnits, Health, Energy, Reactions, Armor(front,back,left,right), Strenght and PSI Strenght. All other stats are left as-is. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
:::: I'm not so sure about this. See 05:00 mark at [http://www.youtube.com/watch?v=y-_zLdjhUHI]. The armour doesn't match the one Gill man should have (per UFOpaedia, at least). [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST). See also 04:17 mark at [http://www.youtube.com/watch?v=z5LfzFSkRnI] for reason to suspect resistances aren't always changed. It's possible he just was unlucky though... [[User:Cesium|Cesium]] 19:53, 21 February 2010 (EST)
::::: Actually the function is something like this
<pre>#define UpdateStat(x,y) pur->x = (unsigned char) \
( ( (unsigned int)pur->x \
* (unsigned int)pasTo->y \
) / (unsigned int)pasFrom->y )
UpdateStat( TimeUnits0, TimeUnits );
UpdateStat( Health0, Health );
UpdateStat( Energy0, Energy );
UpdateStat( Reactions0, Reactions );
UpdateStat( AFront0, AFront2 );
UpdateStat( ALeft0, ALeft2 );
UpdateStat( ARight0, ARight2 );
UpdateStat( ARear0, ARear2 );
UpdateStat( AUnder0, AUnder2 );
UpdateStat( Strength, Strength );
UpdateStat( PsiStrength, PsiStrength );
</pre>
::::: the 0's are values at start of tactical.
::::: I read that as Current(from game_x) * Target default(from xcomutil.cfg) / source default (from Xcomutil.cfg) so the stats will be different. --[[User:BladeFireLight|BladeFireLight]] 21:33, 21 February 2010 (EST)
:::::: I'd have expected Current(game_x) == Source default if applied on first turn? This would end up with result == Target default, no? Hmmm... We already saw some compiler multiplication wackiness with the research help bug. Possibly this affected these calculations too?
:::::: As for the code, you're not updating PsiSkill, so non Psi-users can't get Psi after RPL. [[User:Cesium|Cesium]] 22:03, 21 February 2010 (EST)
::::::: I didn't write this. I'm amusing Scott did it this way to adjust for difficulty because XcomUtil.cfg has the beginner level stats. It need's an overhaul to use the full stat entries including the unknowns adjusted correctly for the level. Something for latter. --[[User:BladeFireLight|BladeFireLight]] 22:09, 21 February 2010 (EST)
:::::::: For this specific issue I think you will need to update 0x37 of [[UNITREF.DAT]] which is the Damage Modifier. In addition to the Psi Strength. Also Firing Accuracy, energy regen rate, movement class... loads of stuff. And of course LOFTEMPS. So with current RPL not changing LOFTEMPS, changed aliens are the wrong size and shape probably. This would be visible using the LOFTEMPS map viewer I suppose. [[User:Spike|Spike]] 18:39, 9 March 2010 (EST)
*[[Known Bugs#XComUtil Inventory Stacking Bug]]
:* I hope to overcome this but Scott's notes point to a technical limitation. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*Was it really intended to '''not''' have nerfed the [[Manufacturing_Profitability#XComUtil_manufacturing_profitability|Profitability]] of the Fusion Ball Launcher along with everything else? More generally, the profit nerfing could be revised to be more orderly and more systematic.
:: I dont really know what Scott intended as for the profiteering off of the changed items. If you want to suggest alternative values I'm open to discussion. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: A preliminary suggestion would be to make the Fusion Ball Launcher similarly difficult to manufacture as the Plasma Beam, so about ten times harder vs the unmodified game. E.g. Workshop space 6 -> 60, 400 -> 4000 Engineer hours. And perhaps require 4 Elerium and 20 Alloys, placing it midway between Laser Cannon and Plasma Beams. These changes (even without the materials) make the FBL unprofitable, like the (modified) Plasma Beam. I'm sure part of Scott's intent was to prevent "Laser Cannon Factories", but "FBL Factories" are 75% as profitable.
::: General reform of the profitability of manufacturing would require a lot of thought. Suffice to say I don't think '''any''' thought went into this for the original game. In reforming the economics of XCom, a basic problem is that realism is at odds with game balance. Realistically, governments would pay handsomely for almost anything XCom can produce. What would be reasonable is to get a moderate rate of return, rising more or less linear with investment (research effort), for ''all'' items. For game balance, this could be tweaked down for items that are useful in the game, or have research predecessors / successors that are useful in the game. A simpler case is to say that no item has negative profit, you can at least get 'cost price' back for it. Aircraft should arguably be in this category (since they would sell for 100s of millions which would be totally unbalancing). A rationalisation for nerfing any prices is that the money received by XCom is not the whole sale amount, but just a small commission paid by the Council of Funding Nations, which actually controls the sales and takes (in exchange for its funding) most of the profits. [[User:Spike|Spike]] 19:40, 8 February 2010 (EST)
:::: FBLs are already pretty useless, and you want to nerf these further? I'd rather think of a way to make them more useful in-game, otherwise the profit should be kept (Note how it's the mostly useless craft weapons which are profitable - I suspect there was some thought into this..). In comparison, the Laser Cannon profit does get nerfed with XcomUtil, but we get a useful weapon instead. I'd suggest a modified FBL will have a very high elerium requirement, and the power of the weapon should be raised a bit to compensate. [[User:Cesium|Cesium]] 20:04, 8 February 2010 (EST)
::::: For example: Raise power to 240, and add another charge (almost enough to sink a battleship if a craft has two FBLs loaded), but make it cost 100 elerium to make launcher. Raise hours for Balls by factor of 10. [[User:Cesium|Cesium]] 20:16, 8 February 2010 (EST)
::: Actually you're right, it makes more sense to make FBLs viable, instead of (just) nerfing the profits. Obviously high Elerium requirements will make them non-profitable. But of the 2 problems - making things useful and preventing 'factory farming' - I think making things useful is more important. I didn't realise FBLs were not tactically useful. I've never built them, only Plasma Beams. 3 ammo is reasonable, it means that 2 FBL armed aircraft have a good chance to take down a Battleship, if they can fire 9-10 out of 12 fusion balls before they are both killed. But 100 Elerium is way too much for an improved FBL that's only slightly more powerful. I think my suggestion (4 Elerium, 20 Alloys, 10x hours, 10x space) fits with the requirements of other XComUtil-modified weapons. Combined with your suggestion of 3 ammo and 240 damage, I think it would make FBLs ''useful'' again, which is one of the original goals of XComUtil.
::: Of course, it's ''possible'' that Scott was cleverly making FBLs useful, by making them so much cheaper (net) to manufacture than Plasma Beams. In an XComUtil modified game, you might well deploy FBLs first, and only work your way up to Plasma Beams later, because of the huge manufacturing costs of Plasma Beams. But personally I think it was an oversight. [[User:Spike|Spike]] 17:21, 9 February 2010 (EST)
:::: I've never played with XcomUtil modified lasers, so if you say this fits in better that's fine with me. It's unfortunate it involves increasing space: inventory management is one of the things I hate about the first two X-Coms. I was hired to be a commander, not a supply clerk! A mod which made general stores have 10000 space (like Apoc) would be nice.. [[User:Cesium|Cesium]] 21:39, 9 February 2010 (EST)
:::: Actually the energy weapon mod means they uses more ''workshop'' space to build but not more inventory space to store.
::::However "An army marches on its stomach ", Napoleon said, by which he meant that wars are won or lost on logistics. Other famous commanders have said similar things. So a general should pay attention to logistics. One of the great things about XCOM is it's not just a tactical game, it's a combined political - strategic - operational - tactical game. [[User:Spike|Spike]] 04:37, 14 February 2010 (EST)
*Zrbite lying around in odd places. Objects lying around in odd places in general - these are map modifying errors, probably only occur when customising terrain etc.
:: Will be part of an overhaul of the BFG --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*There is a small problem in editing/customising craft using '''XComUtil.cfg'''. Certain X-Com craft weapon values - the rate of fire value - can't be set. Or more specifically, they can be set (patched) in the executable but it has no effect in the game. To avoid confusion they should perhaps be removed from the format of custom craft, or commented out. (This rate of fire patching ''might'' work on UFOs, haven't tested it).
:: Can you be more specific? --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: There is a section in '''xcomutil.cfg''' which is used for patching XCom craft weapon characteristics. This is where Scott changed values for the Laser Cannon, etc. Probably very few people use these fields. I only used them because I was doing research into the game mechanics. One of the values changed in this section is the reload time. These values are present in the executable, and can be patched, but patching them has no effect (other than to change the UFOPaedia entry). The reload time seems to be hard coded elsewhere in the executable, based (broadly) on the class of weapon. So you might want to comment this column with an a note saying "cannot be modified for combat". On the other hand I could be wrong, or someone still might want to modify these fields. Discussion is at [[Talk:UFO_Interception#Observed_Rates_of_Fire]]. Offsets are at [[Talk:GEOSCAPE.EXE#Craft_weapon_stats]]. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
:::: Or maybe change these display-only values so that they reflect the [[Talk:UFO_Interception#Observed_Rates_of_Fire|observed reload rates]]? I am not yet 100% sure I have got these right, might want to wait until I do some more confirmation tests. [[User:Spike|Spike]] 15:26, 22 February 2010 (EST)
*EQL only works on turn 1 (see discussion above)
::: Added to my to do list. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)

==Fixed Bugs==
*don't prevent patching windows version while running in dosbox, or vice versa
:*Fixed: XcuSetup can be run independantly to the OS RunXcom is used in.
*4DOS and MS-DOS 5 dont like "-" in variable names.
:*Fixed
*Enviroment space reached quickly on most DOS envirments.
:*Partly Fixed: Requirement has been drasticly reduced to to ~1024 use of Command.com /e:xxxx still may be required
*EnvClean.bat has an error in line 172: ser -> set.
:* Fixed in build 204.
*ANSI escape sequences aren't necessarily supported on a real dos environment/emulation
:*Fixed: ANSI only used in DOSBox
*If all the aliens are down (some of them stunned), the last save is named "AutoCombat" and I end turn, XcomUtil may still run "AutoCombat" phase. This may have slightly different results than end of combat would have had
:*Fixed: Autocombat will not run if you have already won.
*A fully loaded Hammerhead's initial deployment has three aquanauts outside the craft.
:*Fixed: the unit placement for the default 12 unit craft has been added to XcomUtil.cfg
*Select terrain: dosent apear untill after I select a terrain in BFG prompting
:*Fixed
*geodata/obdata.dat get's trunkated with slecting any improved weapon.
:*Fixed: This happend because a full backup did not complete but XcuSetup does not detect it. Backup script's changed to avoid xcopy timeout on some versions of DOS. (Backups are required by SDUMP to apply patches)
*I get this error dureing backup "16-bit MS-DOS Subsystem NTVDM has encountered a System Error The handle is invalid."
:*Fixed: All NT based OS's now useing 32bit EXE's
* You can get X-COM MIA if you abort a mission, even if everyone is in the exit. Possibly a second stage bug only? See [[Image:X-COM_MIA.zip]]. Note that this only affects the report - after mission all the X-COM troops are still available.
:*NOT Fixed: This happens even on vanilla TFTD with that save. Given it's TFTD it could be an issue with the mapfiles. --[[User:BladeFireLight|BladeFireLight]] 00:23, 24 February 2010 (EST)
:*Various second stage bugs - ammo clip recovery, crashes after autocombat of first stage, etc. Mainly for TFTD, but possibly Cydonia in UFO is also affected.
:*Fixed: Clip recoverty no longer ran between parts of 2-3 part missions. Autocombat only crashes on two part if you are aborting the second stage and the save in slot 10 is from the first stage. Stage comparisons are now done to abort autocmbat if you do this.
*Removal of Small Scout map / Survey Ship map, making it impossible to do these Battlescape missions.
:*Fixed: 9.7 only removes the maps if you use the BFG. I hope to have 9.8 not remove them at all. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*The XcuSetup prompt for the option of less-profitable weapons manufacturing is misleadingly called "new laser weapons".
:*Fixed: Renamed to Alternate Lasor weapons.
* SteamSetup.bat won't run from DOSBox. It says "This needs to be run from Windows". Though, does it make any sense to run SteamSetup.bat under DOSBox (eg for a linux system with no Steam)? [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
:*NOT Fixed: STEAM dosent give access by default to the command prompt. If you know how to add that then you should know enought of DOS not to need the STEAM menu. --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)
* '''cfg/ShipDefU.txt''' has the XCU values for improved Laser Cannon (35/35/35), not the original values (21/35/70). Is this correct - is this file supposed to be the original defaults? [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)
:*Fixed: I was unawhare that this had been changed. The weapons are not prompted for any change so they should not be changed. I'm reseting them all to defaults and looking to see if Scott had anything about them in the notes. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
* standalone patches the fix the difficulty bug
:*Partialy Fixed: 9.7 min install is the dificulty patch and changeing Copy protection questions to all 0's.
*Version detection issues with obscure versions (Italian, 1.2a, etc.) causing corruption or lack of patching.
:*Fixed: Added support and patching offsets.
*Various default options make the game easier, not harder (''harder'' being the intent of XComUtil, right?). These should not be defaults. (More discussion at [[Talk:Enemy_Unknown_Extended#Standard_Config_Discussions]]) E.g.
::: 9.7 only has 3 items on by default. Remove copy protection. Fix Difficulty bug and Split EXE (split EXE can be skiped but not the others). All other options are default to NO.
::: As for the intent of XcomUtil. Scott added features to
:::# Increase difficulty.
:::# Make useless items useful.
:::# Get the game Started faster.
::: I have added:
:::# Don't make unwanted changes.
:::# Fix game bugs
:::::Yes all of those are very sensible. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
::::Latter versions of XcomUtil will turn the last two forced items to prompted. with only the Difficulty bug and the split EXE as Default=Yes. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Basic tanks using advanced tank stats
**Improved High Explosive - very powerful in favour of X-Com, especially as alien spawn points and routes aren't set up to cover holes in UFO hulls.
:*Gauss weapons have infinite ammo
::: 9.7 has a second option to just the increase power to closer match UFO.
:*Using fighters as transports (carrying soldiers)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Using transports as fighters (weapon hardpoints)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:*Improved Heavy Laser / Heavy Gauss. OK, this should maybe be a ''recommended'' option since the unpatched weapons are nearly pointless. But, it does make the game easier. [[User:Spike|Spike]] 20:12, 7 February 2010 (EST)

=XComUtil Wish List=
Things that are not bugs or inconsistencies in XComUtil but would be Nice To Have

== Features for 9.7 - Interface, consistency and bug fixes ==

=== Categorise Config Options ===

For each option, in the prompt, note which category of option this is, according your list above. E.g. faster start, making the game harder, making useless items useful, bug fix, variant game, etc. [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)

:Actually it might be even better to organise the options questions into sections, thematically grouped by these categories. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

:: Items are currently sorted like this.
* Windows EXE
* Game Fixes
* Game Mods
** Sound
** Craft
** Base
** Equipment
** Research
** Units
** Battlefield
** Alien Craft
** Misc
--[[User:BladeFireLight|BladeFireLight]] 19:25, 10 March 2010 (EST)

=== Improved Pistole Modification ===
*Remove 3rd burst for Pistol - it's already good enough, as NKF has shown
::: do you have a link to NKF's comments? --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:::: Having trouble finding his comments, maybe he'll show up here! See [[Rifle_vs_Pistol]], also [[Talk:Squad_Composition_and_Tactics#Starting_Sniper_Weapon]]. If anything there is a case for the Pistol to be nerfed slightly (eg Damage=20, Ammo=8), or for the Rifle to be buffed. Also worth looking through [[Weapon Analysis]] for general thoughts on weapon power and balance. The weapon set in EU is actually remarkably well balanced already.
::::: Further to this - not a bug but it's really wrong for a projectile weapon, a firearm, to have the same accuracy on Auto as on Snap fire (60). Even plasma weapons have Auto accuracy somewhat lower than Snap. If you reduce the Pistol burst mode accuracy by anything less than 2/3rds, the burst function is still useful, but more balanced. Actually even with a reduction of ''greater'' than 2/3rds, it would be useful, because of the increased damage at point blank range. Which is perhaps realistic for a burst-mode pistol. 60 Accuracy is higher than any Auto weapon in the game, for what ought to be the least accurate auto weapon. The best auto firearm is the Rifle at 35. Anything over 20 is still a bonus for the Pistol. How about 25? This still gives burst mode a 25% edge over Snap mode at long ranges, and a big improvement at close/point blank. 30 would make it more accurate than a Laser Pistol is on Auto (28), which is hard to justify. Admittedly the Pistol burst mode uses 3x (?) the TUs, so maybe some latitude can be given. Maybe go to 30 Accuracy, then, but no higher. [[User:Spike|Spike]] 19:49, 11 February 2010 (EST)
:::::: An interesting idea. Scott felt that this was just to make the pistol useful by allowing three snaps to be treated as one action so you dont deal with Reaction fire. The end results is the massive time units and same accuracy. If I lowered the accuracy I would have to lower the time to. I believe there is a reason the pistol doesn't have full auto in the vanilla game. You have seen a military issue full auto pistol? --[[User:BladeFireLight|BladeFireLight]] 21:15, 11 February 2010 (EST)
: Indent reset! I can't remember what my comments were either, but it's probably has to do with the weapon anaylsis and how useful snap shots already are. 'tis a jolly good weapon. I agree that you can't just make the auto mode identical to three snaps - you've got the added bonus of uninterrupted fire for the first two shots. You need to pay this off either with reduced accuracy or increase the usage cost.
: For consideration, I was actually fiddling with the weapons a few months back and was testing a 10% accuracy burst mode at 15% TU costs. I think 10 or 15 AP damage. Turned out way-way too powerful a weapon (against soft enemies) - and this was on a rookie I just picked randomly. It was probably too fast, but it still worked fairly well at 10% accuracy. 60% accuracy does feel quite high. -[[User:NKF|NKF]] 00:14, 12 February 2010 (EST)
:: Exactly. The point is that a 3-rd burst makes the Pistol more useful, ''even if the per-shot accuracy is lower'', because you get 3 attempts to kill the target before it Reaction Fires, rather than just one. As long as the ''net'' 3-rd accuracy isn't less than a single Snap shot, the weapon has been improved. The break-even point is about 26% accuracy on auto. At this level, 3 rounds have a ~60% chance of getting ''at least one'' hit. Even if the 3-rd accuracy was lower than a single Snap shot, you would still get the advantage of multiple hits at very close range. I would strongly suggest no more than 25% accuracy for Pistol auto burst, at the same level of TUs (3x Snap right?). This will definitely still be a significant improvement for the Pistol. Probably what was not fully understood at the time Scott did the original mod, is that the Pistol is arguably ''already'' the most effective starting weapon, certainly against the initial opponents. [[User:Spike|Spike]] 13:19, 12 February 2010 (EST)

=== Fusion weapons inconsistently exempted from Alternate Laser Tech ===
* Fusion weapons inconsistently exempted from the "more difficult" energy weapons manufacturing option ("alternate laser Tech"). Blaster Bombs and Blaster Launchers, Fusion hovertanks and ammo, and Fusion Balls and Fusion Ball Launchers - none of these are harder to build or use with the "alternate Tech" option. Why make laser weapons/tanks and plasma weapons/tanks harder but not Fusion weapons? It's not consistent. I wonder if Scott didn't look at these because he never used Blaster Launchers or Fusion Hovertanks, as he considered them to unbalancing already? And ignored FBLs because, well, most people ignore them? But this should be consistent. Or, the "harder weapons" option could be broken down into sub options, e.g. for each weapon technology:
** Much more expensive (typically: add some exotic materials, 10x workshop space and 10x Engineer hours)
** Can/can't manufacture the battlescape weapons/tanks (pure alien weapons only)
** Can/can't manufacture the ammo (pure alien weapons only)
:Personally I would prefer it to be all-or-nothing but include the Fusion weapons as being more difficult to make and use. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)

=== AutoCombat issues ===
* Day vs Night
** The Day/night algorithm breaks. For example, at any point when XCom has more than twice as many flare-carrying soldiers than there are remaining aliens, XCom is actually ''stronger'' in darkness than it would be in full daylight. Toward the end of a battle this is a very common situation. But fixing the algorithm is tricky. What might work is to give -10 for each Soldier in darkness, reduce from -20 to -10 for each Alien in darkness, then add back +10 for every soldier with a light source. Thus there is no way XCom can go 'net positive' from light sources.
:: If you have more units then they do you can see more of the battle field. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:::It never makes sense for XCom to be stronger at night, than during the day, for the same force ratio. But that is what happens. An example. 10 XCom soldiers with flares and 3 aliens. At night there is an extra -30 modifier for the aliens, but a +100 modifier for XCom, net +70. The same 10 soldiers against the same 3 aliens are +70 ''more'' effective in darkness than they would be in daylight. It does not make any sense. [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
** The definition of a light source should be expanded to include a Flare ''or'' an Incendiary weapon. In fact, one Incendiary-capable weapon of any type (AC/HC/HjC/GC), with appropriate Incendiary rounds carried, should be enough for the entire squad to be considered as having a light source. But this may be hard to implement without a special flag and a special pre-search for a valid Incendiary weapon, since AutoCombat normally scores by individual soldiers, not by whole squads.
:: This would take a rewrite. currently the ammo is not used by W: --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
** To be honest I would prefer that each soldier without a light source in darkness is 50% effective, each soldier with a light source (personal or squad), is 75% effective. Meanwhile how about this:

//Darkness
-10 L:-9 u:-2 // Human in Darkness

+10 L:-9 u:-2 W:-27 U:- // Human in Darkness w/Flare -OR-
+10 L:-9 u:-2 W:-4 W:-7 U:- // Human in Darkness w/In ammo and launcher HC/GC-IN -OR-
+10 L:-9 u:-2 W:-8 W:-11 U:- // Human in Darkness w/In ammo and launcher AC/HjC-IN -OR-
+10 L:-9 u:-2 W:-12 W:-15 U:- // Human in Darkness w/In ammo and launcher IN Rkt/Torp

-10 L:-9 u:4-14 // Alien in Darkness
:: Only thing I see is that this ''must'' come at the end. The U:- removes the unit from further consideration. --[[User:BladeFireLight|BladeFireLight]] 19:58, 9 March 2010 (EST)
::: Yes, to use the U: flag for this "OR" function, it must come at the end of the section for humans. That's how I have it my updated AutCombt.txt, these fragments are a bit out of context. It's not critical to have the "OR", it's just nice-to-have as it stops someone cheating by having a flare and one of each loaded incendiary launcher weapon in each hand and in their backpack, to get quadruple score. But hopefully people are unlikely to cheat at AutoCombat, there are easier ways such as the WIN flag. [[User:Spike|Spike]] 20:39, 9 March 2010 (EST)
* The Zombie is rated the same as a tank, a Chrysallid/Tentaculat or an effective Psi alien (-50). I think this is too high, as Zombies are much weaker than those units. A Zombie should be maybe -25.
: Disagree. the zombie should be slightly higher then a Chrysallid/Tentaculat as it will become one and you have to kill it twice. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:: OK good point! [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
* Area effect weapons (HE, IN, Small Launcher) should have at least the same bonus as effective-on-Auto weapons (+5). This is because they can damage/kill multiple targets. (The AC/HjC should not get both bonuses however.)

//Area Weapons. ToDo: compensating bonus for aliens. should not be cumulative. check if "effective?"
+5 u:-2 W:-4 W:-6 // Human w/HE ammo and launcher HC/GC-HE
+5 u:-2 W:-8 W:-10 // Human w/HE ammo and launcher AC/HjC-HE
+10 u:-2 W:-12 W:-13 // Human w/HE ammo and launcher Sm HE Rkt/Torp
+10 u:-2 W:-12 W:-13 // Human w/HE ammo and launcher Lg HE Rkt/Torp
+10 u:-2 W:-42 W:-43 // Human w/ Stun/Shok Launcher and ammo
+25 u:-2 W:-40 W:-41 // Human w/ Blaster/DP Launcher and ammo

-10 u:4-14 W:-42 W:-43 // Alien w/ Stun/Shok Launcher and ammo
-25 u:4-14 W:-40 W:-41 // Alien w/ Blaster/DP Launcher and ammo

::Having tested the first 2 rules, the first rule (HC-HE) does not work unless you remove the ammo specifier W:-6, making it just a test for an HC. But weirdly the second rule (AC-HE) works fine with its ammo specifier in place. Odd. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
::: The problem was due to [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Ammo loaded into a weapon by the game automatically prior to the equip phase is not caught by the W: function. When the ammo is loaded manually, both rules works fine. [[User:Spike|Spike]] 18:16, 13 March 2010 (EST)

* Pistols with the burst mode option should not count as Auto weapons (maybe they don't).
: Burst and snap are based on default stats --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
* Blaster Launchers / DPLs (with ammo) should be worth as much as a tank, e.g. +/- 50 (including the single shot effective bonus it should already get - see suggested rule above under area weapons)
* Should distinguish between tanks. Even with improved armour, a Tank/Cannon is not the same as a Fusion Hovertank. I would suggest a range of 25 for a Tank/Cannon to 75 for a Hovertank/Fusion. Maybe 40 for a Tank/Rocket, 50 for Tank/Laser, 60 for a Hovertank/Plasma?
:This does not seem to be possible with the existing ruleset as all Tanks are unit type 3
::Hmm, byte 42 of [[UNITREF.DAT]] is Rank but also Tank chassis. So this ''might'' allow distinguishing tracked tanks from hover tanks, at least. An alternative approach would be to pick some stat (that has a StatStrings statid) and set it to a different unique value for each tank type. [[User:Spike|Spike]] 18:32, 9 March 2010 (EST)
::This rule set might work:

// Tanks - distinguish chassis types.
+40 u:3-3 R:0-0 // Tank, Tracked (Cannon, Rocket, Laser)//To Test
+60 u:3-3 R:1-1 // Tank, Hover (Plasma, Fusion) //To Test

* Flying units (either side) should be worth say +/- 5
:Not possible for XCom as no statid makes a distinction between Power Suit and Flying Suit. Would be possible for aliens eg:

-5 T:0- u:6-6 // Flying Alien - Ethereal
-5 T:0- u:8-8 // Flying Alien - Floater
-5 T:1- u:13-13 // "Flying" Alien - Hallucinoid
-5 T:1- u:11-11 // "Flying" Alien - Tentaculat

* If the squad is carrying some Smoke or Dye that should be worth maybe +5 - +10. But since the aliens don't ever carry that, you need some balancing factor for them.

+1 u:-2 W:-20 // +1 per human with smoke grenade(s) (hopefully not +1 per grenade!)

* Effective melee weapons should be counted. This is particularly important in TFTD when ranged weapons may be ineffective, e.g. vs Lobstermen.
* Similarly if the enemy are in heavy armour and therefore a soldier/alien does not have an effective weapon, any HE Pack / Alien Grenade / Sonic Pulser should be counted for something (if it is "effective").

//Melee weapons
+5 u:-2 W:1- W:-26 // Human w/o effective ranged weapon but w/ Stun Rod
<s>+5 u:-2 W:3-26 // Human w/ effective Stun Rod (cumulative to above)</s>

::The second rule doesn't work at all, it looks like it counts all items of types 3-6. The "superiority" function (first value before the hyphen) does not seem to operate, probably because it is a melee weapon. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
::: did you try W:255-26 ? not that I know if it would work. AutoCombat doesn't recognize stun rods as weapons when applying damage.--[[User:BladeFireLight|BladeFireLight]] 21:01, 9 March 2010 (EST)
:::: OK, if AutoCombat rates stun rods as doing no damage, the lower range of the W: function ("superiority") will likely never work. So we can't tell whether or not a Stun Rod is "effective" vs the current enemy. In general, the Stun Rod is a pretty effective weapon. So instead we generalise and just use something like this rule set:

//Melee weapons
+5 u:-2 W:1- W:-26 // Human w/o effective ranged weapon but w/ Stun Rod
+5 u:-2 W:-26 // Human w/ effective Stun Rod (cumulative to above)

//It would be nice if AutoCombat checked for the presence of Stun Rods and used them to increase the chance of an alien casualty being stunned rather than killed.

//To Do: check if TFTD melee weapons are included in "effective" weapons by the W: statid.

//Grenades
+5 u:-2 W:1- W:-19 // Human w/o effective ranged weapon but w/ effective grenade(s)
+5 u:-2 W:1- W:-21 // Human w/o effective ranged weapon but w/ effective prox grenade(s)
+5 u:-2 W:1- W:-22 // Human w/o effective ranged weapon but w/ effective HE pack(s)
+5 u:-2 W:1- W:-44 // Human w/o effective ranged weapon but w/ effective Alien grenade(s)

-5 u:4-14 W:3-44 // -5 per Alien with effective Alien Grenade(s) (hope not -5 per grenade!)
:: Only one per unit. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)
::: Tested ok too! [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
* AutoCombat victories should award all UFO Components, not just some Navigation, Elerium and Alloys.
* Every Civilian on the map should be a penalty to XCom of maybe -5, due to the distraction effects of trying to save them / avoid killing them.

-5 u:15-16 U:- // Civilian distraction effect, no further effect

Let me know if I should try to work some of this up as AutoCombat rules. Some of it requires new coding of course, but a lot of it could probably be done with existing rules. [[User:Spike|Spike]] 13:15, 7 March 2010 (EST)
: I dont plan on any changing to the underlying code yet. Your welcome to make up a new set of rules and testing them out. --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
:: OK added some rules above. I have not tested them yet, some of the syntax might not work. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)
::: Syntax looks good to me. Give them a test and let me know how they go.
::: Just a quick note on how AutoCombat works. First the success percent chance is calculated using the AutoCombat StatStrings, dead and unconscious units dont count. (those that bleed to death are considers alive, need to fix this). If it's below AbortThreshold it aborts. If it's 100-199 then change to 90. 200+ change to 95 (success is never a guarantee.) Aliens roll d100, if over your success chance you lose. If You win. Then average damage by each side is calculated based on Loaded weapon being carried and time units. All aliens are killed or stunned by X-Com unit chosen at random. Each Alien gets a chance to wound an X-Com unit based on Success Percentage. Randomly choose unit using random damage (max is average alien damage) Leave at least one X-Com Unit alive. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)

== Features for 9.8+ - New features ==

=== TFTD Gause Tank Research Fix ===
*Have the option to make the Gauss Tank require only Gauss Cannon research - this can make it more distinct than the Sonic Displacer and maybe slightly useful for a while
:*I plan on it. just not this version. --[[User:BladeFireLight|BladeFireLight]] 20:53, 18 January 2010 (EST)

=== Improved Base Comes At Cost ===

The Improved Base is supposed to be a "faster start" option rather than a "make the game easier" option. But it does make the game easier, not least because it gives you a load of free base facility improvements. (Not to mention not having to struggle along the first month with only Small Radar and no Alien Containment) To partly avoid making the game easier, please add a sub-option that subtracts the cost of the extra facilities from your starting cash. This should be the ''full'' cost of the extra facilities, not just the difference between e.g. a Small Radar and a Large Radar.
[[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
: I dont have the offsets to the starting money ranges. so I cant do this. --[[User:BladeFireLight|BladeFireLight]] 19:13, 10 March 2010 (EST)
:: I never realised that the starting money is slightly random, I see ranges from $4,125,000 to $4,153,000, in ten samples. Does not seem to depend on Difficulty or starting base location. That is going to be a hard offset to find. [[User:Spike|Spike]] 20:36, 11 March 2010 (EST)
::: I believe there is no "starting money" anywhere to be found, or rather the starting money is effectively zero but it soon changes: the first thing the game does when you begin a new game is perform a hidden monthly report which grants you money from the funding nations. Only way to decrease it is to lower your rating toward countries (you should be able to hack the starting diplomacy data located at 0x4728F8). Or I could just patch the initial money to be negative instead of zero thus providing lower overall starting money. [[User:Seb76|Seb76]] 15:52, 12 March 2010 (EST)
:::: That makes a lot of sense. The initial money is the same as the initial funding. Doh! I should've realised that. The solution to poke a negative number into the money field, prior to the "hidden funding round", sounds a great idea.
:::: Looking at initial money vs funding, your initial cash is always $1,860,000 less than your initial funding. This $1.86M is probably made up of the first 3 rows (only) of your initial Monthly Costs: $500K transport rental, $1200K Interceptor rental, and $160K salary (not hiring fees) for 8 Soldiers. The salary (and hiring fees) for 10 Scientists and 10 Engineers are ignored. The Base Maintenance costs, $224K for a standard starting base, are also ignored. This generosity saves you at least $774K. Could this be considered a bug? Possibly.
:::: The cash value of the XComUtil Improved Base is a whopping $4.5M. This is $1.6M of facilities (Alien Containment, Large Radar, 2nd Living Quarters) and $2.9M of personnel (+10 Engineers, +40 Scientists). $4.5M would wipe out all starting cash and players would begin the game with a negative balance - quite challenging! For XComUtil, it might be best to break improved Facilities and Extra Starting Personnel into 2 options, with each having a sub-option to pay for the improvements. ''"These extra facilities/staff would cost $1.6M/$2.9M, do you want to deduct that amount from your starting cash?"'' [[User:Spike|Spike]] 20:48, 12 March 2010 (EST)

== Easier Inventory Management ==
Inventory management is one of the things I hate about the first two X-Coms. I was hired to be a commander, not a supply clerk! A mod which made general stores have 10000 space (like Apoc) would be nice.. [[User:Cesium|Cesium]] 21:39, 9 February 2010 (EST)
: The manager of any facility has to deal with generalities of space issues. The clerk tells you if that fancy new tank you just bought will fit. He has to put it in storage and keep track of what shelf the ammo is on. --[[User:BladeFireLight|BladeFireLight]] 22:27, 9 February 2010 (EST)
:: That's the clerk's problem and if he complains too much I'll have him peel potatoes until his hands drop. In any event, the limit doesn't make any sense:
::* General stores size is 8x8x2 (8x8x3 in TFTD) per base defence map, and should have no problem storing more than 50 items.
::: The items taking up 1 item unit are typically about the size of humanoid body. I think it's not unreasonable to have no more than 50 of those in the area that the General Stores takes up.
:::: I can't find a list on the wiki of storage space requirements for items, so I'm not sure which items take up 1 item unit. Typically the main space wasters are Heavy Plasma ammo/Blaster Bombs/Stun Bombs (late game) and/or HWPs and avalanches (early game). These either are definitely not the size of a human body (ammo/Bombs), or shouldn't be stored in stores at all (HWPs gain nothing, and might as well lay around somewhere else in base).
::* The size of a fully built X-Com base is about the size of a city block (judging by comparison of base defence to terror missions), and should easily be able to hold hundreds of items even in the starting base if it's willing to put some stuff not in the general stores.
::* The space limit makes no sense. Why do Blaster Bombs and Heavy Plasma ammo take so much space whereas in the inventory view it doesn't take any more than normal ammo? Who stores <s>mini tanks</s> HWPs in the same compartment as light weapons? And the way X-Com (probably) stores ammo and explosives is scary...
::: As you suggest, extremely powerful ammunition probably requires a lot more space for safe and secure storage in-base, versus on a tactical mission. Imagine what would happen if a Blaster Bomb exploded in a base? Or was stolen? They probably use nuclear warhead style storage facilities for those. And similarly for Avalanche warheads, alien artifacts, Elerium, etc. Segregating dangerous/explosive items from other items probably uses up a lot of overhead in the construction of the storage space - think armoured, bomb-proof lockers and bulkheads, advanced security systems, airlocks, scanners, etc. This is not just like piling stuff up in your shed! And the Commander who left Elerium or Avalanche warheads lying around in his hanger or corridors would justifiably be sacked on the spot by XCom High Command. [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Well, judging by all the explosives in the hangar during base defence and the X-COM 1.0 Elerium bug, Elerium and explosive warheads ''are'' lying around in the base... And all the equipment in the General Stores is stored in ordinary lockers according to the General Stores map ;-) More to the point, if X-COM wants to store explosives safely (judging by said warheads X-COM doesn't care too much) they need a special facility for this, not to store them in the room which also contains all the base's weapons and priceless alien artifacts.

:::: Furthermore, I expect X-COM to improvise on storage in the interest of actually winning the war. X-COM does do this and ignore the limit when manufacturing stuff in-base or getting loot from missions. All that's needed is that X-COM will improvise for transfers too. I can't imagine a quartermaster informing the commander there isn't any room for the new armour and that the troops should go without. Maybe the reason X-COM doesn't pay quartermasters each month is that they keep getting themselves lynched by enraged X-COM troops...
::* Gameplay wise, inventory micromanagement is just no fun, especially in the late game when you have all the cash you need but still has to sell stuff after each combat (which can be prolonged if you haven't sold for awhile), otherwise you can't transfer items to the base where your main team is at.
::* Maybe this entire "stores" thing is a plot by the CFN to force X-Com to share its technology with them by forcing X-Com to sell sell sell. It's not like they pay X-Com the real worth of the technology anyway. [[User:Cesium|Cesium]] 23:47, 9 February 2010 (EST)
::: I think a lot of people do find the inventory management tedious, or unrealistically low. Personally I think it's about right for large equipment (missiles, tanks, bodies), but too low for small arms and personal equipment. And yes, it only reflects using the General Stores modules, not storing stuff at random points in the base - maybe fair enough. If the right offset to patch can be found, the storage limits could easily be raised. The last few bytes of [[BASE.DAT]] could be a good place to look for this offset. BASE.DAT can store up to 9,999 units of each item per base. The total limit for items per base would need to be found by experiment, but 9,999 might work for those who want to ignore inventory. For those who feel inventory management is OK but the limits set too tight, the capacity of each General Stores could be increased from 50 to 100 - assuming we can find the offset for this to patch it. [[User:Spike|Spike]] 19:50, 10 February 2010 (EST)
::::Maybe you can try there:
.text:00439C85 66 81 C5 F4 01 add bp, 500
::::[[User:Seb76|Seb76]] 13:03, 11 February 2010 (EST)
::::: Yes that works nicely. E.g. patch '''66 81 C5 E8 03''' at that location and you get 100 space per General Stores. Thanks Seb! [[User:Spike|Spike]] 18:21, 13 February 2010 (EST)
:::::: Now if only I had the offsets or search signature so we can add that as an options --[[User:BladeFireLight|BladeFireLight]] 18:24, 13 February 2010 (EST)
::::::: UFO 1.4 dos: offset 143748. TFTD 2.1 dos: offset 178462. TFTD v1 dos: offset 176861. TFTD CE: offset 252795. UFO CE: offset 236680. (all offsets are in decimal and point to the "F4 01" value to be patched).
::::::: Patching to "E8 03" has been tested on dos versions (not on CE) and it works. The "base information" screen will display the correct value, though the values to line length scale is such that the line will max at 250. [[User:Cesium|Cesium]] 05:57, 14 February 2010 (EST)
::::::::Are the preceding bytes the same from TFTD 1 and 2x? --[[User:BladeFireLight|BladeFireLight]] 17:26, 15 February 2010 (EST)
::::::::: Yes they are. '''81 C3 F4 01''' is the add instruction. [[User:Cesium|Cesium]] 17:48, 15 February 2010 (EST)
::::::::: Sig for UFO Dos is '''81 C6 F4 01''' --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
:::::::::: Do you also have the preceding bytes for UFO? with the signatures I can create a patch file for all versions --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
::::::::::: I am not sure I understand your question.. Judging the the two UFO versions I have available (1.3 per xcusetup and 1.4) the common preceding bytes are ''80 78 16 07 75 0C 80 78 3A 00 75 06'' (followed by the sig). You could try to use the sig alone - it exists only once in the file. [[User:Cesium|Cesium]] 19:35, 15 February 2010 (EST)
:::::::::::: Offset Locations are something I'm collecting but also the unique series of bytes to find them for the two geoscape/tactical that I dont have. (UFO Spanish, TFTD Italian) I hope to add a lot more options in the in the future. I do feel this one nerfs the storage system anything to get the game up and going faster is always a plus. --[[User:BladeFireLight|BladeFireLight]] 22:01, 15 February 2010 (EST)
::::::::::::: Well, you may want to add another General Stores to the improved starting base if you want to achieve the faster startup effect without "nerfing" storage system for rest of game (I prefer a "nerf" due to late-game reasons). Also, I suggest you add an message in Xcusetup to ask people to get in contact with you if they use an unknown/unrecognized version. [[User:Cesium|Cesium]] 14:27, 16 February 2010 (EST)
::: Inventory management is just as much a pain in the early game, where you almost always are out of space until your 2nd general stores is built. I like realistic constraints, but not tedium. Maybe upping the space per Stores from 50 units to 100 units would be a generally acceptable approach (now that Seb76 has kindly found the offset)? [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Yeah, that would be a great improvement. [[User:Cesium|Cesium]] 15:45, 13 February 2010 (EST)

:I can confirm Seb76 is correct, as ever. The 2 bytes at offsets '''0x39c88''' and '''0x39c89''' in geoscape.exe code for the capacity of each General Stores. Default value is 500 ('''F4 01''') which equates to 50 in-game internal capacity units. (Smallest item uses 0.1 in game capacity so I guess that is 1 unit in internal units). I am not sure about a signature. From what I can tell, the preceding bytes '''66 81 C5''' are unique in geoscape.exe, which seems pretty odd, so someone else should verify that. [[User:Spike|Spike]] 19:48, 13 February 2010 (EST)
:: Yes it is unique to CE. it does not exist in any DOS EXE, but "F4 01" can be found in 79 places. Trial and error could locate it. --[[User:BladeFireLight|BladeFireLight]] 20:50, 13 February 2010 (EST)

=== AutoCombat ===

==== Firepower Factors ====
You might want to consider replacing the weapon offensive weighting factors for Autocombat with some factors that are (inversely) related to the [[Weapon_Analysis#Quantitative_Analysis|% TUs Per Kill]]. I've tabulated these for each weapon (including tanks) vs each alien race. You would still need to account for Psi, light/darkness, and XCom armour. Plus you would need a similar offensive factor for the aliens' attacks. But I could probably help with that, I have the data that's directly comparable to the % TUs per Kill for XCom weapons. [[User:Spike|Spike]] 22:06, 12 February 2010 (EST)

==== AutoWithdrawal ====

One of the most tedious things you can try to do in XCom is to scavenge the battlefield and retreat to landing craft for an Abort. A great option would be an AutoWithdrawal, similar to an AutoCombat, but with an easier threshold of XCom vs Alien combat power.

Basically it would scavenge all loose equipment off the Battlescape - dropped friendly and alien items, friendly and alien corpses and wounded, all go back into the landing craft. Elerium, Alloys, and UFO Components would not be recovered, as this is (normally) impossible apart from full tactical victory. All friendly troops return to the landing craft. Friendly losses, and equipment recovered, would be proportional to the offensive factor ratios but much more favourable than for AutoCombat. E.g. as long as XCom factors were at least equal to Alien factors, they would be able to scavenge everything and recover without casualties. If the aliens were stronger than XCom, they would only recover part of the scavenged equipment, and risk partial casualties, at say one third the rate of AutoCombat. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

: It's too easy compared to actual game IMHO. Every time a battle went FUBAR for me, it got FUBAR all the way and I was lucky if I could salvage my own team/equipment and maybe a single alien weapon/body. An AutoWithdrawal without salvage might be useful, but perhaps instead we should change AutoCombat failure mode to work better (e.g. Make some X-COM people survive a failed AutoCombat, depending on strength vs aliens). [[User:Cesium|Cesium]] 15:00, 7 March 2010 (EST)

:: Yes fair point. I was not thinking of the FUBAR situations, and you are right about how hairy those are. I was thinking of the situation where you control a certain part of the battlefield, but you either don't want to go on an endless hunt for the last few aliens, or you pretty much know you can't take on the aliens that are left (e.g. in the UFO or some other stronghold) without getting creamed. You can exercise a safe withdrawal, it's just tedious to carry out all the bodies and equipment. But it's pretty hard for an AutoCombat algorithm to detect which of those situations it is - FUBAR, boredom, or tactical withdrawal. I'll have to think about that, there may be no realistic solution at all. And there is the existing "teleport loose items back to base" command line option to XComUtil, maybe that's enough. [[User:Spike|Spike]] 16:08, 7 March 2010 (EST)

=== Tougher UFOs ===

[[Wish_List_(EU)#Tougher_UFOs|Tougher UFOs]]
As this is entirely implemented by patching data and data files it is a good candidate for XComUtil rather than [[UFO Extender]].
: That would definitely make the game harder. 9.7 is about the installer and the bug fixes. This would be a good candidate for 9.8. --[[User:BladeFireLight|BladeFireLight]] 01:38, 19 February 2010 (EST)
:: Cool! [[User:Spike|Spike]] 02:25, 19 February 2010 (EST)

=== Rebalanced Craft Weapons ===

This fits under the "making useless things usefull" category. It would be a 9.8 or later option. The idea is to make the Cannon, Stingray, Laser Cannon and Fusion Ball Launcher useful. Hopefully it breaks up the monotony of Dual Avalanches followed by Dual Plasma Beams, every game.

There is one common element in the approach, and two options. The common element is to fix the stats on the Fusion Ball Launcher. The two options are to use a stat-based approach, or a cost-based approach, to fix the other weapons.

NB This proposal is still a draft and will need tweaking, but I've got it to the point where it is worth discussing. Feedback is welcome!

''(Ultimately, the Plasma Beam still ends up being pretty much the optimum weapon in the end game. To mitigate this, it is a good idea to select the existing Alternate Energy Weapons Manufacturing option in XComUtil.)''

==== Fusion Ball Launcher ====

Increase the ammo capacity from 2 to 3. Don't mess with the damage. Job done.

See [[User:Spike#Fusion_Ball_Launcher]] and discussions linked from there.

==== Cost Based Approach ====

This uses historically realistic costs to restore game balance between different craft weapons. The stand off advantage of Avalanche missiles is now purchased at a price which is significant in terms of XCom budgets and mission yields. Stingrays and Cannons become significantly cheaper alternatives. The Laser Cannon, with similar capabilities to Stingrays but free to operate, also becomes very attractive. Mounting dual launched weapons becomes a very expensive luxury.

*Increase Avalanche missile Purchase cost to $386,000
*Increase Stingray missile Purchase cost to $125,000
*Leave Sell prices unmodified (to avoid creating a cash reservoir at the start of the game)
*Leave Launcher buy/sell prices unmodified

See [[User:Spike#Cost_Based_Rebalancing]]

==== Stat Based Approach ====

This provides a benefit trade-off to shorter range weapons, by increasing their firepower or effectiveness relative to longer range weapons.

*Increase Cannon stats to 15 Damage, 50% hit. Firepower is tripled, slightly ahead of (unmodified) Avalanches launching in Aggressive mode. Increase rearming rate to 200.
*Increase Stingray accuracy to 80%. Decrease Avalanche accuracy to 60%. Stingray now has 50% more firepower relative to Avalanche. Increase Stingray rearming rate to 2, so a full craft can be re-armed in the same time period with either weapon (instead of twice as long for Stingray).
*Increase Laser Cannon stats to 100 Damage, 50% hit. Firepower is doubled, 20% more than (unmodified) Avalanches launching in Aggressive mode, 2/3rds of Plasma Beam firepower.

To avoid advanced XCom aircraft exploiting the extra firepower of the Cannon weapons and disregarding the return fire from UFOs, this is best used alongside the Tougher UFOs option.

See [[User:Spike#Stat_Based_Rebalancing]]

=== Rebalanced Infantry Weapons ===

See [[User:Spike#Balancing_Infantry_Weapons]]

Primarily this means making the Rifle a bit stronger, and probably making the Pistol a bit weaker.

==See Also==

[[Wish List]]

= Completed Wish List Items =

=== BFG Default To Unchanged ===

Is it possible when using the BattleFieldGenerator, for it to detect the actual conditions for the mission (terrain, enemy craft, and light level) and offer these as defaults? [[User:Spike|Spike]] 08:22, 13 February 2010 (EST)
:Press The esc key at the prompt. (Line 719 in Xcomutil.txt, not that I expect anyone to read the manual :) ) Enter should also work. --[[User:BladeFireLight|BladeFireLight]] 12:34, 13 February 2010 (EST)
:: RTFM eh? My biggest failing. Maybe you could add an explicit prompt "Esc or Enter = [whatever the unmodified value would be]". [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)
::: From what I can see, hitting Escape during BFG makes it continue with ''all'' values reverting to the original conditions. It would be nice to be able to select some but not all original conditions. My main use of this is to turn a night mission into a day mission without the hassle of keeping the landing craft hovering around until the terminator crosses the landing site. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
:::: You could just use the force all daylight option.
:::: After reviewing Scott's code. Esc leaves all setting as-is. Pressing enter or any other key not listed will randomly choose for you. I will see if I can change enter to leave as is. --[[User:BladeFireLight|BladeFireLight]] 11:00, 7 March 2010 (EST)
::::: This has been added --[[User:BladeFireLight|BladeFireLight]] 01:15, 14 March 2010 (EST)

== MISC ==

* It's actually quite hard to downgrade to DOSBox 0.72 in Ubuntu. Only 0.73 is offered, there is no ability to Force back to a lower package level with Synaptic Package Manager. Unix guru skilz are required to rollback to 0.72, and I guess 0.74 is not around yet, or not packaged for Ubunut APT? Is there any way to fudge around this, e.g. by providing the command line arguments in an optional text file for xcusetup.bat to parse? Having said that, even with no command line arguments, xcusetup hangs on my 0.73 DOSBox while executing SDUMP. I had to reboot in Windows to run xcusetup.bat - something that is only possible on a dual boot machine / Wubi machine. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
** Try using a different batch interpreter like 4DOS [http://www.4dos.info] to execute xcusetup inside DosBox. I tested this throughly before under DosBox/Linux and it works well with recent 9.7 builds. I suggest running "config -set cpu core=dynamic" and "config -set cpu cycles=max" before xcusetup to speed it up (xcusetup doesn't detect DosBox when 4Dos is run, so it doesn't run these automatically unlike normal DosBox case). [[User:Cesium|Cesium]] 09:48, 7 March 2010 (EST)
** Oh, and downgrading isn't that difficult: Get a dosbox 0.72 deb, and run "dpkg -i" on it, and then do "echo dosbox hold | dpkg --set-selections" to prevent future upgrades. [[User:Cesium|Cesium]] 09:50, 7 March 2010 (EST)
** Another option is to install the dosemu package, and run xcusetup under that. EU/TFTD can be run under that, but it doesn't work as well there. (Oh, and there's no mount command there. UFO/TFTD needs to exist under ~/.dosemu/drive_c which is C:) [[User:Cesium|Cesium]] 11:42, 7 March 2010 (EST)

:Thanks Cesium I will check this out. I still think it would be good to have a solution that works for people who are not knowledgeable with the unix command line though. [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)

:: Why use Linux if you dont know how to use the console? It is a text mode OS with a separate GUI. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)

::: Well Ubuntu is a bit different, as it's supposed to be an OS for the general public, where you never need to touch text mode! Incidentally I can't find any DEB or other packages for 0.72, all that is available on the DOSBox website is the source code. They really don't seem to realise that 0.73 is buggy! So I guess I will need to '''make''' it. Or just wait for 0.74 as I think it's out soon. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)

:::: See [http://archive.ubuntu.com/ubuntu/pool/universe/d/dosbox/] for 0.72 debs. Unlike Windows, package systems in Unix land are centralized, so best location to search is typically a package server mirror or a distro mirror, not a vendor's website. [[User:Cesium|Cesium]] 17:36, 9 March 2010 (EST)

Talk:XcomUtil

2010-03-14T00:51:47Z

BladeFireLight: /* Build 435 */

=XcomUtil 9.7 Beta=

9.7 Beta is available on www.bladefirelight.com

==Release Notes==
===Build 200===
This is a Beta, so backup your files before using. If you have issues pleas post them to XcomUFO.com in the XcomUtil forum.

New in this version.

*Major overhall of the installer (XcuSetup) and the inclusion of 16/32bit exe's to support both DOSBox and Windows Vista/7 x64.
*New subfolders added to hold supporting files making the install c leaner
*New XcuSetup options were added to XcuSetup allowing for silent install and uninstallation.
*New XcuSetup option for debugging the install (XcuSetup debug) creating debug.txt.
*XcuSetup now can have minimal impact on the game.
**All options default to NO.
**Almost all changes are now prompted for (skyranger guns, interceptor as transport, Disjointed Base Bug, etc...).
***Items still done by default:
***Copy protection questions set to 0000000 for UFO 1.0-1.3 and X-Com 1.0
***Difficulty bug fixed in UFO 1.0-1.4 and X-Com 1.0-1.4
***Unique names for all maps in TFTD, Used for Hybrid Games
*XCOMUTIL.CFG is now pieced together and overwritten by XcuSetup (see XcomUtil.txt for how to make permanent changes).
*All game files are restored to the pre-XcomUtil state each time XcuSetup is ran. Any modifications by other utilities will have to be re-applied.
*Recovery of MIA soldiers has been removed as it had a habit of resurrecting all KIA units to.
*Vista/Win7 patch now an option for XcuSetup.
**This will fix the blank screen issue.
**Updated to support the split EXE.
*XcuSetup attempts to fix UAC issues by resetting folder permissions.
*A number of community made fixes are included and selectable with XcuSetup.
*Support for the DOS/Window STEAM Install.
**Windows EXE, just run XcuSetup from windows
**to launch Dos version from Steam Run XcomUtil/SteamSetup.bat to activate menu then lauch from steam.
*Out of the box support for UFO Extender. XcuSetup will detect it and ask if you want RunXcom to use it.

NOTE: If you use DosBox, this requires DosBox 0.72 (Does not work on 0.73)

--[[User:BladeFireLight|BladeFireLight]] 18:28, 17 January 2010 (EST)

===Build 204===

* Fix the goto and "ser" issue
* Fixed the version display on the DosBox version detection is back on.
--[[User:BladeFireLight|BladeFireLight]] 16:15, 18 January 2010 (EST)

===Build 219===

ok. Just posted Build 219

*New command line argument "nobackup" skips backup only if it has been ran.
*Fix f0ders loader path and option goto so it actually works.
*Fix prompted terrain option to create correct flag file.
*f0ders loader now available to Vista and Win7 users. (I have no idea if this will be of help)
*replace "if exist" on folders with "if exist" on file.
*Allow 0.73 with no command line args (as this is all it brakes)
*%X-COM% to %XCOM% for older OS's
*Fixed the beta message display
*Fixed version display in deader
*Fixed misleading message in SFX install scrip.
--[[User:BladeFireLight|BladeFireLight]] 22:57, 18 January 2010 (EST)

===Build 221===

*Fix issue following issue with XcomUtil and STEAM.
**only creating backups of the Windows EXE
**only applying changes to the DOS EXE's

STEAM USERS need to run "Verify Integrity of game cache" before updating to this build.
--[[User:BladeFireLight|BladeFireLight]] 18:02, 20 January 2010 (EST)

===Build 305===

Some major restructuring of Environment Variables to fit within the limits of the forthcoming DosBox 0.74. Previous LastOp.bat files will no longer work. (should limit XcuSetup's Environment usage to about 980 bytes. Will no longer crash DosBox 0.73 by overrunning environment buffer)
Corrected a massive error that caused corruption on x64 systems.

I recommend you uninstall the previous version of XcomUtil before installing this one. (or delete LastOp.bat)

New items:

*Backup and restore of additional folders added.
*Allow install on Unknown OS with warning.
*Re-order some option questions and adjust wording.
*Correct File location that was causing Random ship generation to hang or crash.
*Fixed Vista/Win7 Patch to run on Vista. (Thanks Dangermouse)
*Environment Vars size shrunk. This invalidates previous lastop.bat (Thanks to Peter on the DosBox Team)
*Fix issues with using space in IF statement in dosbox and Dos 5.0
*Clean up environment test variable to free up space
*Backup and Restore: Fixes time out issues on DosBox. Adds progress display.
*Set Default to split EXE.
*Allow xcusetup for Dos games in x64 OS with warning
*Switched compiler to Open Watcom for ResFix and ResINfo
*New code to detect EXE version and adjust Max Research in ResFix and ResInfo
*Resfix will no longer execute on UFO
*Switched compiler to Open Watcom xcomutil xcomutrt and sdump.
*Fixed issues with 32bit structure packing leading to wide spread file corruption
*Fixed Alien Research Help math error
--[[User:BladeFireLight|BladeFireLight]] 18:28, 6 February 2010 (EST)

===Build 317===

Don't forget to re-run XcuSetup after you extract the files. For a almost quite install use "XcuSetup lastop skip"
If upgrading from pre-305 versions you need to uninstall with "XcuSetup uninstall" and run XcuSetup Fresh.

You can now use XcuSetup in Windows to configure a game you intend to play in DosBox OR run XcuSetup in DosBox and play from Windows. Even on x64 systems. XcuSetup can be slow in Dosbox this will allow for faster setup.

RunXcom now makes on-the-fly choices about x86 vs x64 XcomUtil EXE's and Steam Dos vs Windows. If you have Vista or Win7 x64 and a Steam copy you can switch between Dos/Windows Xcom by either runing from Steam or directly starting RunXcom.

A few caveats for STEAM users. Because of how XcomUtil detects the game, while XcuSetup will apply changes to both EXE's. Running XcomUtil from the command line will only effect the Dos version.

Complete List of changes.

*XcuSetup can be run from windows and RunXcom run from DosBox
*Renamed "New Laser" to Alternate Laser
*SortStats now back in XcomUtil.cfg
*Runxcom now uses x86 or x64 EXE's based on OS at time of execution
*Steam choice of Windows or DOS EXE now based on if RunXcom is started in DosBox.
*Xcomutil settings applied to both EXE's in Steam
*SteamSetup.bat displays message on success.
*Minor error fixes with 4DOS
*Better handling of unknown OS.
*New Steam Menu Options
** Run X-Com Sound Setup
** eXit to Windows
--[[User:BladeFireLight|BladeFireLight]] 03:21, 8 February 2010 (EST)

===Build 333===

Some Minor tweaks. Only major thing is I have given up on DOSBox 0.73 it's to buggy and crashes often. Although some of the bug fixes I worked out with the DOSBox dev team will not make it in until 0.75. They tell me most of them will be in 0.74 and it should not have this issue.

Luckily STEAM uses 0.72 and works as expected.

If you run another Command interpreter like 4DOS it should work.

*Random alien craft shape now works.
*Fixed Text color on BFG prompting on UFO under DOSBox.
*XCLoader.exe properly removed on uninstall and Gamefile restore
*Fixed display of Unit type on Fighter as transport prompt.
*Apply of Seb Loader from DosBox fixed.
*Commented RunXcom
*Removed Exit Point and replaced with Pauses in XcuSetup
*Updated DOSBox 0.73 error (to unstable. frequent buffer overflows setting ERRORLEVEL on program exit.)

-Blade FireLight

===Build 339===

This fixes the issue with 4DOS failing to do an initial backup, that lead to SDUMP being unable to apply patches, that led to empty designation files.
9.6 replaced the Hammer Head map by default. 9.7 does not but the unit placement was never updated. The 12 unit placement section has been added to fix units spawning outside the craft. (Scott's version of the Hammer Head is in the patches folder but requires manual modification of the config files to fully use. )

*Disable stderr redirection on 4DOS
*More debug and ArchFile now able to be run independently
*Add unit placement section for standard Hammerhead.
*Added Apply of Transport Hard Point.
*Fix Missing Terrain on TFTD Very Small

--[[User:BladeFireLight|BladeFireLight]] 21:14, 12 February 2010 (EST)

===Build 340===

*Fixed missing label causing exit in build 399.

--[[User:BladeFireLight|BladeFireLight]] 01:48, 13 February 2010 (EST)

===Build 348===

Fixed some obscure bugs.
Win7 32x on some computers would not run 16bit code(something to to with chip-set drivers and the 16bit xcopy), so now all NT based Windows will use 32bit EXE's.
Some STEAM users had issue with the windows EXE either being replace by or replacing the _patched.exe (f0ders loader) I saw this happen but was unable to repeat it. Hopefully the change of not using short file names when long ones can be will fix this issue.

*Fix BFG Prompting Display
*replace delete with del in RunXcom
*32bit EXE used on most versions of windows.
*Skip copy short file name if can find long file name.
--[[User:BladeFireLight|BladeFireLight]] 00:44, 14 February 2010 (EST)

===Build 350===

The EXE download now uses an updated script to prompt for steamsetup (if detected) and start xcusetup. This makes it more "consumer friendly".

*New SFX Installer Script.
*Cleaned up / updated xcomutil.txt and moved to xcomutil folder

--[[User:BladeFireLight|BladeFireLight]] 18:49, 14 February 2010 (EST)

===Build 361===

By popular demand the EQL now works on any turn.

*EQL allowed any turn.
*Fix Display of Forced patches for UFO Spanish/Italian
*Fix BFG questions to avoid invalid options.
*Add Xcom UFO Italian Support

--[[User:BladeFireLight|BladeFireLight]] 19:28, 17 February 2010 (EST)

===Build 384===

Lots of bug fixes. Hybrid now working, Fixed issues with auto combat and combining clips.

*Fix Hybrid Implementation
*Auto Combat will not run on second half of two part using first parts saved data.
*Auto Combat will no longer run if combat was won.
*MIA Recovery on won combat only
*Auto equip no longer triggers on second part of 2 stage missions.
*Add skip of combine clips if between stages of 2-3 part missions.
*Lost of debug info to in XcomUtil.log
*Add Headers to XcomUtil.log section brakes.
*XcomUtil's Apply action now in debug.txt
*Update and move f0dders read me per his request.
*Fixed typo stopping Lab PSI/MC Screen from working.
*Fix Infinite loop when not splitting EXE
*Fix nonexistent %no% variable
*Limit STDERR redirection to MS OS's

--[[User:BladeFireLight|BladeFireLight]] 02:44, 22 February 2010 (EST)

===Build 413===

Fixed Hybrid and Prompted BFG on Windows EXE's. Hybrid now uses Boom Blokes Pallet conversion. (removes lighting artifacts) "XcomUtil uninstall" now removes the hybrid game maps and terrain. Updated the Vista/Win7 patch. Recommend applying if you get odd colors that only go away with a reboot or playing a video in Media Player. Created new Add-on ability to allow others to plug-in to XcuSetup and RunXcom.

*Add-on support added. see XcomUtil\XcomUtil.txt and XcomUtil\Addon\Example.txt
*Restore and Backup ran second time on Hybrid games to resolve issues with cross pollination
*Update Vista/Win7 Patch to address alt + tab color issues. (restores color pallet on next start of Goescape or Tactical. Does not stop the corrupt pallet)
*Create windows flag file to force XcomUtil to update windows EXE when playing Xcom Windows
*Better UFO Hybrid integration and uninstall of copied files.
*Bomb Bloke's Hybrid Pallet Map
*command line option for config file now searches %CWD%\, %CWD%\XcomUtil\ and %CWD%\XcomUtil\Batch\
*Hybrid path detection change to look for \maps\ATLAN00.map OR %1\maps\URBAN00.map
*Move XcomUtRt and LastOp to sub-folders older LastOp moved if it exists.
*All Flags moved to the flags folder.
*If debug.txt exists zero out file (deletion caused problems with WinTail)
*uninstall a few missed files.
*Fix debug log of config flags.
*Fix echo------ error in RunXcom.bat

--[[User:BladeFireLight|BladeFireLight]] 17:40, 28 February 2010 (EST)

===Build 422===

*Fixed unit placing where units were placed outside of sub or inside of tanks.
*Fixed Display of Starting Transport and Fighter names for TFTD
*Updated addon example.txt to streamline and clarify a few things.
*Switched to Bomb Bloke updated Color Pallet
*Units who bleed to death no longer rise from the grave. (unless they die the same turn as you kill the last alien)
*Units under mind control when the last alien dies are no longer MIA.
*Fix messed up goto in Line 8 used for addons (Was causing exit of RunXcom)
*Fix RME error

--[[User:BladeFireLight|BladeFireLight]] 02:33, 2 March 2010 (EST)

===Build 435===

Original Sound Effects from UFO were re-sampled to work with 1.4 and CE.

*Add Category to option headers.
*Improve randomness by using current time instead of game date/time in srand()
*Added Option to keep Current terrain/UFO to BFG.
*Original UFO 1.2 Sounds for Geoscape and Tactical added as an option for UFO 1.4 and CE.
*Force Split EXE on STEAM. Fixes issues with setup failing.
*Reset Laser/Gauss craft weapons stats to be default.
*Example addon now uses different flag extension to avoid deletion by XcuSetup
*fix issue with Lab Screen on DosBox always screening

==Beta Disscusion==
===Build 219===

: Well, I tried running it, and noticed a few errors in the batch setup system:
:#The existence of a directory can't be tested by using "if exist". It won't work on real DOS and many DOS emulations. The suggested workaround fails sometimes (see [http://support.microsoft.com/kb/65994] or [http://www.faqs.org/faqs/msdos-programmer-faq/part3/section-7.html]).
:#* I dont have access to every platform. Your help on this would be invaluable.
:#** It's been a long long time since I wrote batch scripts... First, I suggest creating the directories unconditionally (redirect output or clear screen if you're worried about error output). Second, either drop checking for game_1 directory existence afterwards or if you must check for it - write a dummy batchfile into the directory which only runs one command: a command which exits with a specific known errorlevel (probably sdump or other xcomutil binary would work). Then try to run said batch. Then you can test for said errorlevel - if it's there, than the directory exists. Then erase dummy batchfile.
:#*** My solution is similar. i'm using the dum.bin If it dosent exist create the directory with >>%redir% and copy in a dum.bin. should work on any OS.
:#Please don't test existence of correct running environment for X-COM in the setup file (e.g. don't prevent patching windows version while running in dosbox, or vice versa). Or at least don't abort the setup, but just print out a warning. This is patronizing - it's none of Xcomutil business, and people who downloaded this probably already know how to run software. Besides, this is likely to ruin at least some possible combinations. Maybe some future bug in dosbox/Windows will make people want to run the setup batch file under cmd.exe/dosbox? Or maybe some people may even want to run XCOM CE in [http://www.winehq.com Wine] for example, and the check keeps in the way? (Also there's a spelling error - "hoast" -> "host").
:#* I dont expect everyone who got the game for the first time from STEAM to know their way around the computer. If RunXcom uses 16bit EXE's setup in DosBox in Windows 7 x64 it will throw an error. I could integrate the system checks into RunXcom so It can select the right EXE's however for STEAM and similar setup with both EXE I would have to setup a menu in RunXcom to select what version to actually use if they have Steam on a 32 bit platform.
:#* I dont intend to support OS2 or Wine like Scott did. What OS's I can support will be based on what feedback I get and what I have the time/interest in fixing.
:#** Then can you add a parameter to let us override the checks without editing xcusetup? These checks are bound to fail for some OS/dosbox combination now or in the future...
:#*** It's not that simple. The values in the syscheck are required for making decisions. like is the OS x64, is the game UFO or TFTD. does the OS have UAC. will the OS accept SHIM's. Can I find the files needed to run the commands ... --[[User:BladeFireLight|BladeFireLight]] 20:53, 18 January 2010 (EST)
:#4DOS (v7.5 and v8) at least don't like X-COM environment variable name (it returns -COM when doing %X-Com%), and I suspect it may not work under MS-DOS's COMMAND.COM either. Try something like "%X_Com%" for example.
:#* That will be fixed soon.
:# EnvClean.bat has an error in line 172: ser -> set.
:#* Fixed in build 204.
:# Note that ansi escape sequences aren't necessarily supported on a real dos environment/emulation.
:#* Good point I will move that to DosBox only.
:# FreeDOS breaks horribly on the setup files, but I think that's due to bugs on their end.
:#* I dont know what can be done about that.
:# Thanks for continuing work on XComUtil.
:#* Your welcome. I should have started on this sooner.
:# Btw, what's wrong with DosBox 0.73? It sure didn't stop XcomUtil 9.6.. [[User:Cesium|Cesium]] 09:45, 18 January 2010 (EST)
:#* 0.73 had two changes. 1. the shell closes the batch file after each line and remembers where it was then reads the file again starting at the next line. (this was to alow for menus that modify themselves. 2. They made shift move %1 to %0. I'm sure you can see what that does. I do a special shift test to detect 0.73. While the basic setup would work none of the command line options would. This was fixed in there current nightly build 2 months back so it will be working in 0.74.
:#** Grrr. They did this for "self modifying menus" (which don't need this performance killing stupidity) but ignored my patch...
::I have verified the new setup works if 4DOS is used under DosBox 0.73 (with some small changes outlined above. 4Dos had to be started with "4DOS /E:16384"). Now to test the game.. [[User:Cesium|Cesium]] 15:00, 18 January 2010 (EST)
::* Well, the Dart gun seems to be still useless. The change gave me an auto shot which takes 3xTU than snap shot but with same percentage...
::** This the same as the UFO pistol update. all it's doing is making 3 snap shots with no chance for reaction fire. --[[User:BladeFireLight|BladeFireLight]] 20:53, 18 January 2010 (EST)
::* Small wish: Have the option to make the Gauss Tank require only Gauss Cannon research - this can make it more distinct than the Sonic Displacer and maybe slightly useful for a while...
::** I plan on it. just not this version. --[[User:BladeFireLight|BladeFireLight]] 20:53, 18 January 2010 (EST)

:* One other think I noticed (with 200 but that's probably with 204 too), is that if xcusetup is run again after a successful setup, than it restores from backup, then backups the restored files again... Not sure if this is needed. Maybe there's a scenario where it is? [[User:Cesium|Cesium]] 17:32, 18 January 2010 (EST)
::* Yes it does. on DosBox this can be painfully slow to :( The reason for this is Hybrid games or map packs being added sense the last backup. When I have the new BFG and make a C++ version of the XcomUtTE.jar that 9.6 XcuSetup had, this will be of more important. perhaps I will make a command line option to skip backup so you dont have to run it. --[[User:BladeFireLight|BladeFireLight]] 20:53, 18 January 2010 (EST)

: I've noticed a bug (with 200, but since no in-game changes are mentioned in the changelog, I'm guessing its unchanged): XcomUtil is set to restore previous equipment. I'm packing a few Sonic Pulsars for the first time (I think?), and XcomUtil packs a few Pulsars into one spot in the backpack.. Savegame: [http://www.ufopaedia.org/images/3/34/Bugged_save.zip] [[User:Cesium|Cesium]] 23:32, 18 January 2010 (EST)
:: This behavior has been around since that option was added. see "Automatic Re-Equipment of Troops:" on line 1025 of XcomUtil.txt. I have not modified that section of code. It will be addressed eventually --[[User:BladeFireLight|BladeFireLight]] 23:39, 18 January 2010 (EST)

===Build 221===

:* Playing further, I noticed that If all the aliens are down (some of them stunned), the last save is named "AutoCombat" and I end turn, XcomUtil may still run "AutoCombat" phase. This may have slightly different results than end of combat would have had. (Also, the score is low in AutoCombat use since all agents are regarded as KIA, but you probably already knew that). [[User:Cesium|Cesium]] 22:57, 20 January 2010 (EST)

:: Autocombat should only run on Abort, and only if: slot ten is named "autocombat" AND it's date,time and combat round match the one just aborted. By "all agents KIA" are you saying they all were killed by auto combat? --[[User:BladeFireLight|BladeFireLight]] 12:14, 21 January 2010 (EST)

::* This is not the case. Set up XcomUtil so that it leaves messages after battle. Then get [http://www.ufopaedia.org/images/c/c3/Buggy_autocombat1.zip]. Load the game and press "End Turn" - AutoCombat will run when it shouldn't... As for all agents KIA I mean score-wise - I do get them back, but in score display I get points deducted as if they are all dead. Same for civilians at terror sites. I'm using build 200, as there's nothing in the changelogs that suggests changes to XcomUtil's behaviour in-game and I already got it installed.. [Edit: tested with 219 too - still fails] [Edit2: this turns out not to be entirely accurate: agents not in exit locations would be lost after running AutoCombat. Edit date: [[User:Cesium|Cesium]] 19:44, 30 January 2010 (EST)]
::: AutoCombat should only run then tactical exits with abort mission. if it's runing on end turn then tactical is crashing. Can you send me your debug.txt? --[[User:BladeFireLight|BladeFireLight]] 14:06, 21 January 2010 (EST)
:::: Well, there's a link to a buggy savegame above so you can verify it yourself (I'm using TFTD v2.1 DOS under DosBox 0.73 right now). I've erased debug.txt and loaded the savegame again - nothing is written to debug.txt. Also, X-COM is behaving fine (mission successful end, etc.) when this is run without XcomUtil. I suspect Tactical is just exiting normally and for some reason XcomUtil just decided to run AutoCombat. [[User:Cesium|Cesium]] 14:18, 21 January 2010 (EST)
::::: The debug.txt is created by XcuSetup. it tells me what options you chose and what happend when it tried to apply them. This would give me a baseline to replicate your setup. With 0.73 you cant run "XcuSetup lastop skip" to re-create what it did the last time you ran it Can you either send me the lastop.bat or if you run XcuSetup again with the same options and send me the debug.txt. Then I can get the same configuration your having issues with. (I need to add a CRC check to the before and after conditions of the EXE's to the debug so I can tell if they have changing consistently.) --[[User:BladeFireLight|BladeFireLight]] 15:44, 21 January 2010 (EST)
:::::: I can run "Xcusetup lastop skip" under DosBox 0.73 if I use a different batch interpreter like 4DOS... Here it is: [[Image:Debug.zip]] [[User:Cesium|Cesium]] 16:12, 21 January 2010 (EST).
::::::: That is good to know. The setup should not give an error in that case, if it passes the shift then it could care less. I would think that with a diferent interprater, %COMSPEC% would be somthing other then Z:\COMMAND.COM. am I correct about that?
:::::::: Well, in this case COMSPEC isn't changed and than it works fine. If COMSPEC is changed to point to 4DOS, than:
::::::::# "Processing" is displayed as the "Operating System".
::::::::# setup fails on the "Path to Xcopy" check.
::::::::: I tried to use the 4DOS batch file debugger to see exactly where it fails, but it's too unwieldy for this. (Note that 4DOS needs to be started using /E:16384 or something similar, since default environment size is too small). [[User:Cesium|Cesium]] 02:29, 23 January 2010 (EST)
:::::::::: It should fail on an Unknown OS. If you have a sure fire way to detect 4DOS i would be happy to add it. I would treat it the same as dosbox.
::::::::::: It's funny that a DOS program won't work on a real DOS but only on dosbox... It would be a lot easier to make the OS checks not abort, than to try and detect everything... Anyway, you can test for 4DOS like this: 'if NOT "%_4VER%". == "". (then 4DOS)'.
:::::::::: As for the environment size I'm not surprised it's to small. I use it extensively so I check for a lot of it. I dont know how the larger command.com footprint will effect available memory on a bare mettle dos install. --[[User:BladeFireLight|BladeFireLight]] 23:05, 23 January 2010 (EST)
::::::::::: Well, Environment requirement can be reduced, but this is likely to reduce legibility of setup batch. I doubt it's worth it. Even ancient DOS systems had 640KB.. [[User:Cesium|Cesium]] 00:05, 24 January 2010 (EST)
::::::: I will look at the debug and the saved game this weekend or monday. I have to finish migrating all my code to another compiler. XcomUtil was written with Borland 2.0 in mind. I had to use 5.5 for the 32 but but it's giving me fits. So I'm trying to move all the code over to Open Watcom this weekend. It will be nice having debugger to use. --[[User:BladeFireLight|BladeFireLight]] 01:22, 23 January 2010 (EST)
::::::: Took a look at why the autocombat would run when not intended. If you have the same date/time in the autocombat as the current save and press end turn with with all aliens dead it will trigger autocombat. to avoid this rename the save in slot 10 if your playing the same battle again. --[[User:BladeFireLight|BladeFireLight]] 17:40, 30 January 2010 (EST)
:::::::* OK, so it can run if end turn rather than abort is used (that's not a problem to get around). However, there's a bug: Even though tactical has concluded the aliens are no longer a threat, XcomUtil can still run an AutoCombat against a few "zombie" aliens (I think the uploaded save has this? If not, I probably have an archived save exhibiting this)... X-Com would win, but it might be possible to lose valuable research help from accidentally killing said aliens. I suspect that's due to some stun calculations failing somehow and concluding some stunned aliens can still fight. [[User:Cesium|Cesium]] 19:40, 30 January 2010 (EST)

::* P.S. Can I get research help from captive at first stage of 2-stage missions? And Has XcomUtil's behaviour for 2/3-stage TFTD missions been improved? Well, I'm doing an Artifact site now, so I'll find out soon anyway... 9.6 used to be real buggy in T'Leth third stage transition (and I have a save game for that too) and IIRC didn't let me get captives from first stage. Never played research help till now though... [[User:Cesium|Cesium]] 13:41, 21 January 2010 (EST)
::: I have only made one change to XcomUtil.exe that that was to remove the MIA recovery. I expect the clip recovery issue will still be their between stages. This is a major frustration to me and I will address it once the installer is stable. --[[User:BladeFireLight|BladeFireLight]] 14:06, 21 January 2010 (EST)
:::: I managed to overwrite my own game saves, but eventually I did quite a few two part missions. I notice that sometimes XcomUtil can emit "Divide error" when calculating research help. This seems to happen usually (but not exclusively) when calculating the second part of a two-part... The attached savegame ([[Image:Autocombat_research_bug.zip]] - unzip than save slot 10 at "AutoCombat" and abort) has this behaviour. [[User:Cesium|Cesium]] 08:44, 25 January 2010 (EST)
::::: I played around with that game and didn't get a "divide error" with vanila 0.72 but it did lockup on me doing the research calculations aborting the second stage if I autocombated the first. I also had tactical skip the equip screen and crash. This will require some more research. --[[User:BladeFireLight|BladeFireLight]] 18:03, 30 January 2010 (EST)

===Build 305===

:: I haven't played with this yet, but running setup I noticed the following:
:* I get this warning when running XcuSetup under 4DOS: "restore.bat [485] Duplicate redirection ">>debug.txt"". It's harmless though.
::: This will be fixed in the next build. --[[User:BladeFireLight|BladeFireLight]] 15:14, 7 February 2010 (EST)
:* Redirecting the "attrib -R /S" line to nul would be nice (it outputs a lot under 4DOS, FreeDos and maybe other interpreters).
::: Ditto --[[User:BladeFireLight|BladeFireLight]] 15:14, 7 February 2010 (EST)
:* Install on unknown OS doesn't seem to work - it gives "Unable to continue!" right after asking "Shell We Continue?" (without waiting for input). I've tested this on DosBox 0.73 where COMSPEC has been changed..
::: Same here. DosBox a number of things missing in the command interprater I relyed on detecting the comspec var to know it's dosbox becaus of the lack of a native find. and if I use a | it only runs the first part. I am re-writing the detection to now use the included 16bit find.com on all but x64 systems to check the ver statement. --[[User:BladeFireLight|BladeFireLight]] 15:14, 7 February 2010 (EST)
:* Why is the sound directory backed up? Perhaps you intend to add an "UFO 1.2 sounds for 1.4" or "Playstation mp3s for UFO CE" options in the future? It seems useless for TFTD though.. [[User:Cesium|Cesium]] 03:12, 7 February 2010 (EST)
::: Yes I intend to include the sound fixes eventualy. While TFTD would not be needed Its more of a pain to skip then to backup. The Geograph folder that is Slooooow. I may limit it to just files I may replace.
:* One more thing: I've tried running "command /E:512" with dosbox 0.73 and then running xcusetup. Instead of exiting with an environment space error, the setup breaks in a very odd way (dosbox is stuck and has to be terminated [edit: sometimes this requires running xcusetup more than once to trigger]). Also, the real requirement seems to be more than 980 bytes (unless the check is intentionally pessimistic?). [[User:Cesium|Cesium]] 03:29, 7 February 2010 (EST)
::: the DOSBox team is addressing this in 0.74. It was my complaints of crashing that led to us working on fixing the environment buffer overflow issue. I had to shrink my environment usage to the official size (1088) and they fixed the overflow. --[[User:BladeFireLight|BladeFireLight]] 15:14, 7 February 2010 (EST)
:: Btw, you might be interested in [http://forums.somethingawful.com/showthread.php?threadid=3220122]. The thread uses XcomUtil (9.6) multiplayer quite heavily and they probably have bug reports... [[User:Cesium|Cesium]] 03:15, 7 February 2010 (EST)

===Build 317===

:* Unknown OS now works: I've successfully ran xcusetup under FreeDOS in dosemu.
:* DosBox 0.73 doesn't work though.. It gets stuck right after asking whether to apply the bugfixes.
:* I wonder why the research fix for TFTD isn't enabled by default? I guess it will be once testing is done? [[User:Cesium|Cesium]] 12:25, 8 February 2010 (EST)
:: Minor problem with XCUSETUP of build 317. Note the missing "what" transports can carry.

-= XcomUtil 9.7 Beta (Build 317) setup =-
:: Fighters / Transport ::
Change the Interceptor and Firestorm to carry 's
[NOTE: modifies Tactical and adds additional map, route and terrain
files.]
Do you want to enable Interceptor and Firestorm as Fighter Transports? (N)

::This is my first install of the new XCU and I am VERY impressed. Nice job! [[User:Spike|Spike]] 19:23, 11 February 2010 (EST)

::: Thanks This will be fixed. --[[User:BladeFireLight|BladeFireLight]] 21:21, 11 February 2010 (EST)
:* A fully loaded Hammerhead's initial deployment has three aquanauts outside the craft. This doesn't happen when XcomUtil isn't started (i.e. via TERROR.COM). [[User:Cesium|Cesium]] 01:54, 12 February 2010 (EST)
::: Can you give me a save that is that far along. I dont have one handy. --[[User:BladeFireLight|BladeFireLight]] 02:10, 12 February 2010 (EST)
:::: Sure. [[Image:Hammerhead_bug_saves.zip]]. [[User:Cesium|Cesium]] 02:34, 12 February 2010 (EST)
:::: [[Image:Hbug2.zip]]. Maybe that would be more convenient for you. [[User:Cesium|Cesium]] 04:32, 12 February 2010 (EST)

:* I've managed to accidentally make a truncated geoscape/obdata.dat file using xcusetup. I uninstalled it, then ran "xcusetup nobackup" (it still made a backup), and chose "n" to everything besides the prompted bug fixed and improved gauss weapons. I'll try to reproduce this.
::: "uninstall" removes the backup's. "nobackup" only works if it finds backup files.
:* I've also noticed "improved gauss weapons" doesn't change the Heavy Gauss clip power in the entry in ufopedia (should be 80 instead of 75). [[User:Cesium|Cesium]] 03:03, 12 February 2010 (EST)
::: Works for me on Win7 and DOSBox 0.72. --[[User:BladeFireLight|BladeFireLight]] 15:11, 12 February 2010 (EST)
:::: I'm talking about the clip page, not the weapon page. TFTD displays the power on both the gauss weapon and gauss ammo pages. [[User:Cesium|Cesium]] 16:36, 12 February 2010 (EST)
::::: This must be with remove clip turned on. with just a power increase the damage is not displayed on the weapon. I need to look into disabling clip research as part of removing the clip requirement. for now I can add the damage levels to the clips when removing the need for them. --[[User:BladeFireLight|BladeFireLight]] 16:43, 12 February 2010 (EST)
:::::: Per description in xcusetup, Heavy Gauss is upgraded from 75 to 80 power even when "Improved Gauss Weapons" change is on, but "Remove Clip" change is off (i.e. gauss weapons still need clips), so the Heavy Gauss Clip page needs to be updated regardless of "Remove Clip" setting in xcusetup (unless you manage to disable clips altogether when its turned on). [[User:Cesium|Cesium]] 16:58, 12 February 2010 (EST)
::::::: UFOPedia pulls the information from obdata.dat. 4DOS has a number of issues that cascade though out XcuSetup I'm tracking them back. I will have to do some regression testing with 4DOS tonight. Seems redirection of STDERR varies from one DOS to another. --[[User:BladeFireLight|BladeFireLight]] 18:38, 12 February 2010 (EST)
:::::::: Ah, yes. "Real" DOS has no stderr redirection support at all. 4DOS has ">&>" extension, but NT cmd.exe uses "2>". I saw these errors, but thought they were harmless... [[User:Cesium|Cesium]] 19:20, 12 February 2010 (EST)

:Weirdness. I'm using Aliens Help Research and I win a Laser technology every day with 50 Scientists. One day I doubled up and got Laser Rifle and Heavy Laser on the same day (a known, non-XCU bug). Got Laser Cannon in 2 days. Is this supposed to happen with the human tech when you opt for Aliens Help Research? The Alien tech becomes impossible without them. Also I am getting Battlescape crashes, or rather it just skips the Battlescape altogether and replays the results of the previous battle. It also seems to lose the equipment in the transport, revert it to what was in the transport on the previous battle. I'm using the BFG and the Seb76 loader equipment management, that could be part of the problem. [[User:Spike|Spike]] 22:00, 12 February 2010 (EST)

:: OK I see what's going on. It is prompting me for terrain, but offering not terrain options but light level options. Then after I select a light level, it prompts me for light level, but does not wait for input and goes straight to battlescape, which fails.

0 = Jungle
1 = Farm
2 = Forest
3 = Human Base
4 = Alien Base
5 = Urban
6 = Desert
7 = Mountain
8 = Polar
9 = Mars

''[here I enter "5"]''
Select terrain:
0 = Darkness
1 = Twilight
2 = Daylight

''[here I enter "2"]''
Select light:

:: Basically it seems to be reading my input one step before I am prompted for it, and possibly giving the wrong input for the wrong question. It also is getting stuck in a loop of the BFG prompt. So probably it's a simple logic glitch in the batch file. I will update to the latest build and see if can replicate it. If I can, I will attach the game save file and config files. [[User:Spike|Spike]] 08:32, 13 February 2010 (EST)

::: I noticed this to. This is the underlying code.
<pre> printf( "\nSelect terrain: " );

if ( ESCAPE == ( i = getch() ) )</pre>
::: The prompt displayed before waiting for a key press. This may be an issue with Open Watcom. --[[User:BladeFireLight|BladeFireLight]] 18:39, 13 February 2010 (EST)

===Build 333===

:* One can make a truncated geodata/obdata.dat file in builds 317/333. I've run xcusetup, selected nothing but the fixes and improved gauss weapons, and pressed enter for everything else (4DOS/DosBox 0.73). The truncated file prevents the game from starting. [[User:Cesium|Cesium]] 03:23, 12 February 2010 (EST)
:: I think this may be a 4DOS issue. jpsoft.com does not look to support it any more. What version are you on on where do I get a copy? --[[User:BladeFireLight|BladeFireLight]] 15:08, 12 February 2010 (EST)
::: I've tried now with both last official version (7.50) and last open source version (8.00). Same issue with both. You just get a copy of either from [http://www.4dos.info/v4dos.htm] [[User:Cesium|Cesium]] 16:52, 12 February 2010 (EST)

===Build 340===

-= XcomUtil 9.7 Beta (Build 340) setup =-

::Creating Backup Files::

Geoscape Backup ................... OK
Tactical Backup ................... None
Maps Directory Backup ............. Processing.

16-bit MS-DOS Subsystem
Windows Command Processor - xcusetup
NTVDM has encountered a System Error
The handle is invalid.
Choose Close to terminate the application.

version is

Microsoft Windows [Version 6.1.7100]
Win7

last debug.txt message is

ResConfig=None
1 file(s) copied.
GeoBak=OK
Copying C:\games\xcom-all\MAPS\AVENGER.MAP
1 file(s) copied

xcsetup goes into a loop, the close option does not stop xcusetup but just loops

[[User:Spike|Spike]] 15:41, 13 February 2010 (EST)

:Lovely. I think I know what is going but I dont have a win7 32bit to test on. Do you have a Google Talk account? I would like to test something.
: on a side note. that is not actually a loop. it's copying groups of files at a time to avoid the timeout issue on dosbox. --[[User:BladeFireLight|BladeFireLight]] 16:40, 13 February 2010 (EST)

===Build 361===
*There's no Italian text for the New Laser Weapons option. Applying the patch seems to work, but it displays the text for the default laser weapons. Unfortunately, I don't know enough Italian to translate it myself.
:: Neither do I --[[User:BladeFireLight|BladeFireLight]] 21:51, 17 February 2010 (EST)
*There are two places in SysCheck.bat which use "%NO%" (lines 46, 164). I don't see that set anywhere. I think you meant something like "%clErr%NO%clOff%"? It's also possible to remove "set NO=" line from EnvClean.bat.
:: Thanks I will fix that --[[User:BladeFireLight|BladeFireLight]] 21:51, 17 February 2010 (EST)
*Apply.bat has two overt redirections to stderr (lines 830, 831). Since you're doing the stderr redirection support check several times, you may want to centralize it in Xcusetup.bat and than use something like %output%.
:: This is why you used to have to do "/E:16384" and why DosBox crashed so often. I have to keep under 950 bytes of environment usage.
::: I still have to do "/E:1024" etc. since 4Dos default environment size is 512 bytes. I think it's possible to save a bit more though by using a trick: instead of using %OLDPATH%, save the value of %PATH% to a batch file ("echo set PATH=%PATH >>" etc.) and then run said file after running EnvClean.bat at the end. There's more savings in this approach than just %OLDPATH%, since there are environment variables which tend to exist in DosBox before running xcusetup and can be cleared: %COMSPEC% (unused after DosBox test), %BLASTER% (iff sb emulation is on), %ULTRASND% and %ULTRADIR% (iff gus emulation is on). These can be unset at batch file start to save space and later restored by the temporary batch file. [[User:Cesium|Cesium]] 20:24, 18 February 2010 (EST)
::::All true DOS's only have 512 by default. I had thought about doing something similar with the default.bat and lastop.bat. using a series of of jumps to read it parts and then creating flag files for each setting. This would eliminate the need for most of the environment vars, but it also means another week for the overhaul. --[[User:BladeFireLight|BladeFireLight]] 21:07, 18 February 2010 (EST)
*Xcomutil.txt line 569: Telling the user to reboot isn't the best advice for multitasking OSs... Best to limit that advice to DOS. [[User:Cesium|Cesium]] 21:03, 17 February 2010 (EST)
::: Made sense when it was written. :) --[[User:BladeFireLight|BladeFireLight]] 21:51, 17 February 2010 (EST)

* I'm looking at the autocombat issue you mentioned above. AutoCombat is designed to kill every alien, no mater if they are unconscious. This has obvious issues with Alien Research. --[[User:BladeFireLight|BladeFireLight]] 22:42, 17 February 2010 (EST)

===Build 384===
* Hooray! This build is much better. I did find some stuff on initial check though:
* The number of aliens in the mission report is inconsistent with the number of live aliens captured per research help. See [[Image:Alien_numbers_mismatch.zip]] and [[Image:Dead_alien_count.zip]].
* You can get X-COM MIA if you abort a mission, even if everyone is in the exit. Possibly a second stage bug only? See [[Image:X-COM_MIA.zip]]. Note that this only affects the report - after mission all the X-COM troops are still available.
:* This happens even on vanilla TFTD with that save. Given it's TFTD it could be an issue with the mapfiles. --[[User:BladeFireLight|BladeFireLight]] 00:23, 24 February 2010 (EST)
* Morale is random at start of second stage after autocombat of first stage?
:* Actually Morale is used as the clip size and time units as the weapon damage. Don't ask me why. It would take a major re-write of auto combat to fix this. --[[User:BladeFireLight|BladeFireLight]] 19:34, 23 February 2010 (EST)
* All Civilians are dead if AutoCombat is used to end a Terror mission. It's too not much of a problem, since score is likely to be positive anyway. It would possibly be an improvement to assume all civs from first stage are dead (if ran at second stage) and get a random number (using mission seed) for dead civs at current stage? [[User:Cesium|Cesium]] 07:00, 22 February 2010 (EST)
:* This is odd. Autocombat is supposed to skip over civilians when using the kill function. --[[User:BladeFireLight|BladeFireLight]] 00:18, 24 February 2010 (EST)
::Maybe kill civilians (or not) according to the force ratios. If XCom has only enough force to win the mission, all Civilians are dead. If XCom bring a certain amount of "excessive force", all or nearly all Civilians are saved. By the way I love AutoCombat, it is great for avoiding repetitive combat and only playing the new, interesting bits. [[User:Spike|Spike]] 15:53, 22 February 2010 (EST)

::: Thinking about this, I recalled the scenario where someone fights the mission and uses AutoCombat to hunt the last aliens (another reason AutoCombat is great). Spike's suggestion is better from pure RNG, since in this case probably all civs that were at risk already died. So lets see what we suggest XcomUtil do:

:::* Count civs from first stage if there was one as dead (since IIRC XcomUtil has no memory of first stage when exiting second stage, so we can't take them into account?).
:::* Deduct dead civs from current stage.
:::* Calculate extra dead civs using force ratio to bias the RNG (I prefer merely biasing the RNG rather than precluding results, since Xcom in general has a large variance in almost every gameplay mechanic). [[User:Cesium|Cesium]] 18:27, 22 February 2010 (EST)

* "if %xOS%. == DosBox. if %xOS%. == 4DOS. if %xOS%. == Unknown. dir *.xcf" - this is not an OR statement. This line will simply never be executed. You can use a goto to emulate if/else and to test the condition only once, e.g.:

if NOT %xOS%. == DosBox. if NOT %xOS%. == 4DOS. if NOT %xOS%. == Unknown. goto win
dir ...
goto next
win:
dir /b ...
next:
[[User:Cesium|Cesium]] 07:42, 22 February 2010 (EST)

===Build 435===
: I hope the improved randomness doesn't apply to the Aliens' d100 during AutoCombat. Otherwise, one could load-scum for success. [[User:Cesium|Cesium]] 06:33, 11 March 2010 (EST)
:: Actually it does. I can see what your getting at, but why do it that way. if you want to win the "WIN" command line option is faster and you get better loot from the UFO. also using the combat date would also swing the other way with an unwindable autocombat with an fully loaded avenger vs a survey ship. --[[User:BladeFireLight|BladeFireLight]] 17:41, 11 March 2010 (EST)
: In the setup question for sound files: "were replace" should be "were replaced". [[User:Cesium|Cesium]] 06:53, 11 March 2010 (EST)

Excellent! For the first time xcusetup.bat completed for me in Dosbox in Ubuntu. Previously the SDUMP commands were hanging it.

For the first time ever, I ran the sound setup utility. It did not response to any cursor keys, enter, tab, etc. The only key that worked was Escape, and I'm not sure what this did.

One point on the xcusetup.bat script - Ctrl C does not seem to work. On all those "press a key to continue" prompts could we also have "or 'q' to quit"?

[[User:Spike|Spike]] 18:41, 13 March 2010 (EST)

: "press a key to continue" is the Pause command. Ctrl + C works fine in Windows. DOSBox does not. The reason for the use of Pause is because an number of new players kept exiting setup early when I gave the option. Aborting early makes a mess and I dont want to have to troubleshoot it for Joe user.

==Open Bugs==
*Various second stage bugs - ammo clip recovery, crashes after autocombat of first stage, etc. Mainly for TFTD, but possibly Cydonia in UFO is also affected.
*RPL bug, when you turn creatures into Gill Men, they are reported as Snakemen
:: Reported how? Is this consistent? The name's used are from xcomutil.cfg. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
:::Sorry. It's reported in morale failure pop up messages. Though maybe this is an original TFTD bug rather than an XComUtil bug. [[User:Spike|Spike]] 19:21, 21 February 2010 (EST)
::: See this: [http://www.youtube.com/watch?v=uGlSghf7aTU]. In that case, all Gill man (were lobster man before RPL) were reported as snakemen.. [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST)
*RPL bug, when you turn Lobstermen into other creatures (e.g. Gill Men), they are very hard to kill despite having the stats of the creature they turned in to. Possibly they are keeping their damage resistance? Maybe the race is stored in more than one place, for different purposes, and XComUtil misses one of these places?
:: I will look into this --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: The RPL only changes the basics; The race, rank, name, TimeUnits, Health, Energy, Reactions, Armor(front,back,left,right), Strenght and PSI Strenght. All other stats are left as-is. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
:::: I'm not so sure about this. See 05:00 mark at [http://www.youtube.com/watch?v=y-_zLdjhUHI]. The armour doesn't match the one Gill man should have (per UFOpaedia, at least). [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST). See also 04:17 mark at [http://www.youtube.com/watch?v=z5LfzFSkRnI] for reason to suspect resistances aren't always changed. It's possible he just was unlucky though... [[User:Cesium|Cesium]] 19:53, 21 February 2010 (EST)
::::: Actually the function is something like this
<pre>#define UpdateStat(x,y) pur->x = (unsigned char) \
( ( (unsigned int)pur->x \
* (unsigned int)pasTo->y \
) / (unsigned int)pasFrom->y )
UpdateStat( TimeUnits0, TimeUnits );
UpdateStat( Health0, Health );
UpdateStat( Energy0, Energy );
UpdateStat( Reactions0, Reactions );
UpdateStat( AFront0, AFront2 );
UpdateStat( ALeft0, ALeft2 );
UpdateStat( ARight0, ARight2 );
UpdateStat( ARear0, ARear2 );
UpdateStat( AUnder0, AUnder2 );
UpdateStat( Strength, Strength );
UpdateStat( PsiStrength, PsiStrength );
</pre>
::::: the 0's are values at start of tactical.
::::: I read that as Current(from game_x) * Target default(from xcomutil.cfg) / source default (from Xcomutil.cfg) so the stats will be different. --[[User:BladeFireLight|BladeFireLight]] 21:33, 21 February 2010 (EST)
:::::: I'd have expected Current(game_x) == Source default if applied on first turn? This would end up with result == Target default, no? Hmmm... We already saw some compiler multiplication wackiness with the research help bug. Possibly this affected these calculations too?
:::::: As for the code, you're not updating PsiSkill, so non Psi-users can't get Psi after RPL. [[User:Cesium|Cesium]] 22:03, 21 February 2010 (EST)
::::::: I didn't write this. I'm amusing Scott did it this way to adjust for difficulty because XcomUtil.cfg has the beginner level stats. It need's an overhaul to use the full stat entries including the unknowns adjusted correctly for the level. Something for latter. --[[User:BladeFireLight|BladeFireLight]] 22:09, 21 February 2010 (EST)
:::::::: For this specific issue I think you will need to update 0x37 of [[UNITREF.DAT]] which is the Damage Modifier. In addition to the Psi Strength. Also Firing Accuracy, energy regen rate, movement class... loads of stuff. And of course LOFTEMPS. So with current RPL not changing LOFTEMPS, changed aliens are the wrong size and shape probably. This would be visible using the LOFTEMPS map viewer I suppose. [[User:Spike|Spike]] 18:39, 9 March 2010 (EST)
*[[Known Bugs#XComUtil Inventory Stacking Bug]]
:: I hope to overcome this but Scott's notes point to a technical limitation. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*Removal of Small Scout map / Survey Ship map, making it impossible to do these Battlescape missions.
:: 9.7 only removes the maps if you use the BFG. This will be addressed eventually. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*Was it really intended to '''not''' have nerfed the [[Manufacturing_Profitability#XComUtil_manufacturing_profitability|Profitability]] of the Fusion Ball Launcher along with everything else? More generally, the profit nerfing could be revised to be more orderly and more systematic.
:: I dont really know what Scott intended as for the profiteering off of the changed items. If you want to suggest alternative values I'm open to discussion. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: A preliminary suggestion would be to make the Fusion Ball Launcher similarly difficult to manufacture as the Plasma Beam, so about ten times harder vs the unmodified game. E.g. Workshop space 6 -> 60, 400 -> 4000 Engineer hours. And perhaps require 4 Elerium and 20 Alloys, placing it midway between Laser Cannon and Plasma Beams. These changes (even without the materials) make the FBL unprofitable, like the (modified) Plasma Beam. I'm sure part of Scott's intent was to prevent "Laser Cannon Factories", but "FBL Factories" are 75% as profitable.
::: General reform of the profitability of manufacturing would require a lot of thought. Suffice to say I don't think '''any''' thought went into this for the original game. In reforming the economics of XCom, a basic problem is that realism is at odds with game balance. Realistically, governments would pay handsomely for almost anything XCom can produce. What would be reasonable is to get a moderate rate of return, rising more or less linear with investment (research effort), for ''all'' items. For game balance, this could be tweaked down for items that are useful in the game, or have research predecessors / successors that are useful in the game. A simpler case is to say that no item has negative profit, you can at least get 'cost price' back for it. Aircraft should arguably be in this category (since they would sell for 100s of millions which would be totally unbalancing). A rationalisation for nerfing any prices is that the money received by XCom is not the whole sale amount, but just a small commission paid by the Council of Funding Nations, which actually controls the sales and takes (in exchange for its funding) most of the profits. [[User:Spike|Spike]] 19:40, 8 February 2010 (EST)
:::: FBLs are already pretty useless, and you want to nerf these further? I'd rather think of a way to make them more useful in-game, otherwise the profit should be kept (Note how it's the mostly useless craft weapons which are profitable - I suspect there was some thought into this..). In comparison, the Laser Cannon profit does get nerfed with XcomUtil, but we get a useful weapon instead. I'd suggest a modified FBL will have a very high elerium requirement, and the power of the weapon should be raised a bit to compensate. [[User:Cesium|Cesium]] 20:04, 8 February 2010 (EST)
::::: For example: Raise power to 240, and add another charge (almost enough to sink a battleship if a craft has two FBLs loaded), but make it cost 100 elerium to make launcher. Raise hours for Balls by factor of 10. [[User:Cesium|Cesium]] 20:16, 8 February 2010 (EST)
::: Actually you're right, it makes more sense to make FBLs viable, instead of (just) nerfing the profits. Obviously high Elerium requirements will make them non-profitable. But of the 2 problems - making things useful and preventing 'factory farming' - I think making things useful is more important. I didn't realise FBLs were not tactically useful. I've never built them, only Plasma Beams. 3 ammo is reasonable, it means that 2 FBL armed aircraft have a good chance to take down a Battleship, if they can fire 9-10 out of 12 fusion balls before they are both killed. But 100 Elerium is way too much for an improved FBL that's only slightly more powerful. I think my suggestion (4 Elerium, 20 Alloys, 10x hours, 10x space) fits with the requirements of other XComUtil-modified weapons. Combined with your suggestion of 3 ammo and 240 damage, I think it would make FBLs ''useful'' again, which is one of the original goals of XComUtil.
::: Of course, it's ''possible'' that Scott was cleverly making FBLs useful, by making them so much cheaper (net) to manufacture than Plasma Beams. In an XComUtil modified game, you might well deploy FBLs first, and only work your way up to Plasma Beams later, because of the huge manufacturing costs of Plasma Beams. But personally I think it was an oversight. [[User:Spike|Spike]] 17:21, 9 February 2010 (EST)
:::: I've never played with XcomUtil modified lasers, so if you say this fits in better that's fine with me. It's unfortunate it involves increasing space: inventory management is one of the things I hate about the first two X-Coms. I was hired to be a commander, not a supply clerk! A mod which made general stores have 10000 space (like Apoc) would be nice.. [[User:Cesium|Cesium]] 21:39, 9 February 2010 (EST)
:::: Actually the energy weapon mod means they uses more ''workshop'' space to build but not more inventory space to store.
::::However "An army marches on its stomach ", Napoleon said, by which he meant that wars are won or lost on logistics. Other famous commanders have said similar things. So a general should pay attention to logistics. One of the great things about XCOM is it's not just a tactical game, it's a combined political - strategic - operational - tactical game. [[User:Spike|Spike]] 04:37, 14 February 2010 (EST)
*Zrbite lying around in odd places. Objects lying around in odd places in general - these are map modifying errors, probably only occur when customising terrain etc.
:: Will be part of an overhaul of the BFG --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*Also the '''xcsetup.bat''' prompt for the option of less-profitable weapons manufacturing is misleadingly called "new laser weapons". This should be much more clear eg "Much more difficult to manufacture advanced weapons [except FBLs]" or similar.
:: This seems to be a common complaint. I will look into better wording. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: Actually it might be an idea to break this up into sub-options. It does a lot of things! The "new laser weapons" option requires the use of extra alien materials in order to manufacture almost all energy beam weapons (not just lasers). It also makes the human manufacture of the alien plasma beam small arms impossible (research success merely allows X-COM to use captured weapons). The manufacture of craft Plasma Beams is still possible, but is made significantly more difficult (ten times the labour and workspace requirement as well as additional materials). As Scott says this "seriously changes the economics of the game". It also significantly alters the balance of firepower in the air and (to a lesser extent) on the ground. [[User:Spike|Spike]] 19:40, 8 February 2010 (EST)
*There is a small problem in editing/customising craft using '''XComUtil.cfg'''. Certain X-Com craft weapon values - the rate of fire value - can't be set. Or more specifically, they can be set (patched) in the executable but it has no effect in the game. To avoid confusion they should perhaps be removed from the format of custom craft, or commented out. (This rate of fire patching ''might'' work on UFOs, haven't tested it).
:: Can you be more specific? --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: There is a section in '''xcomutil.cfg''' which is used for patching XCom craft weapon characteristics. This is where Scott changed values for the Laser Cannon, etc. Probably very few people use these fields. I only used them because I was doing research into the game mechanics. One of the values changed in this section is the reload time. These values are present in the executable, and can be patched, but patching them has no effect (other than to change the UFOPaedia entry). The reload time seems to be hard coded elsewhere in the executable, based (broadly) on the class of weapon. So you might want to comment this column with an a note saying "cannot be modified for combat". On the other hand I could be wrong, or someone still might want to modify these fields. Discussion is at [[Talk:UFO_Interception#Observed_Rates_of_Fire]]. Offsets are at [[Talk:GEOSCAPE.EXE#Craft_weapon_stats]]. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
:::: Or maybe change these display-only values so that they reflect the [[Talk:UFO_Interception#Observed_Rates_of_Fire|observed reload rates]]? I am not yet 100% sure I have got these right, might want to wait until I do some more confirmation tests. [[User:Spike|Spike]] 15:26, 22 February 2010 (EST)
*EQL only works on turn 1 (see discussion above)
::: Added to my to do list. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)

*Remove 3rd burst for Pistol - it's already good enough, as NKF has shown
::: do you have a link to NKF's comments? --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:::: Having trouble finding his comments, maybe he'll show up here! See [[Rifle_vs_Pistol]], also [[Talk:Squad_Composition_and_Tactics#Starting_Sniper_Weapon]]. If anything there is a case for the Pistol to be nerfed slightly (eg Damage=20, Ammo=8), or for the Rifle to be buffed. Also worth looking through [[Weapon Analysis]] for general thoughts on weapon power and balance. The weapon set in EU is actually remarkably well balanced already.
::::: Further to this - not a bug but it's really wrong for a projectile weapon, a firearm, to have the same accuracy on Auto as on Snap fire (60). Even plasma weapons have Auto accuracy somewhat lower than Snap. If you reduce the Pistol burst mode accuracy by anything less than 2/3rds, the burst function is still useful, but more balanced. Actually even with a reduction of ''greater'' than 2/3rds, it would be useful, because of the increased damage at point blank range. Which is perhaps realistic for a burst-mode pistol. 60 Accuracy is higher than any Auto weapon in the game, for what ought to be the least accurate auto weapon. The best auto firearm is the Rifle at 35. Anything over 20 is still a bonus for the Pistol. How about 25? This still gives burst mode a 25% edge over Snap mode at long ranges, and a big improvement at close/point blank. 30 would make it more accurate than a Laser Pistol is on Auto (28), which is hard to justify. Admittedly the Pistol burst mode uses 3x (?) the TUs, so maybe some latitude can be given. Maybe go to 30 Accuracy, then, but no higher. [[User:Spike|Spike]] 19:49, 11 February 2010 (EST)
:::::: An interesting idea. Scott felt that this was just to make the pistol useful by allowing three snaps to be treated as one action so you dont deal with Reaction fire. The end results is the massive time units and same accuracy. If I lowered the accuracy I would have to lower the time to. I believe there is a reason the pistol doesn't have full auto in the vanilla game. You have seen a military issue full auto pistol? --[[User:BladeFireLight|BladeFireLight]] 21:15, 11 February 2010 (EST)
: Indent reset! I can't remember what my comments were either, but it's probably has to do with the weapon anaylsis and how useful snap shots already are. 'tis a jolly good weapon. I agree that you can't just make the auto mode identical to three snaps - you've got the added bonus of uninterrupted fire for the first two shots. You need to pay this off either with reduced accuracy or increase the usage cost.
: For consideration, I was actually fiddling with the weapons a few months back and was testing a 10% accuracy burst mode at 15% TU costs. I think 10 or 15 AP damage. Turned out way-way too powerful a weapon (against soft enemies) - and this was on a rookie I just picked randomly. It was probably too fast, but it still worked fairly well at 10% accuracy. 60% accuracy does feel quite high. -[[User:NKF|NKF]] 00:14, 12 February 2010 (EST)
:: Exactly. The point is that a 3-rd burst makes the Pistol more useful, ''even if the per-shot accuracy is lower'', because you get 3 attempts to kill the target before it Reaction Fires, rather than just one. As long as the ''net'' 3-rd accuracy isn't less than a single Snap shot, the weapon has been improved. The break-even point is about 26% accuracy on auto. At this level, 3 rounds have a ~60% chance of getting ''at least one'' hit. Even if the 3-rd accuracy was lower than a single Snap shot, you would still get the advantage of multiple hits at very close range. I would strongly suggest no more than 25% accuracy for Pistol auto burst, at the same level of TUs (3x Snap right?). This will definitely still be a significant improvement for the Pistol. Probably what was not fully understood at the time Scott did the original mod, is that the Pistol is arguably ''already'' the most effective starting weapon, certainly against the initial opponents. [[User:Spike|Spike]] 13:19, 12 February 2010 (EST)

* Fusion weapons inconsistently exempted from the "more difficult" energy weapons manufacturing option ("alternate laser Tech"). Blaster Bombs and Blaster Launchers, Fusion hovertanks and ammo, and Fusion Balls and Fusion Ball Launchers - none of these are harder to build or use with the "alternate Tech" option. Why make laser weapons/tanks and plasma weapons/tanks harder but not Fusion weapons? It's not consistent. I wonder if Scott didn't look at these because he never used Blaster Launchers or Fusion Hovertanks, as he considered them to unbalancing already? And ignored FBLs because, well, most people ignore them? But this should be consistent. Or, the "harder weapons" option could be broken down into sub options, e.g. for each weapon technology:
** Much more expensive (typically: add some exotic materials, 10x workshop space and 10x Engineer hours)
** Can/can't manufacture the battlescape weapons/tanks (pure alien weapons only)
** Can/can't manufacture the ammo (pure alien weapons only)
:Personally I would prefer it to be all-or-nothing but include the Fusion weapons as being more difficult to make and use. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)

* SteamSetup.bat won't run from DOSBox. It says "This needs to be run from Windows". Though, does it make any sense to run SteamSetup.bat under DOSBox (eg for a linux system with no Steam)? [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)

* It's actually quite hard to downgrade to DOSBox 0.72 in Ubuntu. Only 0.73 is offered, there is no ability to Force back to a lower package level with Synaptic Package Manager. Unix guru skilz are required to rollback to 0.72, and I guess 0.74 is not around yet, or not packaged for Ubunut APT? Is there any way to fudge around this, e.g. by providing the command line arguments in an optional text file for xcusetup.bat to parse? Having said that, even with no command line arguments, xcusetup hangs on my 0.73 DOSBox while executing SDUMP. I had to reboot in Windows to run xcusetup.bat - something that is only possible on a dual boot machine / Wubi machine. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
** Try using a different batch interpreter like 4DOS [http://www.4dos.info] to execute xcusetup inside DosBox. I tested this throughly before under DosBox/Linux and it works well with recent 9.7 builds. I suggest running "config -set cpu core=dynamic" and "config -set cpu cycles=max" before xcusetup to speed it up (xcusetup doesn't detect DosBox when 4Dos is run, so it doesn't run these automatically unlike normal DosBox case). [[User:Cesium|Cesium]] 09:48, 7 March 2010 (EST)
** Oh, and downgrading isn't that difficult: Get a dosbox 0.72 deb, and run "dpkg -i" on it, and then do "echo dosbox hold | dpkg --set-selections" to prevent future upgrades. [[User:Cesium|Cesium]] 09:50, 7 March 2010 (EST)
** Another option is to install the dosemu package, and run xcusetup under that. EU/TFTD can be run under that, but it doesn't work as well there. (Oh, and there's no mount command there. UFO/TFTD needs to exist under ~/.dosemu/drive_c which is C:) [[User:Cesium|Cesium]] 11:42, 7 March 2010 (EST)

:Thanks Cesium I will check this out. I still think it would be good to have a solution that works for people who are not knowledgeable with the unix command line though. [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)

:: Why use Linux if you dont know how to use the console? It is a text mode OS with a separate GUI. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)

::: Well Ubuntu is a bit different, as it's supposed to be an OS for the general public, where you never need to touch text mode! Incidentally I can't find any DEB or other packages for 0.72, all that is available on the DOSBox website is the source code. They really don't seem to realise that 0.73 is buggy! So I guess I will need to '''make''' it. Or just wait for 0.74 as I think it's out soon. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)

:::: See [http://archive.ubuntu.com/ubuntu/pool/universe/d/dosbox/] for 0.72 debs. Unlike Windows, package systems in Unix land are centralized, so best location to search is typically a package server mirror or a distro mirror, not a vendor's website. [[User:Cesium|Cesium]] 17:36, 9 March 2010 (EST)

* '''cfg/ShipDefU.txt''' has the XCU values for improved Laser Cannon (35/35/35), not the original values (21/35/70). Is this correct - is this file supposed to be the original defaults? [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)
:: I was unawhare that this had been changed. The weapons are not prompted for any change so they should not be changed. I'm reseting them all to defaults and looking to see if Scott had anything about them in the notes. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)

=== AutoCombat issues ===
* Day vs Night
** The Day/night algorithm breaks. For example, at any point when XCom has more than twice as many flare-carrying soldiers than there are remaining aliens, XCom is actually ''stronger'' in darkness than it would be in full daylight. Toward the end of a battle this is a very common situation. But fixing the algorithm is tricky. What might work is to give -10 for each Soldier in darkness, reduce from -20 to -10 for each Alien in darkness, then add back +10 for every soldier with a light source. Thus there is no way XCom can go 'net positive' from light sources.
:: If you have more units then they do you can see more of the battle field. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:::It never makes sense for XCom to be stronger at night, than during the day, for the same force ratio. But that is what happens. An example. 10 XCom soldiers with flares and 3 aliens. At night there is an extra -30 modifier for the aliens, but a +100 modifier for XCom, net +70. The same 10 soldiers against the same 3 aliens are +70 ''more'' effective in darkness than they would be in daylight. It does not make any sense. [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
** The definition of a light source should be expanded to include a Flare ''or'' an Incendiary weapon. In fact, one Incendiary-capable weapon of any type (AC/HC/HjC/GC), with appropriate Incendiary rounds carried, should be enough for the entire squad to be considered as having a light source. But this may be hard to implement without a special flag and a special pre-search for a valid Incendiary weapon, since AutoCombat normally scores by individual soldiers, not by whole squads.
:: This would take a rewrite. currently the ammo is not used by W: --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
** To be honest I would prefer that each soldier without a light source in darkness is 50% effective, each soldier with a light source (personal or squad), is 75% effective. Meanwhile how about this:

//Darkness
-10 L:-9 u:-2 // Human in Darkness

+10 L:-9 u:-2 W:-27 U:- // Human in Darkness w/Flare -OR-
+10 L:-9 u:-2 W:-4 W:-7 U:- // Human in Darkness w/In ammo and launcher HC/GC-IN -OR-
+10 L:-9 u:-2 W:-8 W:-11 U:- // Human in Darkness w/In ammo and launcher AC/HjC-IN -OR-
+10 L:-9 u:-2 W:-12 W:-15 U:- // Human in Darkness w/In ammo and launcher IN Rkt/Torp

-10 L:-9 u:4-14 // Alien in Darkness
:: Only thing I see is that this ''must'' come at the end. The U:- removes the unit from further consideration. --[[User:BladeFireLight|BladeFireLight]] 19:58, 9 March 2010 (EST)
::: Yes, to use the U: flag for this "OR" function, it must come at the end of the section for humans. That's how I have it my updated AutCombt.txt, these fragments are a bit out of context. It's not critical to have the "OR", it's just nice-to-have as it stops someone cheating by having a flare and one of each loaded incendiary launcher weapon in each hand and in their backpack, to get quadruple score. But hopefully people are unlikely to cheat at AutoCombat, there are easier ways such as the WIN flag. [[User:Spike|Spike]] 20:39, 9 March 2010 (EST)
* The Zombie is rated the same as a tank, a Chrysallid/Tentaculat or an effective Psi alien (-50). I think this is too high, as Zombies are much weaker than those units. A Zombie should be maybe -25.
: Disagree. the zombie should be slightly higher then a Chrysallid/Tentaculat as it will become one and you have to kill it twice. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:: OK good point! [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
* Area effect weapons (HE, IN, Small Launcher) should have at least the same bonus as effective-on-Auto weapons (+5). This is because they can damage/kill multiple targets. (The AC/HjC should not get both bonuses however.)

//Area Weapons. ToDo: compensating bonus for aliens. should not be cumulative. check if "effective?"
+5 u:-2 W:-4 W:-6 // Human w/HE ammo and launcher HC/GC-HE
+5 u:-2 W:-8 W:-10 // Human w/HE ammo and launcher AC/HjC-HE
+10 u:-2 W:-12 W:-13 // Human w/HE ammo and launcher Sm HE Rkt/Torp
+10 u:-2 W:-12 W:-13 // Human w/HE ammo and launcher Lg HE Rkt/Torp
+10 u:-2 W:-42 W:-43 // Human w/ Stun/Shok Launcher and ammo
+25 u:-2 W:-40 W:-41 // Human w/ Blaster/DP Launcher and ammo

-10 u:4-14 W:-42 W:-43 // Alien w/ Stun/Shok Launcher and ammo
-25 u:4-14 W:-40 W:-41 // Alien w/ Blaster/DP Launcher and ammo

::Having tested the first 2 rules, the first rule (HC-HE) does not work unless you remove the ammo specifier W:-6, making it just a test for an HC. But weirdly the second rule (AC-HE) works fine with its ammo specifier in place. Odd. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
::: The problem was due to [[Known_Bugs#Equip_Phase_Ammo_Load_Error]]. Ammo loaded into a weapon by the game automatically prior to the equip phase is not caught by the W: function. When the ammo is loaded manually, both rules works fine. [[User:Spike|Spike]] 18:16, 13 March 2010 (EST)

* Pistols with the burst mode option should not count as Auto weapons (maybe they don't).
: Burst and snap are based on default stats --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
* Blaster Launchers / DPLs (with ammo) should be worth as much as a tank, e.g. +/- 50 (including the single shot effective bonus it should already get - see suggested rule above under area weapons)
* Should distinguish between tanks. Even with improved armour, a Tank/Cannon is not the same as a Fusion Hovertank. I would suggest a range of 25 for a Tank/Cannon to 75 for a Hovertank/Fusion. Maybe 40 for a Tank/Rocket, 50 for Tank/Laser, 60 for a Hovertank/Plasma?
:This does not seem to be possible with the existing ruleset as all Tanks are unit type 3
::Hmm, byte 42 of [[UNITREF.DAT]] is Rank but also Tank chassis. So this ''might'' allow distinguishing tracked tanks from hover tanks, at least. An alternative approach would be to pick some stat (that has a StatStrings statid) and set it to a different unique value for each tank type. [[User:Spike|Spike]] 18:32, 9 March 2010 (EST)
::This rule set might work:

// Tanks - distinguish chassis types.
+40 u:3-3 R:0-0 // Tank, Tracked (Cannon, Rocket, Laser)//To Test
+60 u:3-3 R:1-1 // Tank, Hover (Plasma, Fusion) //To Test

* Flying units (either side) should be worth say +/- 5
:Not possible for XCom as no statid makes a distinction between Power Suit and Flying Suit. Would be possible for aliens eg:

-5 T:0- u:6-6 // Flying Alien - Ethereal
-5 T:0- u:8-8 // Flying Alien - Floater
-5 T:1- u:13-13 // "Flying" Alien - Hallucinoid
-5 T:1- u:11-11 // "Flying" Alien - Tentaculat

* If the squad is carrying some Smoke or Dye that should be worth maybe +5 - +10. But since the aliens don't ever carry that, you need some balancing factor for them.

+1 u:-2 W:-20 // +1 per human with smoke grenade(s) (hopefully not +1 per grenade!)

* Effective melee weapons should be counted. This is particularly important in TFTD when ranged weapons may be ineffective, e.g. vs Lobstermen.
* Similarly if the enemy are in heavy armour and therefore a soldier/alien does not have an effective weapon, any HE Pack / Alien Grenade / Sonic Pulser should be counted for something (if it is "effective").

//Melee weapons
+5 u:-2 W:1- W:-26 // Human w/o effective ranged weapon but w/ Stun Rod
<s>+5 u:-2 W:3-26 // Human w/ effective Stun Rod (cumulative to above)</s>

::The second rule doesn't work at all, it looks like it counts all items of types 3-6. The "superiority" function (first value before the hyphen) does not seem to operate, probably because it is a melee weapon. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
::: did you try W:255-26 ? not that I know if it would work. AutoCombat doesn't recognize stun rods as weapons when applying damage.--[[User:BladeFireLight|BladeFireLight]] 21:01, 9 March 2010 (EST)
:::: OK, if AutoCombat rates stun rods as doing no damage, the lower range of the W: function ("superiority") will likely never work. So we can't tell whether or not a Stun Rod is "effective" vs the current enemy. In general, the Stun Rod is a pretty effective weapon. So instead we generalise and just use something like this rule set:

//Melee weapons
+5 u:-2 W:1- W:-26 // Human w/o effective ranged weapon but w/ Stun Rod
+5 u:-2 W:-26 // Human w/ effective Stun Rod (cumulative to above)

//It would be nice if AutoCombat checked for the presence of Stun Rods and used them to increase the chance of an alien casualty being stunned rather than killed.

//To Do: check if TFTD melee weapons are included in "effective" weapons by the W: statid.

//Grenades
+5 u:-2 W:1- W:-19 // Human w/o effective ranged weapon but w/ effective grenade(s)
+5 u:-2 W:1- W:-21 // Human w/o effective ranged weapon but w/ effective prox grenade(s)
+5 u:-2 W:1- W:-22 // Human w/o effective ranged weapon but w/ effective HE pack(s)
+5 u:-2 W:1- W:-44 // Human w/o effective ranged weapon but w/ effective Alien grenade(s)

-5 u:4-14 W:3-44 // -5 per Alien with effective Alien Grenade(s) (hope not -5 per grenade!)
:: Only one per unit. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)
::: Tested ok too! [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
* AutoCombat victories should award all UFO Components, not just some Navigation, Elerium and Alloys.
* Every Civilian on the map should be a penalty to XCom of maybe -5, due to the distraction effects of trying to save them / avoid killing them.

-5 u:15-16 U:- // Civilian distraction effect, no further effect

Let me know if I should try to work some of this up as AutoCombat rules. Some of it requires new coding of course, but a lot of it could probably be done with existing rules. [[User:Spike|Spike]] 13:15, 7 March 2010 (EST)
: I dont plan on any changing to the underlying code yet. Your welcome to make up a new set of rules and testing them out. --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
:: OK added some rules above. I have not tested them yet, some of the syntax might not work. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)
::: Syntax looks good to me. Give them a test and let me know how they go.
::: Just a quick note on how AutoCombat works. First the success percent chance is calculated using the AutoCombat StatStrings, dead and unconscious units dont count. (those that bleed to death are considers alive, need to fix this). If it's below AbortThreshold it aborts. If it's 100-199 then change to 90. 200+ change to 95 (success is never a guarantee.) Aliens roll d100, if over your success chance you lose. If You win. Then average damage by each side is calculated based on Loaded weapon being carried and time units. All aliens are killed or stunned by X-Com unit chosen at random. Each Alien gets a chance to wound an X-Com unit based on Success Percentage. Randomly choose unit using random damage (max is average alien damage) Leave at least one X-Com Unit alive. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)

==Fixed Bugs==
* standalone patches the fix the difficulty bug
::9.7 min install is the dificulty patch and changeing Copy protection questions to all 0's.
*Prompted Terrain displays the options but the prompt doesn't display until after a key press.
:: I guess Open Watcom's version of printf does not auto flush to the screen like Borland did.
*Version detection issues with obscure versions (Italian, 1.2a, etc.) causing corruption or lack of patching.
:: Cesium; XcomUtil doesn't have the offset for the copy protection for the Italian version coded. However the file you sent me is detecting as 1.3. none of the offsets will line up. The offsets Scott used to detect Italian are unique and may have been based on 1.0 or 1.2. Was that a clean unmodified copy? I need a clean one to validate all the offsets and update XcomUtil. --[[User:BladeFireLight|BladeFireLight]] 13:23, 16 February 2010 (EST)
:: I loaded it up and notice it does not ask for a language. this would imply it's based on X-Com 1.3 and not UFO 1.3. --[[User:BladeFireLight|BladeFireLight]] 13:33, 16 February 2010 (EST)
::: I didn't send you the installer since it's a mess (it requires some subst magic to work), but it looks authentic. Use the same link as before if you want to take a look at the installer. There's an Italian readme attached which points to some (now defunct) Italian sites. I didn't do any changes besides installing X-Com and then testing out XcomUtil. [[User:Cesium|Cesium]] 14:01, 16 February 2010 (EST)
:::: Italian UFO detection and offsets added, 1.2a offset's fixed.

*Various default options make the game easier, not harder (''harder'' being the intent of XComUtil, right?). These should not be defaults. (More discussion at [[Talk:Enemy_Unknown_Extended#Standard_Config_Discussions]]) E.g.
::: 9.7 only has 3 items on by default. Remove copy protection. Fix Difficulty bug and Split EXE (split EXE can be skiped but not the others). All other options are default to NO.
::: As for the intent of XcomUtil. Scott added features to
:::# Increase difficulty.
:::# Make useless items useful.
:::# Get the game Started faster.
::: I have added:
:::# Don't make unwanted changes.
:::# Fix game bugs
:::::Yes all of those are very sensible. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
::::Latter versions of XcomUtil will turn the last two forced items to prompted. with only the Difficulty bug and the split EXE as Default=Yes. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
**Basic tanks using advanced tank stats
**Improved High Explosive - very powerful in favour of X-Com, especially as alien spawn points and routes aren't set up to cover holes in UFO hulls.
**Gauss weapons have infinite ammo
::: 9.7 has a second option to just the increase power to closer match UFO.
**Using fighters as transports (carrying soldiers)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
**Using transports as fighters (weapon hardpoints)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
**Improved Heavy Laser / Heavy Gauss. OK, this should maybe be a ''recommended'' option since the unpatched weapons are nearly pointless. But, it does make the game easier.

[[User:Spike|Spike]] 20:12, 7 February 2010 (EST)

=XComUtil Wish List=
Things that are not bugs or inconsistencies in XComUtil but would be Nice To Have

== Features for 9.7 - Interface, consistency and bug fixes ==

=== Categorise Config Options ===

For each option, in the prompt, note which category of option this is, according your list above. E.g. faster start, making the game harder, making useless items useful, bug fix, variant game, etc. [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)

:Actually it might be even better to organise the options questions into sections, thematically grouped by these categories. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

:: Items are currently sorted like this.
* Windows EXE
* Game Fixes
* Game Mods
** Sound
** Craft
** Base
** Equipment
** Research
** Units
** Battlefield
** Alien Craft
** Misc
--[[User:BladeFireLight|BladeFireLight]] 19:25, 10 March 2010 (EST)

=== Improved Base Comes At Cost ===

The Improved Base is supposed to be a "faster start" option rather than a "make the game easier" option. But it does make the game easier, not least because it gives you a load of free base facility improvements. (Not to mention not having to struggle along the first month with only Small Radar and no Alien Containment) To partly avoid making the game easier, please add a sub-option that subtracts the cost of the extra facilities from your starting cash. This should be the ''full'' cost of the extra facilities, not just the difference between e.g. a Small Radar and a Large Radar.
[[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
: I dont have the offsets to the starting money ranges. so I cant do this. --[[User:BladeFireLight|BladeFireLight]] 19:13, 10 March 2010 (EST)
:: I never realised that the starting money is slightly random, I see ranges from $4,125,000 to $4,153,000, in ten samples. Does not seem to depend on Difficulty or starting base location. That is going to be a hard offset to find. [[User:Spike|Spike]] 20:36, 11 March 2010 (EST)
::: I believe there is no "starting money" anywhere to be found, or rather the starting money is effectively zero but it soon changes: the first thing the game does when you begin a new game is perform a hidden monthly report which grants you money from the funding nations. Only way to decrease it is to lower your rating toward countries (you should be able to hack the starting diplomacy data located at 0x4728F8). Or I could just patch the initial money to be negative instead of zero thus providing lower overall starting money. [[User:Seb76|Seb76]] 15:52, 12 March 2010 (EST)
:::: That makes a lot of sense. The initial money is the same as the initial funding. Doh! I should've realised that. The solution to poke a negative number into the money field, prior to the "hidden funding round", sounds a great idea.
:::: Looking at initial money vs funding, your initial cash is always $1,860,000 less than your initial funding. This $1.86M is probably made up of the first 3 rows (only) of your initial Monthly Costs: $500K transport rental, $1200K Interceptor rental, and $160K salary (not hiring fees) for 8 Soldiers. The salary (and hiring fees) for 10 Scientists and 10 Engineers are ignored. The Base Maintenance costs, $224K for a standard starting base, are also ignored. This generosity saves you at least $774K. Could this be considered a bug? Possibly.
:::: The cash value of the XComUtil Improved Base is a whopping $4.5M. This is $1.6M of facilities (Alien Containment, Large Radar, 2nd Living Quarters) and $2.9M of personnel (+10 Engineers, +40 Scientists). $4.5M would wipe out all starting cash and players would begin the game with a negative balance - quite challenging! For XComUtil, it might be best to break improved Facilities and Extra Starting Personnel into 2 options, with each having a sub-option to pay for the improvements. ''"These extra facilities/staff would cost $1.6M/$2.9M, do you want to deduct that amount from your starting cash?"'' [[User:Spike|Spike]] 20:48, 12 March 2010 (EST)

=== BFG Default To Unchanged ===

Is it possible when using the BattleFieldGenerator, for it to detect the actual conditions for the mission (terrain, enemy craft, and light level) and offer these as defaults? [[User:Spike|Spike]] 08:22, 13 February 2010 (EST)
:Press The esc key at the prompt. (Line 719 in Xcomutil.txt, not that I expect anyone to read the manual :) ) Enter should also work. --[[User:BladeFireLight|BladeFireLight]] 12:34, 13 February 2010 (EST)
:: RTFM eh? My biggest failing. Maybe you could add an explicit prompt "Esc or Enter = [whatever the unmodified value would be]". [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)
::: From what I can see, hitting Escape during BFG makes it continue with ''all'' values reverting to the original conditions. It would be nice to be able to select some but not all original conditions. My main use of this is to turn a night mission into a day mission without the hassle of keeping the landing craft hovering around until the terminator crosses the landing site. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
:::: You could just use the force all daylight option.
:::: After reviewing Scott's code. Esc leaves all setting as-is. Pressing enter or any other key not listed will randomly choose for you. I will see if I can change enter to leave as is. --[[User:BladeFireLight|BladeFireLight]] 11:00, 7 March 2010 (EST)

== Features for 9.8+ - New features ==

=== AutoCombat ===

==== Firepower Factors ====
You might want to consider replacing the weapon offensive weighting factors for Autocombat with some factors that are (inversely) related to the [[Weapon_Analysis#Quantitative_Analysis|% TUs Per Kill]]. I've tabulated these for each weapon (including tanks) vs each alien race. You would still need to account for Psi, light/darkness, and XCom armour. Plus you would need a similar offensive factor for the aliens' attacks. But I could probably help with that, I have the data that's directly comparable to the % TUs per Kill for XCom weapons. [[User:Spike|Spike]] 22:06, 12 February 2010 (EST)

==== AutoWithdrawal ====

One of the most tedious things you can try to do in XCom is to scavenge the battlefield and retreat to landing craft for an Abort. A great option would be an AutoWithdrawal, similar to an AutoCombat, but with an easier threshold of XCom vs Alien combat power.

Basically it would scavenge all loose equipment off the Battlescape - dropped friendly and alien items, friendly and alien corpses and wounded, all go back into the landing craft. Elerium, Alloys, and UFO Components would not be recovered, as this is (normally) impossible apart from full tactical victory. All friendly troops return to the landing craft. Friendly losses, and equipment recovered, would be proportional to the offensive factor ratios but much more favourable than for AutoCombat. E.g. as long as XCom factors were at least equal to Alien factors, they would be able to scavenge everything and recover without casualties. If the aliens were stronger than XCom, they would only recover part of the scavenged equipment, and risk partial casualties, at say one third the rate of AutoCombat. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

: It's too easy compared to actual game IMHO. Every time a battle went FUBAR for me, it got FUBAR all the way and I was lucky if I could salvage my own team/equipment and maybe a single alien weapon/body. An AutoWithdrawal without salvage might be useful, but perhaps instead we should change AutoCombat failure mode to work better (e.g. Make some X-COM people survive a failed AutoCombat, depending on strength vs aliens). [[User:Cesium|Cesium]] 15:00, 7 March 2010 (EST)

:: Yes fair point. I was not thinking of the FUBAR situations, and you are right about how hairy those are. I was thinking of the situation where you control a certain part of the battlefield, but you either don't want to go on an endless hunt for the last few aliens, or you pretty much know you can't take on the aliens that are left (e.g. in the UFO or some other stronghold) without getting creamed. You can exercise a safe withdrawal, it's just tedious to carry out all the bodies and equipment. But it's pretty hard for an AutoCombat algorithm to detect which of those situations it is - FUBAR, boredom, or tactical withdrawal. I'll have to think about that, there may be no realistic solution at all. And there is the existing "teleport loose items back to base" command line option to XComUtil, maybe that's enough. [[User:Spike|Spike]] 16:08, 7 March 2010 (EST)

=== Tougher UFOs ===

[[Wish_List_(EU)#Tougher_UFOs|Tougher UFOs]]
As this is entirely implemented by patching data and data files it is a good candidate for XComUtil rather than [[UFO Extender]].
: That would definitely make the game harder. 9.7 is about the installer and the bug fixes. This would be a good candidate for 9.8. --[[User:BladeFireLight|BladeFireLight]] 01:38, 19 February 2010 (EST)
:: Cool! [[User:Spike|Spike]] 02:25, 19 February 2010 (EST)

=== Rebalanced Craft Weapons ===

This fits under the "making useless things usefull" category. It would be a 9.8 or later option. The idea is to make the Cannon, Stingray, Laser Cannon and Fusion Ball Launcher useful. Hopefully it breaks up the monotony of Dual Avalanches followed by Dual Plasma Beams, every game.

There is one common element in the approach, and two options. The common element is to fix the stats on the Fusion Ball Launcher. The two options are to use a stat-based approach, or a cost-based approach, to fix the other weapons.

NB This proposal is still a draft and will need tweaking, but I've got it to the point where it is worth discussing. Feedback is welcome!

''(Ultimately, the Plasma Beam still ends up being pretty much the optimum weapon in the end game. To mitigate this, it is a good idea to select the existing Alternate Energy Weapons Manufacturing option in XComUtil.)''

==== Fusion Ball Launcher ====

Increase the ammo capacity from 2 to 3. Don't mess with the damage. Job done.

See [[User:Spike#Fusion_Ball_Launcher]] and discussions linked from there.

==== Cost Based Approach ====

This uses historically realistic costs to restore game balance between different craft weapons. The stand off advantage of Avalanche missiles is now purchased at a price which is significant in terms of XCom budgets and mission yields. Stingrays and Cannons become significantly cheaper alternatives. The Laser Cannon, with similar capabilities to Stingrays but free to operate, also becomes very attractive. Mounting dual launched weapons becomes a very expensive luxury.

*Increase Avalanche missile Purchase cost to $386,000
*Increase Stingray missile Purchase cost to $125,000
*Leave Sell prices unmodified (to avoid creating a cash reservoir at the start of the game)
*Leave Launcher buy/sell prices unmodified

See [[User:Spike#Cost_Based_Rebalancing]]

==== Stat Based Approach ====

This provides a benefit trade-off to shorter range weapons, by increasing their firepower or effectiveness relative to longer range weapons.

*Increase Cannon stats to 15 Damage, 50% hit. Firepower is tripled, slightly ahead of (unmodified) Avalanches launching in Aggressive mode. Increase rearming rate to 200.
*Increase Stingray accuracy to 80%. Decrease Avalanche accuracy to 60%. Stingray now has 50% more firepower relative to Avalanche. Increase Stingray rearming rate to 2, so a full craft can be re-armed in the same time period with either weapon (instead of twice as long for Stingray).
*Increase Laser Cannon stats to 100 Damage, 50% hit. Firepower is doubled, 20% more than (unmodified) Avalanches launching in Aggressive mode, 2/3rds of Plasma Beam firepower.

To avoid advanced XCom aircraft exploiting the extra firepower of the Cannon weapons and disregarding the return fire from UFOs, this is best used alongside the Tougher UFOs option.

See [[User:Spike#Stat_Based_Rebalancing]]

=== Rebalanced Infantry Weapons ===

See [[User:Spike#Balancing_Infantry_Weapons]]

Primarily this means making the Rifle a bit stronger, and probably making the Pistol a bit weaker.

==See Also==

[[Wish List]]

= Completed Wish List Items =

==Easier Inventory Management==
Inventory management is one of the things I hate about the first two X-Coms. I was hired to be a commander, not a supply clerk! A mod which made general stores have 10000 space (like Apoc) would be nice.. [[User:Cesium|Cesium]] 21:39, 9 February 2010 (EST)
: The manager of any facility has to deal with generalities of space issues. The clerk tells you if that fancy new tank you just bought will fit. He has to put it in storage and keep track of what shelf the ammo is on. --[[User:BladeFireLight|BladeFireLight]] 22:27, 9 February 2010 (EST)
:: That's the clerk's problem and if he complains too much I'll have him peel potatoes until his hands drop. In any event, the limit doesn't make any sense:
::* General stores size is 8x8x2 (8x8x3 in TFTD) per base defence map, and should have no problem storing more than 50 items.
::: The items taking up 1 item unit are typically about the size of humanoid body. I think it's not unreasonable to have no more than 50 of those in the area that the General Stores takes up.
:::: I can't find a list on the wiki of storage space requirements for items, so I'm not sure which items take up 1 item unit. Typically the main space wasters are Heavy Plasma ammo/Blaster Bombs/Stun Bombs (late game) and/or HWPs and avalanches (early game). These either are definitely not the size of a human body (ammo/Bombs), or shouldn't be stored in stores at all (HWPs gain nothing, and might as well lay around somewhere else in base).
::* The size of a fully built X-Com base is about the size of a city block (judging by comparison of base defence to terror missions), and should easily be able to hold hundreds of items even in the starting base if it's willing to put some stuff not in the general stores.
::* The space limit makes no sense. Why do Blaster Bombs and Heavy Plasma ammo take so much space whereas in the inventory view it doesn't take any more than normal ammo? Who stores <s>mini tanks</s> HWPs in the same compartment as light weapons? And the way X-Com (probably) stores ammo and explosives is scary...
::: As you suggest, extremely powerful ammunition probably requires a lot more space for safe and secure storage in-base, versus on a tactical mission. Imagine what would happen if a Blaster Bomb exploded in a base? Or was stolen? They probably use nuclear warhead style storage facilities for those. And similarly for Avalanche warheads, alien artifacts, Elerium, etc. Segregating dangerous/explosive items from other items probably uses up a lot of overhead in the construction of the storage space - think armoured, bomb-proof lockers and bulkheads, advanced security systems, airlocks, scanners, etc. This is not just like piling stuff up in your shed! And the Commander who left Elerium or Avalanche warheads lying around in his hanger or corridors would justifiably be sacked on the spot by XCom High Command. [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Well, judging by all the explosives in the hangar during base defence and the X-COM 1.0 Elerium bug, Elerium and explosive warheads ''are'' lying around in the base... And all the equipment in the General Stores is stored in ordinary lockers according to the General Stores map ;-) More to the point, if X-COM wants to store explosives safely (judging by said warheads X-COM doesn't care too much) they need a special facility for this, not to store them in the room which also contains all the base's weapons and priceless alien artifacts.

:::: Furthermore, I expect X-COM to improvise on storage in the interest of actually winning the war. X-COM does do this and ignore the limit when manufacturing stuff in-base or getting loot from missions. All that's needed is that X-COM will improvise for transfers too. I can't imagine a quartermaster informing the commander there isn't any room for the new armour and that the troops should go without. Maybe the reason X-COM doesn't pay quartermasters each month is that they keep getting themselves lynched by enraged X-COM troops...
::* Gameplay wise, inventory micromanagement is just no fun, especially in the late game when you have all the cash you need but still has to sell stuff after each combat (which can be prolonged if you haven't sold for awhile), otherwise you can't transfer items to the base where your main team is at.
::* Maybe this entire "stores" thing is a plot by the CFN to force X-Com to share its technology with them by forcing X-Com to sell sell sell. It's not like they pay X-Com the real worth of the technology anyway. [[User:Cesium|Cesium]] 23:47, 9 February 2010 (EST)
::: I think a lot of people do find the inventory management tedious, or unrealistically low. Personally I think it's about right for large equipment (missiles, tanks, bodies), but too low for small arms and personal equipment. And yes, it only reflects using the General Stores modules, not storing stuff at random points in the base - maybe fair enough. If the right offset to patch can be found, the storage limits could easily be raised. The last few bytes of [[BASE.DAT]] could be a good place to look for this offset. BASE.DAT can store up to 9,999 units of each item per base. The total limit for items per base would need to be found by experiment, but 9,999 might work for those who want to ignore inventory. For those who feel inventory management is OK but the limits set too tight, the capacity of each General Stores could be increased from 50 to 100 - assuming we can find the offset for this to patch it. [[User:Spike|Spike]] 19:50, 10 February 2010 (EST)
::::Maybe you can try there:
.text:00439C85 66 81 C5 F4 01 add bp, 500
::::[[User:Seb76|Seb76]] 13:03, 11 February 2010 (EST)
::::: Yes that works nicely. E.g. patch '''66 81 C5 E8 03''' at that location and you get 100 space per General Stores. Thanks Seb! [[User:Spike|Spike]] 18:21, 13 February 2010 (EST)
:::::: Now if only I had the offsets or search signature so we can add that as an options --[[User:BladeFireLight|BladeFireLight]] 18:24, 13 February 2010 (EST)
::::::: UFO 1.4 dos: offset 143748. TFTD 2.1 dos: offset 178462. TFTD v1 dos: offset 176861. TFTD CE: offset 252795. UFO CE: offset 236680. (all offsets are in decimal and point to the "F4 01" value to be patched).
::::::: Patching to "E8 03" has been tested on dos versions (not on CE) and it works. The "base information" screen will display the correct value, though the values to line length scale is such that the line will max at 250. [[User:Cesium|Cesium]] 05:57, 14 February 2010 (EST)
::::::::Are the preceding bytes the same from TFTD 1 and 2x? --[[User:BladeFireLight|BladeFireLight]] 17:26, 15 February 2010 (EST)
::::::::: Yes they are. '''81 C3 F4 01''' is the add instruction. [[User:Cesium|Cesium]] 17:48, 15 February 2010 (EST)
::::::::: Sig for UFO Dos is '''81 C6 F4 01''' --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
:::::::::: Do you also have the preceding bytes for UFO? with the signatures I can create a patch file for all versions --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
::::::::::: I am not sure I understand your question.. Judging the the two UFO versions I have available (1.3 per xcusetup and 1.4) the common preceding bytes are ''80 78 16 07 75 0C 80 78 3A 00 75 06'' (followed by the sig). You could try to use the sig alone - it exists only once in the file. [[User:Cesium|Cesium]] 19:35, 15 February 2010 (EST)
:::::::::::: Offset Locations are something I'm collecting but also the unique series of bytes to find them for the two geoscape/tactical that I dont have. (UFO Spanish, TFTD Italian) I hope to add a lot more options in the in the future. I do feel this one nerfs the storage system anything to get the game up and going faster is always a plus. --[[User:BladeFireLight|BladeFireLight]] 22:01, 15 February 2010 (EST)
::::::::::::: Well, you may want to add another General Stores to the improved starting base if you want to achieve the faster startup effect without "nerfing" storage system for rest of game (I prefer a "nerf" due to late-game reasons). Also, I suggest you add an message in Xcusetup to ask people to get in contact with you if they use an unknown/unrecognized version. [[User:Cesium|Cesium]] 14:27, 16 February 2010 (EST)
::: Inventory management is just as much a pain in the early game, where you almost always are out of space until your 2nd general stores is built. I like realistic constraints, but not tedium. Maybe upping the space per Stores from 50 units to 100 units would be a generally acceptable approach (now that Seb76 has kindly found the offset)? [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Yeah, that would be a great improvement. [[User:Cesium|Cesium]] 15:45, 13 February 2010 (EST)

:I can confirm Seb76 is correct, as ever. The 2 bytes at offsets '''0x39c88''' and '''0x39c89''' in geoscape.exe code for the capacity of each General Stores. Default value is 500 ('''F4 01''') which equates to 50 in-game internal capacity units. (Smallest item uses 0.1 in game capacity so I guess that is 1 unit in internal units). I am not sure about a signature. From what I can tell, the preceding bytes '''66 81 C5''' are unique in geoscape.exe, which seems pretty odd, so someone else should verify that. [[User:Spike|Spike]] 19:48, 13 February 2010 (EST)
:: Yes it is unique to CE. it does not exist in any DOS EXE, but "F4 01" can be found in 79 places. Trial and error could locate it. --[[User:BladeFireLight|BladeFireLight]] 20:50, 13 February 2010 (EST)

Talk:XcomUtil

2010-03-11T22:41:16Z

BladeFireLight: /* Build 435 */

=XcomUtil 9.7 Beta=

9.7 Beta is available on www.bladefirelight.com

==Release Notes==
===Build 200===
This is a Beta, so backup your files before using. If you have issues pleas post them to XcomUFO.com in the XcomUtil forum.

New in this version.

*Major overhall of the installer (XcuSetup) and the inclusion of 16/32bit exe's to support both DOSBox and Windows Vista/7 x64.
*New subfolders added to hold supporting files making the install c leaner
*New XcuSetup options were added to XcuSetup allowing for silent install and uninstallation.
*New XcuSetup option for debugging the install (XcuSetup debug) creating debug.txt.
*XcuSetup now can have minimal impact on the game.
**All options default to NO.
**Almost all changes are now prompted for (skyranger guns, interceptor as transport, Disjointed Base Bug, etc...).
***Items still done by default:
***Copy protection questions set to 0000000 for UFO 1.0-1.3 and X-Com 1.0
***Difficulty bug fixed in UFO 1.0-1.4 and X-Com 1.0-1.4
***Unique names for all maps in TFTD, Used for Hybrid Games
*XCOMUTIL.CFG is now pieced together and overwritten by XcuSetup (see XcomUtil.txt for how to make permanent changes).
*All game files are restored to the pre-XcomUtil state each time XcuSetup is ran. Any modifications by other utilities will have to be re-applied.
*Recovery of MIA soldiers has been removed as it had a habit of resurrecting all KIA units to.
*Vista/Win7 patch now an option for XcuSetup.
**This will fix the blank screen issue.
**Updated to support the split EXE.
*XcuSetup attempts to fix UAC issues by resetting folder permissions.
*A number of community made fixes are included and selectable with XcuSetup.
*Support for the DOS/Window STEAM Install.
**Windows EXE, just run XcuSetup from windows
**to launch Dos version from Steam Run XcomUtil/SteamSetup.bat to activate menu then lauch from steam.
*Out of the box support for UFO Extender. XcuSetup will detect it and ask if you want RunXcom to use it.

NOTE: If you use DosBox, this requires DosBox 0.72 (Does not work on 0.73)

--[[User:BladeFireLight|BladeFireLight]] 18:28, 17 January 2010 (EST)

===Build 204===

* Fix the goto and "ser" issue
* Fixed the version display on the DosBox version detection is back on.
--[[User:BladeFireLight|BladeFireLight]] 16:15, 18 January 2010 (EST)

===Build 219===

ok. Just posted Build 219

*New command line argument "nobackup" skips backup only if it has been ran.
*Fix f0ders loader path and option goto so it actually works.
*Fix prompted terrain option to create correct flag file.
*f0ders loader now available to Vista and Win7 users. (I have no idea if this will be of help)
*replace "if exist" on folders with "if exist" on file.
*Allow 0.73 with no command line args (as this is all it brakes)
*%X-COM% to %XCOM% for older OS's
*Fixed the beta message display
*Fixed version display in deader
*Fixed misleading message in SFX install scrip.
--[[User:BladeFireLight|BladeFireLight]] 22:57, 18 January 2010 (EST)

===Build 221===

*Fix issue following issue with XcomUtil and STEAM.
**only creating backups of the Windows EXE
**only applying changes to the DOS EXE's

STEAM USERS need to run "Verify Integrity of game cache" before updating to this build.
--[[User:BladeFireLight|BladeFireLight]] 18:02, 20 January 2010 (EST)

===Build 305===

Some major restructuring of Environment Variables to fit within the limits of the forthcoming DosBox 0.74. Previous LastOp.bat files will no longer work. (should limit XcuSetup's Environment usage to about 980 bytes. Will no longer crash DosBox 0.73 by overrunning environment buffer)
Corrected a massive error that caused corruption on x64 systems.

I recommend you uninstall the previous version of XcomUtil before installing this one. (or delete LastOp.bat)

New items:

*Backup and restore of additional folders added.
*Allow install on Unknown OS with warning.
*Re-order some option questions and adjust wording.
*Correct File location that was causing Random ship generation to hang or crash.
*Fixed Vista/Win7 Patch to run on Vista. (Thanks Dangermouse)
*Environment Vars size shrunk. This invalidates previous lastop.bat (Thanks to Peter on the DosBox Team)
*Fix issues with using space in IF statement in dosbox and Dos 5.0
*Clean up environment test variable to free up space
*Backup and Restore: Fixes time out issues on DosBox. Adds progress display.
*Set Default to split EXE.
*Allow xcusetup for Dos games in x64 OS with warning
*Switched compiler to Open Watcom for ResFix and ResINfo
*New code to detect EXE version and adjust Max Research in ResFix and ResInfo
*Resfix will no longer execute on UFO
*Switched compiler to Open Watcom xcomutil xcomutrt and sdump.
*Fixed issues with 32bit structure packing leading to wide spread file corruption
*Fixed Alien Research Help math error
--[[User:BladeFireLight|BladeFireLight]] 18:28, 6 February 2010 (EST)

===Build 317===

Don't forget to re-run XcuSetup after you extract the files. For a almost quite install use "XcuSetup lastop skip"
If upgrading from pre-305 versions you need to uninstall with "XcuSetup uninstall" and run XcuSetup Fresh.

You can now use XcuSetup in Windows to configure a game you intend to play in DosBox OR run XcuSetup in DosBox and play from Windows. Even on x64 systems. XcuSetup can be slow in Dosbox this will allow for faster setup.

RunXcom now makes on-the-fly choices about x86 vs x64 XcomUtil EXE's and Steam Dos vs Windows. If you have Vista or Win7 x64 and a Steam copy you can switch between Dos/Windows Xcom by either runing from Steam or directly starting RunXcom.

A few caveats for STEAM users. Because of how XcomUtil detects the game, while XcuSetup will apply changes to both EXE's. Running XcomUtil from the command line will only effect the Dos version.

Complete List of changes.

*XcuSetup can be run from windows and RunXcom run from DosBox
*Renamed "New Laser" to Alternate Laser
*SortStats now back in XcomUtil.cfg
*Runxcom now uses x86 or x64 EXE's based on OS at time of execution
*Steam choice of Windows or DOS EXE now based on if RunXcom is started in DosBox.
*Xcomutil settings applied to both EXE's in Steam
*SteamSetup.bat displays message on success.
*Minor error fixes with 4DOS
*Better handling of unknown OS.
*New Steam Menu Options
** Run X-Com Sound Setup
** eXit to Windows
--[[User:BladeFireLight|BladeFireLight]] 03:21, 8 February 2010 (EST)

===Build 333===

Some Minor tweaks. Only major thing is I have given up on DOSBox 0.73 it's to buggy and crashes often. Although some of the bug fixes I worked out with the DOSBox dev team will not make it in until 0.75. They tell me most of them will be in 0.74 and it should not have this issue.

Luckily STEAM uses 0.72 and works as expected.

If you run another Command interpreter like 4DOS it should work.

*Random alien craft shape now works.
*Fixed Text color on BFG prompting on UFO under DOSBox.
*XCLoader.exe properly removed on uninstall and Gamefile restore
*Fixed display of Unit type on Fighter as transport prompt.
*Apply of Seb Loader from DosBox fixed.
*Commented RunXcom
*Removed Exit Point and replaced with Pauses in XcuSetup
*Updated DOSBox 0.73 error (to unstable. frequent buffer overflows setting ERRORLEVEL on program exit.)

-Blade FireLight

===Build 339===

This fixes the issue with 4DOS failing to do an initial backup, that lead to SDUMP being unable to apply patches, that led to empty designation files.
9.6 replaced the Hammer Head map by default. 9.7 does not but the unit placement was never updated. The 12 unit placement section has been added to fix units spawning outside the craft. (Scott's version of the Hammer Head is in the patches folder but requires manual modification of the config files to fully use. )

*Disable stderr redirection on 4DOS
*More debug and ArchFile now able to be run independently
*Add unit placement section for standard Hammerhead.
*Added Apply of Transport Hard Point.
*Fix Missing Terrain on TFTD Very Small

--[[User:BladeFireLight|BladeFireLight]] 21:14, 12 February 2010 (EST)

===Build 340===

*Fixed missing label causing exit in build 399.

--[[User:BladeFireLight|BladeFireLight]] 01:48, 13 February 2010 (EST)

===Build 348===

Fixed some obscure bugs.
Win7 32x on some computers would not run 16bit code(something to to with chip-set drivers and the 16bit xcopy), so now all NT based Windows will use 32bit EXE's.
Some STEAM users had issue with the windows EXE either being replace by or replacing the _patched.exe (f0ders loader) I saw this happen but was unable to repeat it. Hopefully the change of not using short file names when long ones can be will fix this issue.

*Fix BFG Prompting Display
*replace delete with del in RunXcom
*32bit EXE used on most versions of windows.
*Skip copy short file name if can find long file name.
--[[User:BladeFireLight|BladeFireLight]] 00:44, 14 February 2010 (EST)

===Build 350===

The EXE download now uses an updated script to prompt for steamsetup (if detected) and start xcusetup. This makes it more "consumer friendly".

*New SFX Installer Script.
*Cleaned up / updated xcomutil.txt and moved to xcomutil folder

--[[User:BladeFireLight|BladeFireLight]] 18:49, 14 February 2010 (EST)

===Build 361===

By popular demand the EQL now works on any turn.

*EQL allowed any turn.
*Fix Display of Forced patches for UFO Spanish/Italian
*Fix BFG questions to avoid invalid options.
*Add Xcom UFO Italian Support

--[[User:BladeFireLight|BladeFireLight]] 19:28, 17 February 2010 (EST)

===Build 384===

Lots of bug fixes. Hybrid now working, Fixed issues with auto combat and combining clips.

*Fix Hybrid Implementation
*Auto Combat will not run on second half of two part using first parts saved data.
*Auto Combat will no longer run if combat was won.
*MIA Recovery on won combat only
*Auto equip no longer triggers on second part of 2 stage missions.
*Add skip of combine clips if between stages of 2-3 part missions.
*Lost of debug info to in XcomUtil.log
*Add Headers to XcomUtil.log section brakes.
*XcomUtil's Apply action now in debug.txt
*Update and move f0dders read me per his request.
*Fixed typo stopping Lab PSI/MC Screen from working.
*Fix Infinite loop when not splitting EXE
*Fix nonexistent %no% variable
*Limit STDERR redirection to MS OS's

--[[User:BladeFireLight|BladeFireLight]] 02:44, 22 February 2010 (EST)

===Build 413===

Fixed Hybrid and Prompted BFG on Windows EXE's. Hybrid now uses Boom Blokes Pallet conversion. (removes lighting artifacts) "XcomUtil uninstall" now removes the hybrid game maps and terrain. Updated the Vista/Win7 patch. Recommend applying if you get odd colors that only go away with a reboot or playing a video in Media Player. Created new Add-on ability to allow others to plug-in to XcuSetup and RunXcom.

*Add-on support added. see XcomUtil\XcomUtil.txt and XcomUtil\Addon\Example.txt
*Restore and Backup ran second time on Hybrid games to resolve issues with cross pollination
*Update Vista/Win7 Patch to address alt + tab color issues. (restores color pallet on next start of Goescape or Tactical. Does not stop the corrupt pallet)
*Create windows flag file to force XcomUtil to update windows EXE when playing Xcom Windows
*Better UFO Hybrid integration and uninstall of copied files.
*Bomb Bloke's Hybrid Pallet Map
*command line option for config file now searches %CWD%\, %CWD%\XcomUtil\ and %CWD%\XcomUtil\Batch\
*Hybrid path detection change to look for \maps\ATLAN00.map OR %1\maps\URBAN00.map
*Move XcomUtRt and LastOp to sub-folders older LastOp moved if it exists.
*All Flags moved to the flags folder.
*If debug.txt exists zero out file (deletion caused problems with WinTail)
*uninstall a few missed files.
*Fix debug log of config flags.
*Fix echo------ error in RunXcom.bat

--[[User:BladeFireLight|BladeFireLight]] 17:40, 28 February 2010 (EST)

===Build 422===

*Fixed unit placing where units were placed outside of sub or inside of tanks.
*Fixed Display of Starting Transport and Fighter names for TFTD
*Updated addon example.txt to streamline and clarify a few things.
*Switched to Bomb Bloke updated Color Pallet
*Units who bleed to death no longer rise from the grave. (unless they die the same turn as you kill the last alien)
*Units under mind control when the last alien dies are no longer MIA.
*Fix messed up goto in Line 8 used for addons (Was causing exit of RunXcom)
*Fix RME error

--[[User:BladeFireLight|BladeFireLight]] 02:33, 2 March 2010 (EST)

===Build 435===

Original Sound Effects from UFO were re-sampled to work with 1.4 and CE.

*Add Category to option headers.
*Improve randomness by using current time instead of game date/time in srand()
*Added Option to keep Current terrain/UFO to BFG.
*Original UFO 1.2 Sounds for Geoscape and Tactical added as an option for UFO 1.4 and CE.
*Force Split EXE on STEAM. Fixes issues with setup failing.
*Reset Laser/Gauss craft weapons stats to be default.
*Example addon now uses different flag extension to avoid deletion by XcuSetup
*fix issue with Lab Screen on DosBox always screening

==Beta Disscusion==
===Build 219===

: Well, I tried running it, and noticed a few errors in the batch setup system:
:#The existence of a directory can't be tested by using "if exist". It won't work on real DOS and many DOS emulations. The suggested workaround fails sometimes (see [http://support.microsoft.com/kb/65994] or [http://www.faqs.org/faqs/msdos-programmer-faq/part3/section-7.html]).
:#* I dont have access to every platform. Your help on this would be invaluable.
:#** It's been a long long time since I wrote batch scripts... First, I suggest creating the directories unconditionally (redirect output or clear screen if you're worried about error output). Second, either drop checking for game_1 directory existence afterwards or if you must check for it - write a dummy batchfile into the directory which only runs one command: a command which exits with a specific known errorlevel (probably sdump or other xcomutil binary would work). Then try to run said batch. Then you can test for said errorlevel - if it's there, than the directory exists. Then erase dummy batchfile.
:#*** My solution is similar. i'm using the dum.bin If it dosent exist create the directory with >>%redir% and copy in a dum.bin. should work on any OS.
:#Please don't test existence of correct running environment for X-COM in the setup file (e.g. don't prevent patching windows version while running in dosbox, or vice versa). Or at least don't abort the setup, but just print out a warning. This is patronizing - it's none of Xcomutil business, and people who downloaded this probably already know how to run software. Besides, this is likely to ruin at least some possible combinations. Maybe some future bug in dosbox/Windows will make people want to run the setup batch file under cmd.exe/dosbox? Or maybe some people may even want to run XCOM CE in [http://www.winehq.com Wine] for example, and the check keeps in the way? (Also there's a spelling error - "hoast" -> "host").
:#* I dont expect everyone who got the game for the first time from STEAM to know their way around the computer. If RunXcom uses 16bit EXE's setup in DosBox in Windows 7 x64 it will throw an error. I could integrate the system checks into RunXcom so It can select the right EXE's however for STEAM and similar setup with both EXE I would have to setup a menu in RunXcom to select what version to actually use if they have Steam on a 32 bit platform.
:#* I dont intend to support OS2 or Wine like Scott did. What OS's I can support will be based on what feedback I get and what I have the time/interest in fixing.
:#** Then can you add a parameter to let us override the checks without editing xcusetup? These checks are bound to fail for some OS/dosbox combination now or in the future...
:#*** It's not that simple. The values in the syscheck are required for making decisions. like is the OS x64, is the game UFO or TFTD. does the OS have UAC. will the OS accept SHIM's. Can I find the files needed to run the commands ... --[[User:BladeFireLight|BladeFireLight]] 20:53, 18 January 2010 (EST)
:#4DOS (v7.5 and v8) at least don't like X-COM environment variable name (it returns -COM when doing %X-Com%), and I suspect it may not work under MS-DOS's COMMAND.COM either. Try something like "%X_Com%" for example.
:#* That will be fixed soon.
:# EnvClean.bat has an error in line 172: ser -> set.
:#* Fixed in build 204.
:# Note that ansi escape sequences aren't necessarily supported on a real dos environment/emulation.
:#* Good point I will move that to DosBox only.
:# FreeDOS breaks horribly on the setup files, but I think that's due to bugs on their end.
:#* I dont know what can be done about that.
:# Thanks for continuing work on XComUtil.
:#* Your welcome. I should have started on this sooner.
:# Btw, what's wrong with DosBox 0.73? It sure didn't stop XcomUtil 9.6.. [[User:Cesium|Cesium]] 09:45, 18 January 2010 (EST)
:#* 0.73 had two changes. 1. the shell closes the batch file after each line and remembers where it was then reads the file again starting at the next line. (this was to alow for menus that modify themselves. 2. They made shift move %1 to %0. I'm sure you can see what that does. I do a special shift test to detect 0.73. While the basic setup would work none of the command line options would. This was fixed in there current nightly build 2 months back so it will be working in 0.74.
:#** Grrr. They did this for "self modifying menus" (which don't need this performance killing stupidity) but ignored my patch...
::I have verified the new setup works if 4DOS is used under DosBox 0.73 (with some small changes outlined above. 4Dos had to be started with "4DOS /E:16384"). Now to test the game.. [[User:Cesium|Cesium]] 15:00, 18 January 2010 (EST)
::* Well, the Dart gun seems to be still useless. The change gave me an auto shot which takes 3xTU than snap shot but with same percentage...
::** This the same as the UFO pistol update. all it's doing is making 3 snap shots with no chance for reaction fire. --[[User:BladeFireLight|BladeFireLight]] 20:53, 18 January 2010 (EST)
::* Small wish: Have the option to make the Gauss Tank require only Gauss Cannon research - this can make it more distinct than the Sonic Displacer and maybe slightly useful for a while...
::** I plan on it. just not this version. --[[User:BladeFireLight|BladeFireLight]] 20:53, 18 January 2010 (EST)

:* One other think I noticed (with 200 but that's probably with 204 too), is that if xcusetup is run again after a successful setup, than it restores from backup, then backups the restored files again... Not sure if this is needed. Maybe there's a scenario where it is? [[User:Cesium|Cesium]] 17:32, 18 January 2010 (EST)
::* Yes it does. on DosBox this can be painfully slow to :( The reason for this is Hybrid games or map packs being added sense the last backup. When I have the new BFG and make a C++ version of the XcomUtTE.jar that 9.6 XcuSetup had, this will be of more important. perhaps I will make a command line option to skip backup so you dont have to run it. --[[User:BladeFireLight|BladeFireLight]] 20:53, 18 January 2010 (EST)

: I've noticed a bug (with 200, but since no in-game changes are mentioned in the changelog, I'm guessing its unchanged): XcomUtil is set to restore previous equipment. I'm packing a few Sonic Pulsars for the first time (I think?), and XcomUtil packs a few Pulsars into one spot in the backpack.. Savegame: [http://www.ufopaedia.org/images/3/34/Bugged_save.zip] [[User:Cesium|Cesium]] 23:32, 18 January 2010 (EST)
:: This behavior has been around since that option was added. see "Automatic Re-Equipment of Troops:" on line 1025 of XcomUtil.txt. I have not modified that section of code. It will be addressed eventually --[[User:BladeFireLight|BladeFireLight]] 23:39, 18 January 2010 (EST)

===Build 221===

:* Playing further, I noticed that If all the aliens are down (some of them stunned), the last save is named "AutoCombat" and I end turn, XcomUtil may still run "AutoCombat" phase. This may have slightly different results than end of combat would have had. (Also, the score is low in AutoCombat use since all agents are regarded as KIA, but you probably already knew that). [[User:Cesium|Cesium]] 22:57, 20 January 2010 (EST)

:: Autocombat should only run on Abort, and only if: slot ten is named "autocombat" AND it's date,time and combat round match the one just aborted. By "all agents KIA" are you saying they all were killed by auto combat? --[[User:BladeFireLight|BladeFireLight]] 12:14, 21 January 2010 (EST)

::* This is not the case. Set up XcomUtil so that it leaves messages after battle. Then get [http://www.ufopaedia.org/images/c/c3/Buggy_autocombat1.zip]. Load the game and press "End Turn" - AutoCombat will run when it shouldn't... As for all agents KIA I mean score-wise - I do get them back, but in score display I get points deducted as if they are all dead. Same for civilians at terror sites. I'm using build 200, as there's nothing in the changelogs that suggests changes to XcomUtil's behaviour in-game and I already got it installed.. [Edit: tested with 219 too - still fails] [Edit2: this turns out not to be entirely accurate: agents not in exit locations would be lost after running AutoCombat. Edit date: [[User:Cesium|Cesium]] 19:44, 30 January 2010 (EST)]
::: AutoCombat should only run then tactical exits with abort mission. if it's runing on end turn then tactical is crashing. Can you send me your debug.txt? --[[User:BladeFireLight|BladeFireLight]] 14:06, 21 January 2010 (EST)
:::: Well, there's a link to a buggy savegame above so you can verify it yourself (I'm using TFTD v2.1 DOS under DosBox 0.73 right now). I've erased debug.txt and loaded the savegame again - nothing is written to debug.txt. Also, X-COM is behaving fine (mission successful end, etc.) when this is run without XcomUtil. I suspect Tactical is just exiting normally and for some reason XcomUtil just decided to run AutoCombat. [[User:Cesium|Cesium]] 14:18, 21 January 2010 (EST)
::::: The debug.txt is created by XcuSetup. it tells me what options you chose and what happend when it tried to apply them. This would give me a baseline to replicate your setup. With 0.73 you cant run "XcuSetup lastop skip" to re-create what it did the last time you ran it Can you either send me the lastop.bat or if you run XcuSetup again with the same options and send me the debug.txt. Then I can get the same configuration your having issues with. (I need to add a CRC check to the before and after conditions of the EXE's to the debug so I can tell if they have changing consistently.) --[[User:BladeFireLight|BladeFireLight]] 15:44, 21 January 2010 (EST)
:::::: I can run "Xcusetup lastop skip" under DosBox 0.73 if I use a different batch interpreter like 4DOS... Here it is: [[Image:Debug.zip]] [[User:Cesium|Cesium]] 16:12, 21 January 2010 (EST).
::::::: That is good to know. The setup should not give an error in that case, if it passes the shift then it could care less. I would think that with a diferent interprater, %COMSPEC% would be somthing other then Z:\COMMAND.COM. am I correct about that?
:::::::: Well, in this case COMSPEC isn't changed and than it works fine. If COMSPEC is changed to point to 4DOS, than:
::::::::# "Processing" is displayed as the "Operating System".
::::::::# setup fails on the "Path to Xcopy" check.
::::::::: I tried to use the 4DOS batch file debugger to see exactly where it fails, but it's too unwieldy for this. (Note that 4DOS needs to be started using /E:16384 or something similar, since default environment size is too small). [[User:Cesium|Cesium]] 02:29, 23 January 2010 (EST)
:::::::::: It should fail on an Unknown OS. If you have a sure fire way to detect 4DOS i would be happy to add it. I would treat it the same as dosbox.
::::::::::: It's funny that a DOS program won't work on a real DOS but only on dosbox... It would be a lot easier to make the OS checks not abort, than to try and detect everything... Anyway, you can test for 4DOS like this: 'if NOT "%_4VER%". == "". (then 4DOS)'.
:::::::::: As for the environment size I'm not surprised it's to small. I use it extensively so I check for a lot of it. I dont know how the larger command.com footprint will effect available memory on a bare mettle dos install. --[[User:BladeFireLight|BladeFireLight]] 23:05, 23 January 2010 (EST)
::::::::::: Well, Environment requirement can be reduced, but this is likely to reduce legibility of setup batch. I doubt it's worth it. Even ancient DOS systems had 640KB.. [[User:Cesium|Cesium]] 00:05, 24 January 2010 (EST)
::::::: I will look at the debug and the saved game this weekend or monday. I have to finish migrating all my code to another compiler. XcomUtil was written with Borland 2.0 in mind. I had to use 5.5 for the 32 but but it's giving me fits. So I'm trying to move all the code over to Open Watcom this weekend. It will be nice having debugger to use. --[[User:BladeFireLight|BladeFireLight]] 01:22, 23 January 2010 (EST)
::::::: Took a look at why the autocombat would run when not intended. If you have the same date/time in the autocombat as the current save and press end turn with with all aliens dead it will trigger autocombat. to avoid this rename the save in slot 10 if your playing the same battle again. --[[User:BladeFireLight|BladeFireLight]] 17:40, 30 January 2010 (EST)
:::::::* OK, so it can run if end turn rather than abort is used (that's not a problem to get around). However, there's a bug: Even though tactical has concluded the aliens are no longer a threat, XcomUtil can still run an AutoCombat against a few "zombie" aliens (I think the uploaded save has this? If not, I probably have an archived save exhibiting this)... X-Com would win, but it might be possible to lose valuable research help from accidentally killing said aliens. I suspect that's due to some stun calculations failing somehow and concluding some stunned aliens can still fight. [[User:Cesium|Cesium]] 19:40, 30 January 2010 (EST)

::* P.S. Can I get research help from captive at first stage of 2-stage missions? And Has XcomUtil's behaviour for 2/3-stage TFTD missions been improved? Well, I'm doing an Artifact site now, so I'll find out soon anyway... 9.6 used to be real buggy in T'Leth third stage transition (and I have a save game for that too) and IIRC didn't let me get captives from first stage. Never played research help till now though... [[User:Cesium|Cesium]] 13:41, 21 January 2010 (EST)
::: I have only made one change to XcomUtil.exe that that was to remove the MIA recovery. I expect the clip recovery issue will still be their between stages. This is a major frustration to me and I will address it once the installer is stable. --[[User:BladeFireLight|BladeFireLight]] 14:06, 21 January 2010 (EST)
:::: I managed to overwrite my own game saves, but eventually I did quite a few two part missions. I notice that sometimes XcomUtil can emit "Divide error" when calculating research help. This seems to happen usually (but not exclusively) when calculating the second part of a two-part... The attached savegame ([[Image:Autocombat_research_bug.zip]] - unzip than save slot 10 at "AutoCombat" and abort) has this behaviour. [[User:Cesium|Cesium]] 08:44, 25 January 2010 (EST)
::::: I played around with that game and didn't get a "divide error" with vanila 0.72 but it did lockup on me doing the research calculations aborting the second stage if I autocombated the first. I also had tactical skip the equip screen and crash. This will require some more research. --[[User:BladeFireLight|BladeFireLight]] 18:03, 30 January 2010 (EST)

===Build 305===

:: I haven't played with this yet, but running setup I noticed the following:
:* I get this warning when running XcuSetup under 4DOS: "restore.bat [485] Duplicate redirection ">>debug.txt"". It's harmless though.
::: This will be fixed in the next build. --[[User:BladeFireLight|BladeFireLight]] 15:14, 7 February 2010 (EST)
:* Redirecting the "attrib -R /S" line to nul would be nice (it outputs a lot under 4DOS, FreeDos and maybe other interpreters).
::: Ditto --[[User:BladeFireLight|BladeFireLight]] 15:14, 7 February 2010 (EST)
:* Install on unknown OS doesn't seem to work - it gives "Unable to continue!" right after asking "Shell We Continue?" (without waiting for input). I've tested this on DosBox 0.73 where COMSPEC has been changed..
::: Same here. DosBox a number of things missing in the command interprater I relyed on detecting the comspec var to know it's dosbox becaus of the lack of a native find. and if I use a | it only runs the first part. I am re-writing the detection to now use the included 16bit find.com on all but x64 systems to check the ver statement. --[[User:BladeFireLight|BladeFireLight]] 15:14, 7 February 2010 (EST)
:* Why is the sound directory backed up? Perhaps you intend to add an "UFO 1.2 sounds for 1.4" or "Playstation mp3s for UFO CE" options in the future? It seems useless for TFTD though.. [[User:Cesium|Cesium]] 03:12, 7 February 2010 (EST)
::: Yes I intend to include the sound fixes eventualy. While TFTD would not be needed Its more of a pain to skip then to backup. The Geograph folder that is Slooooow. I may limit it to just files I may replace.
:* One more thing: I've tried running "command /E:512" with dosbox 0.73 and then running xcusetup. Instead of exiting with an environment space error, the setup breaks in a very odd way (dosbox is stuck and has to be terminated [edit: sometimes this requires running xcusetup more than once to trigger]). Also, the real requirement seems to be more than 980 bytes (unless the check is intentionally pessimistic?). [[User:Cesium|Cesium]] 03:29, 7 February 2010 (EST)
::: the DOSBox team is addressing this in 0.74. It was my complaints of crashing that led to us working on fixing the environment buffer overflow issue. I had to shrink my environment usage to the official size (1088) and they fixed the overflow. --[[User:BladeFireLight|BladeFireLight]] 15:14, 7 February 2010 (EST)
:: Btw, you might be interested in [http://forums.somethingawful.com/showthread.php?threadid=3220122]. The thread uses XcomUtil (9.6) multiplayer quite heavily and they probably have bug reports... [[User:Cesium|Cesium]] 03:15, 7 February 2010 (EST)

===Build 317===

:* Unknown OS now works: I've successfully ran xcusetup under FreeDOS in dosemu.
:* DosBox 0.73 doesn't work though.. It gets stuck right after asking whether to apply the bugfixes.
:* I wonder why the research fix for TFTD isn't enabled by default? I guess it will be once testing is done? [[User:Cesium|Cesium]] 12:25, 8 February 2010 (EST)
:: Minor problem with XCUSETUP of build 317. Note the missing "what" transports can carry.

-= XcomUtil 9.7 Beta (Build 317) setup =-
:: Fighters / Transport ::
Change the Interceptor and Firestorm to carry 's
[NOTE: modifies Tactical and adds additional map, route and terrain
files.]
Do you want to enable Interceptor and Firestorm as Fighter Transports? (N)

::This is my first install of the new XCU and I am VERY impressed. Nice job! [[User:Spike|Spike]] 19:23, 11 February 2010 (EST)

::: Thanks This will be fixed. --[[User:BladeFireLight|BladeFireLight]] 21:21, 11 February 2010 (EST)
:* A fully loaded Hammerhead's initial deployment has three aquanauts outside the craft. This doesn't happen when XcomUtil isn't started (i.e. via TERROR.COM). [[User:Cesium|Cesium]] 01:54, 12 February 2010 (EST)
::: Can you give me a save that is that far along. I dont have one handy. --[[User:BladeFireLight|BladeFireLight]] 02:10, 12 February 2010 (EST)
:::: Sure. [[Image:Hammerhead_bug_saves.zip]]. [[User:Cesium|Cesium]] 02:34, 12 February 2010 (EST)
:::: [[Image:Hbug2.zip]]. Maybe that would be more convenient for you. [[User:Cesium|Cesium]] 04:32, 12 February 2010 (EST)

:* I've managed to accidentally make a truncated geoscape/obdata.dat file using xcusetup. I uninstalled it, then ran "xcusetup nobackup" (it still made a backup), and chose "n" to everything besides the prompted bug fixed and improved gauss weapons. I'll try to reproduce this.
::: "uninstall" removes the backup's. "nobackup" only works if it finds backup files.
:* I've also noticed "improved gauss weapons" doesn't change the Heavy Gauss clip power in the entry in ufopedia (should be 80 instead of 75). [[User:Cesium|Cesium]] 03:03, 12 February 2010 (EST)
::: Works for me on Win7 and DOSBox 0.72. --[[User:BladeFireLight|BladeFireLight]] 15:11, 12 February 2010 (EST)
:::: I'm talking about the clip page, not the weapon page. TFTD displays the power on both the gauss weapon and gauss ammo pages. [[User:Cesium|Cesium]] 16:36, 12 February 2010 (EST)
::::: This must be with remove clip turned on. with just a power increase the damage is not displayed on the weapon. I need to look into disabling clip research as part of removing the clip requirement. for now I can add the damage levels to the clips when removing the need for them. --[[User:BladeFireLight|BladeFireLight]] 16:43, 12 February 2010 (EST)
:::::: Per description in xcusetup, Heavy Gauss is upgraded from 75 to 80 power even when "Improved Gauss Weapons" change is on, but "Remove Clip" change is off (i.e. gauss weapons still need clips), so the Heavy Gauss Clip page needs to be updated regardless of "Remove Clip" setting in xcusetup (unless you manage to disable clips altogether when its turned on). [[User:Cesium|Cesium]] 16:58, 12 February 2010 (EST)
::::::: UFOPedia pulls the information from obdata.dat. 4DOS has a number of issues that cascade though out XcuSetup I'm tracking them back. I will have to do some regression testing with 4DOS tonight. Seems redirection of STDERR varies from one DOS to another. --[[User:BladeFireLight|BladeFireLight]] 18:38, 12 February 2010 (EST)
:::::::: Ah, yes. "Real" DOS has no stderr redirection support at all. 4DOS has ">&>" extension, but NT cmd.exe uses "2>". I saw these errors, but thought they were harmless... [[User:Cesium|Cesium]] 19:20, 12 February 2010 (EST)

:Weirdness. I'm using Aliens Help Research and I win a Laser technology every day with 50 Scientists. One day I doubled up and got Laser Rifle and Heavy Laser on the same day (a known, non-XCU bug). Got Laser Cannon in 2 days. Is this supposed to happen with the human tech when you opt for Aliens Help Research? The Alien tech becomes impossible without them. Also I am getting Battlescape crashes, or rather it just skips the Battlescape altogether and replays the results of the previous battle. It also seems to lose the equipment in the transport, revert it to what was in the transport on the previous battle. I'm using the BFG and the Seb76 loader equipment management, that could be part of the problem. [[User:Spike|Spike]] 22:00, 12 February 2010 (EST)

:: OK I see what's going on. It is prompting me for terrain, but offering not terrain options but light level options. Then after I select a light level, it prompts me for light level, but does not wait for input and goes straight to battlescape, which fails.

0 = Jungle
1 = Farm
2 = Forest
3 = Human Base
4 = Alien Base
5 = Urban
6 = Desert
7 = Mountain
8 = Polar
9 = Mars

''[here I enter "5"]''
Select terrain:
0 = Darkness
1 = Twilight
2 = Daylight

''[here I enter "2"]''
Select light:

:: Basically it seems to be reading my input one step before I am prompted for it, and possibly giving the wrong input for the wrong question. It also is getting stuck in a loop of the BFG prompt. So probably it's a simple logic glitch in the batch file. I will update to the latest build and see if can replicate it. If I can, I will attach the game save file and config files. [[User:Spike|Spike]] 08:32, 13 February 2010 (EST)

::: I noticed this to. This is the underlying code.
<pre> printf( "\nSelect terrain: " );

if ( ESCAPE == ( i = getch() ) )</pre>
::: The prompt displayed before waiting for a key press. This may be an issue with Open Watcom. --[[User:BladeFireLight|BladeFireLight]] 18:39, 13 February 2010 (EST)

===Build 333===

:* One can make a truncated geodata/obdata.dat file in builds 317/333. I've run xcusetup, selected nothing but the fixes and improved gauss weapons, and pressed enter for everything else (4DOS/DosBox 0.73). The truncated file prevents the game from starting. [[User:Cesium|Cesium]] 03:23, 12 February 2010 (EST)
:: I think this may be a 4DOS issue. jpsoft.com does not look to support it any more. What version are you on on where do I get a copy? --[[User:BladeFireLight|BladeFireLight]] 15:08, 12 February 2010 (EST)
::: I've tried now with both last official version (7.50) and last open source version (8.00). Same issue with both. You just get a copy of either from [http://www.4dos.info/v4dos.htm] [[User:Cesium|Cesium]] 16:52, 12 February 2010 (EST)

===Build 340===

-= XcomUtil 9.7 Beta (Build 340) setup =-

::Creating Backup Files::

Geoscape Backup ................... OK
Tactical Backup ................... None
Maps Directory Backup ............. Processing.

16-bit MS-DOS Subsystem
Windows Command Processor - xcusetup
NTVDM has encountered a System Error
The handle is invalid.
Choose Close to terminate the application.

version is

Microsoft Windows [Version 6.1.7100]
Win7

last debug.txt message is

ResConfig=None
1 file(s) copied.
GeoBak=OK
Copying C:\games\xcom-all\MAPS\AVENGER.MAP
1 file(s) copied

xcsetup goes into a loop, the close option does not stop xcusetup but just loops

[[User:Spike|Spike]] 15:41, 13 February 2010 (EST)

:Lovely. I think I know what is going but I dont have a win7 32bit to test on. Do you have a Google Talk account? I would like to test something.
: on a side note. that is not actually a loop. it's copying groups of files at a time to avoid the timeout issue on dosbox. --[[User:BladeFireLight|BladeFireLight]] 16:40, 13 February 2010 (EST)

===Build 361===
*There's no Italian text for the New Laser Weapons option. Applying the patch seems to work, but it displays the text for the default laser weapons. Unfortunately, I don't know enough Italian to translate it myself.
:: Neither do I --[[User:BladeFireLight|BladeFireLight]] 21:51, 17 February 2010 (EST)
*There are two places in SysCheck.bat which use "%NO%" (lines 46, 164). I don't see that set anywhere. I think you meant something like "%clErr%NO%clOff%"? It's also possible to remove "set NO=" line from EnvClean.bat.
:: Thanks I will fix that --[[User:BladeFireLight|BladeFireLight]] 21:51, 17 February 2010 (EST)
*Apply.bat has two overt redirections to stderr (lines 830, 831). Since you're doing the stderr redirection support check several times, you may want to centralize it in Xcusetup.bat and than use something like %output%.
:: This is why you used to have to do "/E:16384" and why DosBox crashed so often. I have to keep under 950 bytes of environment usage.
::: I still have to do "/E:1024" etc. since 4Dos default environment size is 512 bytes. I think it's possible to save a bit more though by using a trick: instead of using %OLDPATH%, save the value of %PATH% to a batch file ("echo set PATH=%PATH >>" etc.) and then run said file after running EnvClean.bat at the end. There's more savings in this approach than just %OLDPATH%, since there are environment variables which tend to exist in DosBox before running xcusetup and can be cleared: %COMSPEC% (unused after DosBox test), %BLASTER% (iff sb emulation is on), %ULTRASND% and %ULTRADIR% (iff gus emulation is on). These can be unset at batch file start to save space and later restored by the temporary batch file. [[User:Cesium|Cesium]] 20:24, 18 February 2010 (EST)
::::All true DOS's only have 512 by default. I had thought about doing something similar with the default.bat and lastop.bat. using a series of of jumps to read it parts and then creating flag files for each setting. This would eliminate the need for most of the environment vars, but it also means another week for the overhaul. --[[User:BladeFireLight|BladeFireLight]] 21:07, 18 February 2010 (EST)
*Xcomutil.txt line 569: Telling the user to reboot isn't the best advice for multitasking OSs... Best to limit that advice to DOS. [[User:Cesium|Cesium]] 21:03, 17 February 2010 (EST)
::: Made sense when it was written. :) --[[User:BladeFireLight|BladeFireLight]] 21:51, 17 February 2010 (EST)

* I'm looking at the autocombat issue you mentioned above. AutoCombat is designed to kill every alien, no mater if they are unconscious. This has obvious issues with Alien Research. --[[User:BladeFireLight|BladeFireLight]] 22:42, 17 February 2010 (EST)

===Build 384===
* Hooray! This build is much better. I did find some stuff on initial check though:
* The number of aliens in the mission report is inconsistent with the number of live aliens captured per research help. See [[Image:Alien_numbers_mismatch.zip]] and [[Image:Dead_alien_count.zip]].
* You can get X-COM MIA if you abort a mission, even if everyone is in the exit. Possibly a second stage bug only? See [[Image:X-COM_MIA.zip]]. Note that this only affects the report - after mission all the X-COM troops are still available.
:* This happens even on vanilla TFTD with that save. Given it's TFTD it could be an issue with the mapfiles. --[[User:BladeFireLight|BladeFireLight]] 00:23, 24 February 2010 (EST)
* Morale is random at start of second stage after autocombat of first stage?
:* Actually Morale is used as the clip size and time units as the weapon damage. Don't ask me why. It would take a major re-write of auto combat to fix this. --[[User:BladeFireLight|BladeFireLight]] 19:34, 23 February 2010 (EST)
* All Civilians are dead if AutoCombat is used to end a Terror mission. It's too not much of a problem, since score is likely to be positive anyway. It would possibly be an improvement to assume all civs from first stage are dead (if ran at second stage) and get a random number (using mission seed) for dead civs at current stage? [[User:Cesium|Cesium]] 07:00, 22 February 2010 (EST)
:* This is odd. Autocombat is supposed to skip over civilians when using the kill function. --[[User:BladeFireLight|BladeFireLight]] 00:18, 24 February 2010 (EST)
::Maybe kill civilians (or not) according to the force ratios. If XCom has only enough force to win the mission, all Civilians are dead. If XCom bring a certain amount of "excessive force", all or nearly all Civilians are saved. By the way I love AutoCombat, it is great for avoiding repetitive combat and only playing the new, interesting bits. [[User:Spike|Spike]] 15:53, 22 February 2010 (EST)

::: Thinking about this, I recalled the scenario where someone fights the mission and uses AutoCombat to hunt the last aliens (another reason AutoCombat is great). Spike's suggestion is better from pure RNG, since in this case probably all civs that were at risk already died. So lets see what we suggest XcomUtil do:

:::* Count civs from first stage if there was one as dead (since IIRC XcomUtil has no memory of first stage when exiting second stage, so we can't take them into account?).
:::* Deduct dead civs from current stage.
:::* Calculate extra dead civs using force ratio to bias the RNG (I prefer merely biasing the RNG rather than precluding results, since Xcom in general has a large variance in almost every gameplay mechanic). [[User:Cesium|Cesium]] 18:27, 22 February 2010 (EST)

* "if %xOS%. == DosBox. if %xOS%. == 4DOS. if %xOS%. == Unknown. dir *.xcf" - this is not an OR statement. This line will simply never be executed. You can use a goto to emulate if/else and to test the condition only once, e.g.:

if NOT %xOS%. == DosBox. if NOT %xOS%. == 4DOS. if NOT %xOS%. == Unknown. goto win
dir ...
goto next
win:
dir /b ...
next:
[[User:Cesium|Cesium]] 07:42, 22 February 2010 (EST)

===Build 435===
: I hope the improved randomness doesn't apply to the Aliens' d100 during AutoCombat. Otherwise, one could load-scum for success. [[User:Cesium|Cesium]] 06:33, 11 March 2010 (EST)
:: Actually it does. I can see what your getting at, but why do it that way. if you want to win the "WIN" command line option is faster and you get better loot from the UFO. also using the combat date would also swing the other way with an unwindable autocombat with an fully loaded avenger vs a survey ship. --[[User:BladeFireLight|BladeFireLight]] 17:41, 11 March 2010 (EST)
: In the setup question for sound files: "were replace" should be "were replaced". [[User:Cesium|Cesium]] 06:53, 11 March 2010 (EST)

==Open Bugs==
*Various second stage bugs - ammo clip recovery, crashes after autocombat of first stage, etc. Mainly for TFTD, but possibly Cydonia in UFO is also affected.
*RPL bug, when you turn creatures into Gill Men, they are reported as Snakemen
:: Reported how? Is this consistent? The name's used are from xcomutil.cfg. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
:::Sorry. It's reported in morale failure pop up messages. Though maybe this is an original TFTD bug rather than an XComUtil bug. [[User:Spike|Spike]] 19:21, 21 February 2010 (EST)
::: See this: [http://www.youtube.com/watch?v=uGlSghf7aTU]. In that case, all Gill man (were lobster man before RPL) were reported as snakemen.. [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST)
*RPL bug, when you turn Lobstermen into other creatures (e.g. Gill Men), they are very hard to kill despite having the stats of the creature they turned in to. Possibly they are keeping their damage resistance? Maybe the race is stored in more than one place, for different purposes, and XComUtil misses one of these places?
:: I will look into this --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: The RPL only changes the basics; The race, rank, name, TimeUnits, Health, Energy, Reactions, Armor(front,back,left,right), Strenght and PSI Strenght. All other stats are left as-is. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
:::: I'm not so sure about this. See 05:00 mark at [http://www.youtube.com/watch?v=y-_zLdjhUHI]. The armour doesn't match the one Gill man should have (per UFOpaedia, at least). [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST). See also 04:17 mark at [http://www.youtube.com/watch?v=z5LfzFSkRnI] for reason to suspect resistances aren't always changed. It's possible he just was unlucky though... [[User:Cesium|Cesium]] 19:53, 21 February 2010 (EST)
::::: Actually the function is something like this
<pre>#define UpdateStat(x,y) pur->x = (unsigned char) \
( ( (unsigned int)pur->x \
* (unsigned int)pasTo->y \
) / (unsigned int)pasFrom->y )
UpdateStat( TimeUnits0, TimeUnits );
UpdateStat( Health0, Health );
UpdateStat( Energy0, Energy );
UpdateStat( Reactions0, Reactions );
UpdateStat( AFront0, AFront2 );
UpdateStat( ALeft0, ALeft2 );
UpdateStat( ARight0, ARight2 );
UpdateStat( ARear0, ARear2 );
UpdateStat( AUnder0, AUnder2 );
UpdateStat( Strength, Strength );
UpdateStat( PsiStrength, PsiStrength );
</pre>
::::: the 0's are values at start of tactical.
::::: I read that as Current(from game_x) * Target default(from xcomutil.cfg) / source default (from Xcomutil.cfg) so the stats will be different. --[[User:BladeFireLight|BladeFireLight]] 21:33, 21 February 2010 (EST)
:::::: I'd have expected Current(game_x) == Source default if applied on first turn? This would end up with result == Target default, no? Hmmm... We already saw some compiler multiplication wackiness with the research help bug. Possibly this affected these calculations too?
:::::: As for the code, you're not updating PsiSkill, so non Psi-users can't get Psi after RPL. [[User:Cesium|Cesium]] 22:03, 21 February 2010 (EST)
::::::: I didn't write this. I'm amusing Scott did it this way to adjust for difficulty because XcomUtil.cfg has the beginner level stats. It need's an overhaul to use the full stat entries including the unknowns adjusted correctly for the level. Something for latter. --[[User:BladeFireLight|BladeFireLight]] 22:09, 21 February 2010 (EST)
:::::::: For this specific issue I think you will need to update 0x37 of [[UNITREF.DAT]] which is the Damage Modifier. In addition to the Psi Strength. Also Firing Accuracy, energy regen rate, movement class... loads of stuff. And of course LOFTEMPS. So with current RPL not changing LOFTEMPS, changed aliens are the wrong size and shape probably. This would be visible using the LOFTEMPS map viewer I suppose. [[User:Spike|Spike]] 18:39, 9 March 2010 (EST)
*[[Known Bugs#XComUtil Inventory Stacking Bug]]
:: I hope to overcome this but Scott's notes point to a technical limitation. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*Removal of Small Scout map / Survey Ship map, making it impossible to do these Battlescape missions.
:: 9.7 only removes the maps if you use the BFG. This will be addressed eventually. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*Was it really intended to '''not''' have nerfed the [[Manufacturing_Profitability#XComUtil_manufacturing_profitability|Profitability]] of the Fusion Ball Launcher along with everything else? More generally, the profit nerfing could be revised to be more orderly and more systematic.
:: I dont really know what Scott intended as for the profiteering off of the changed items. If you want to suggest alternative values I'm open to discussion. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: A preliminary suggestion would be to make the Fusion Ball Launcher similarly difficult to manufacture as the Plasma Beam, so about ten times harder vs the unmodified game. E.g. Workshop space 6 -> 60, 400 -> 4000 Engineer hours. And perhaps require 4 Elerium and 20 Alloys, placing it midway between Laser Cannon and Plasma Beams. These changes (even without the materials) make the FBL unprofitable, like the (modified) Plasma Beam. I'm sure part of Scott's intent was to prevent "Laser Cannon Factories", but "FBL Factories" are 75% as profitable.
::: General reform of the profitability of manufacturing would require a lot of thought. Suffice to say I don't think '''any''' thought went into this for the original game. In reforming the economics of XCom, a basic problem is that realism is at odds with game balance. Realistically, governments would pay handsomely for almost anything XCom can produce. What would be reasonable is to get a moderate rate of return, rising more or less linear with investment (research effort), for ''all'' items. For game balance, this could be tweaked down for items that are useful in the game, or have research predecessors / successors that are useful in the game. A simpler case is to say that no item has negative profit, you can at least get 'cost price' back for it. Aircraft should arguably be in this category (since they would sell for 100s of millions which would be totally unbalancing). A rationalisation for nerfing any prices is that the money received by XCom is not the whole sale amount, but just a small commission paid by the Council of Funding Nations, which actually controls the sales and takes (in exchange for its funding) most of the profits. [[User:Spike|Spike]] 19:40, 8 February 2010 (EST)
:::: FBLs are already pretty useless, and you want to nerf these further? I'd rather think of a way to make them more useful in-game, otherwise the profit should be kept (Note how it's the mostly useless craft weapons which are profitable - I suspect there was some thought into this..). In comparison, the Laser Cannon profit does get nerfed with XcomUtil, but we get a useful weapon instead. I'd suggest a modified FBL will have a very high elerium requirement, and the power of the weapon should be raised a bit to compensate. [[User:Cesium|Cesium]] 20:04, 8 February 2010 (EST)
::::: For example: Raise power to 240, and add another charge (almost enough to sink a battleship if a craft has two FBLs loaded), but make it cost 100 elerium to make launcher. Raise hours for Balls by factor of 10. [[User:Cesium|Cesium]] 20:16, 8 February 2010 (EST)
::: Actually you're right, it makes more sense to make FBLs viable, instead of (just) nerfing the profits. Obviously high Elerium requirements will make them non-profitable. But of the 2 problems - making things useful and preventing 'factory farming' - I think making things useful is more important. I didn't realise FBLs were not tactically useful. I've never built them, only Plasma Beams. 3 ammo is reasonable, it means that 2 FBL armed aircraft have a good chance to take down a Battleship, if they can fire 9-10 out of 12 fusion balls before they are both killed. But 100 Elerium is way too much for an improved FBL that's only slightly more powerful. I think my suggestion (4 Elerium, 20 Alloys, 10x hours, 10x space) fits with the requirements of other XComUtil-modified weapons. Combined with your suggestion of 3 ammo and 240 damage, I think it would make FBLs ''useful'' again, which is one of the original goals of XComUtil.
::: Of course, it's ''possible'' that Scott was cleverly making FBLs useful, by making them so much cheaper (net) to manufacture than Plasma Beams. In an XComUtil modified game, you might well deploy FBLs first, and only work your way up to Plasma Beams later, because of the huge manufacturing costs of Plasma Beams. But personally I think it was an oversight. [[User:Spike|Spike]] 17:21, 9 February 2010 (EST)
:::: I've never played with XcomUtil modified lasers, so if you say this fits in better that's fine with me. It's unfortunate it involves increasing space: inventory management is one of the things I hate about the first two X-Coms. I was hired to be a commander, not a supply clerk! A mod which made general stores have 10000 space (like Apoc) would be nice.. [[User:Cesium|Cesium]] 21:39, 9 February 2010 (EST)
:::: Actually the energy weapon mod means they uses more ''workshop'' space to build but not more inventory space to store.
::::However "An army marches on its stomach ", Napoleon said, by which he meant that wars are won or lost on logistics. Other famous commanders have said similar things. So a general should pay attention to logistics. One of the great things about XCOM is it's not just a tactical game, it's a combined political - strategic - operational - tactical game. [[User:Spike|Spike]] 04:37, 14 February 2010 (EST)
*Zrbite lying around in odd places. Objects lying around in odd places in general - these are map modifying errors, probably only occur when customising terrain etc.
:: Will be part of an overhaul of the BFG --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*Also the '''xcsetup.bat''' prompt for the option of less-profitable weapons manufacturing is misleadingly called "new laser weapons". This should be much more clear eg "Much more difficult to manufacture advanced weapons [except FBLs]" or similar.
:: This seems to be a common complaint. I will look into better wording. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: Actually it might be an idea to break this up into sub-options. It does a lot of things! The "new laser weapons" option requires the use of extra alien materials in order to manufacture almost all energy beam weapons (not just lasers). It also makes the human manufacture of the alien plasma beam small arms impossible (research success merely allows X-COM to use captured weapons). The manufacture of craft Plasma Beams is still possible, but is made significantly more difficult (ten times the labour and workspace requirement as well as additional materials). As Scott says this "seriously changes the economics of the game". It also significantly alters the balance of firepower in the air and (to a lesser extent) on the ground. [[User:Spike|Spike]] 19:40, 8 February 2010 (EST)
*There is a small problem in editing/customising craft using '''XComUtil.cfg'''. Certain X-Com craft weapon values - the rate of fire value - can't be set. Or more specifically, they can be set (patched) in the executable but it has no effect in the game. To avoid confusion they should perhaps be removed from the format of custom craft, or commented out. (This rate of fire patching ''might'' work on UFOs, haven't tested it).
:: Can you be more specific? --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: There is a section in '''xcomutil.cfg''' which is used for patching XCom craft weapon characteristics. This is where Scott changed values for the Laser Cannon, etc. Probably very few people use these fields. I only used them because I was doing research into the game mechanics. One of the values changed in this section is the reload time. These values are present in the executable, and can be patched, but patching them has no effect (other than to change the UFOPaedia entry). The reload time seems to be hard coded elsewhere in the executable, based (broadly) on the class of weapon. So you might want to comment this column with an a note saying "cannot be modified for combat". On the other hand I could be wrong, or someone still might want to modify these fields. Discussion is at [[Talk:UFO_Interception#Observed_Rates_of_Fire]]. Offsets are at [[Talk:GEOSCAPE.EXE#Craft_weapon_stats]]. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
:::: Or maybe change these display-only values so that they reflect the [[Talk:UFO_Interception#Observed_Rates_of_Fire|observed reload rates]]? I am not yet 100% sure I have got these right, might want to wait until I do some more confirmation tests. [[User:Spike|Spike]] 15:26, 22 February 2010 (EST)
*EQL only works on turn 1 (see discussion above)
::: Added to my to do list. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)

*Remove 3rd burst for Pistol - it's already good enough, as NKF has shown
::: do you have a link to NKF's comments? --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:::: Having trouble finding his comments, maybe he'll show up here! See [[Rifle_vs_Pistol]], also [[Talk:Squad_Composition_and_Tactics#Starting_Sniper_Weapon]]. If anything there is a case for the Pistol to be nerfed slightly (eg Damage=20, Ammo=8), or for the Rifle to be buffed. Also worth looking through [[Weapon Analysis]] for general thoughts on weapon power and balance. The weapon set in EU is actually remarkably well balanced already.
::::: Further to this - not a bug but it's really wrong for a projectile weapon, a firearm, to have the same accuracy on Auto as on Snap fire (60). Even plasma weapons have Auto accuracy somewhat lower than Snap. If you reduce the Pistol burst mode accuracy by anything less than 2/3rds, the burst function is still useful, but more balanced. Actually even with a reduction of ''greater'' than 2/3rds, it would be useful, because of the increased damage at point blank range. Which is perhaps realistic for a burst-mode pistol. 60 Accuracy is higher than any Auto weapon in the game, for what ought to be the least accurate auto weapon. The best auto firearm is the Rifle at 35. Anything over 20 is still a bonus for the Pistol. How about 25? This still gives burst mode a 25% edge over Snap mode at long ranges, and a big improvement at close/point blank. 30 would make it more accurate than a Laser Pistol is on Auto (28), which is hard to justify. Admittedly the Pistol burst mode uses 3x (?) the TUs, so maybe some latitude can be given. Maybe go to 30 Accuracy, then, but no higher. [[User:Spike|Spike]] 19:49, 11 February 2010 (EST)
:::::: An interesting idea. Scott felt that this was just to make the pistol useful by allowing three snaps to be treated as one action so you dont deal with Reaction fire. The end results is the massive time units and same accuracy. If I lowered the accuracy I would have to lower the time to. I believe there is a reason the pistol doesn't have full auto in the vanilla game. You have seen a military issue full auto pistol? --[[User:BladeFireLight|BladeFireLight]] 21:15, 11 February 2010 (EST)
: Indent reset! I can't remember what my comments were either, but it's probably has to do with the weapon anaylsis and how useful snap shots already are. 'tis a jolly good weapon. I agree that you can't just make the auto mode identical to three snaps - you've got the added bonus of uninterrupted fire for the first two shots. You need to pay this off either with reduced accuracy or increase the usage cost.
: For consideration, I was actually fiddling with the weapons a few months back and was testing a 10% accuracy burst mode at 15% TU costs. I think 10 or 15 AP damage. Turned out way-way too powerful a weapon (against soft enemies) - and this was on a rookie I just picked randomly. It was probably too fast, but it still worked fairly well at 10% accuracy. 60% accuracy does feel quite high. -[[User:NKF|NKF]] 00:14, 12 February 2010 (EST)
:: Exactly. The point is that a 3-rd burst makes the Pistol more useful, ''even if the per-shot accuracy is lower'', because you get 3 attempts to kill the target before it Reaction Fires, rather than just one. As long as the ''net'' 3-rd accuracy isn't less than a single Snap shot, the weapon has been improved. The break-even point is about 26% accuracy on auto. At this level, 3 rounds have a ~60% chance of getting ''at least one'' hit. Even if the 3-rd accuracy was lower than a single Snap shot, you would still get the advantage of multiple hits at very close range. I would strongly suggest no more than 25% accuracy for Pistol auto burst, at the same level of TUs (3x Snap right?). This will definitely still be a significant improvement for the Pistol. Probably what was not fully understood at the time Scott did the original mod, is that the Pistol is arguably ''already'' the most effective starting weapon, certainly against the initial opponents. [[User:Spike|Spike]] 13:19, 12 February 2010 (EST)

* Fusion weapons inconsistently exempted from the "more difficult" energy weapons manufacturing option ("alternate laser Tech"). Blaster Bombs and Blaster Launchers, Fusion hovertanks and ammo, and Fusion Balls and Fusion Ball Launchers - none of these are harder to build or use with the "alternate Tech" option. Why make laser weapons/tanks and plasma weapons/tanks harder but not Fusion weapons? It's not consistent. I wonder if Scott didn't look at these because he never used Blaster Launchers or Fusion Hovertanks, as he considered them to unbalancing already? And ignored FBLs because, well, most people ignore them? But this should be consistent. Or, the "harder weapons" option could be broken down into sub options, e.g. for each weapon technology:
** Much more expensive (typically: add some exotic materials, 10x workshop space and 10x Engineer hours)
** Can/can't manufacture the battlescape weapons/tanks (pure alien weapons only)
** Can/can't manufacture the ammo (pure alien weapons only)
:Personally I would prefer it to be all-or-nothing but include the Fusion weapons as being more difficult to make and use. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)

* SteamSetup.bat won't run from DOSBox. It says "This needs to be run from Windows". Though, does it make any sense to run SteamSetup.bat under DOSBox (eg for a linux system with no Steam)? [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)

* It's actually quite hard to downgrade to DOSBox 0.72 in Ubuntu. Only 0.73 is offered, there is no ability to Force back to a lower package level with Synaptic Package Manager. Unix guru skilz are required to rollback to 0.72, and I guess 0.74 is not around yet, or not packaged for Ubunut APT? Is there any way to fudge around this, e.g. by providing the command line arguments in an optional text file for xcusetup.bat to parse? Having said that, even with no command line arguments, xcusetup hangs on my 0.73 DOSBox while executing SDUMP. I had to reboot in Windows to run xcusetup.bat - something that is only possible on a dual boot machine / Wubi machine. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
** Try using a different batch interpreter like 4DOS [http://www.4dos.info] to execute xcusetup inside DosBox. I tested this throughly before under DosBox/Linux and it works well with recent 9.7 builds. I suggest running "config -set cpu core=dynamic" and "config -set cpu cycles=max" before xcusetup to speed it up (xcusetup doesn't detect DosBox when 4Dos is run, so it doesn't run these automatically unlike normal DosBox case). [[User:Cesium|Cesium]] 09:48, 7 March 2010 (EST)
** Oh, and downgrading isn't that difficult: Get a dosbox 0.72 deb, and run "dpkg -i" on it, and then do "echo dosbox hold | dpkg --set-selections" to prevent future upgrades. [[User:Cesium|Cesium]] 09:50, 7 March 2010 (EST)
** Another option is to install the dosemu package, and run xcusetup under that. EU/TFTD can be run under that, but it doesn't work as well there. (Oh, and there's no mount command there. UFO/TFTD needs to exist under ~/.dosemu/drive_c which is C:) [[User:Cesium|Cesium]] 11:42, 7 March 2010 (EST)

:Thanks Cesium I will check this out. I still think it would be good to have a solution that works for people who are not knowledgeable with the unix command line though. [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)

:: Why use Linux if you dont know how to use the console? It is a text mode OS with a separate GUI. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)

::: Well Ubuntu is a bit different, as it's supposed to be an OS for the general public, where you never need to touch text mode! Incidentally I can't find any DEB or other packages for 0.72, all that is available on the DOSBox website is the source code. They really don't seem to realise that 0.73 is buggy! So I guess I will need to '''make''' it. Or just wait for 0.74 as I think it's out soon. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)

:::: See [http://archive.ubuntu.com/ubuntu/pool/universe/d/dosbox/] for 0.72 debs. Unlike Windows, package systems in Unix land are centralized, so best location to search is typically a package server mirror or a distro mirror, not a vendor's website. [[User:Cesium|Cesium]] 17:36, 9 March 2010 (EST)

* '''cfg/ShipDefU.txt''' has the XCU values for improved Laser Cannon (35/35/35), not the original values (21/35/70). Is this correct - is this file supposed to be the original defaults? [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)
:: I was unawhare that this had been changed. The weapons are not prompted for any change so they should not be changed. I'm reseting them all to defaults and looking to see if Scott had anything about them in the notes. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)

=== AutoCombat issues ===
* Day vs Night
** The Day/night algorithm breaks. For example, at any point when XCom has twice more flare-carrying soldiers than there are aliens, XCom is actually ''stronger'' in darkness than it would be in full daylight. Toward the end of a battle this is a very common situation. But fixing the algorithm is tricky. What might work is to give -10 for each Soldier in darkness, reduce from -20 to -10 for each Alien in darkness, then add back +10 for every soldier with a light source. Thus there is no way XCom can go 'net positive' from light sources.
:: If you have more units then they do you can see more of the battle field. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:::It never makes sense for XCom to be stronger at night, than during the day, for the same force ratio. But that is what happens. An example. 10 XCom soldiers with flares and 3 aliens. At night there is an extra -30 modifier for the aliens, but a +100 modifier for XCom, net +70. The same 10 soldiers against the same 3 aliens are +70 ''more'' effective in darkness than they would be in daylight. It does not make any sense. [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
** The definition of a light source should be expanded to include a Flare ''or'' an Incendiary weapon. In fact, one Incendiary-capable weapon of any type (AC/HC/HjC/GC), with appropriate Incendiary rounds carried, should be enough for the entire squad to be considered as having a light source. But this may be hard to implement without a special flag and a special pre-search for a valid Incendiary weapon, since AutoCombat normally scores by individual soldiers, not by whole squads.
:: This would take a rewrite. currently the ammo is not used by W: --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
** To be honest I would prefer that each soldier without a light source in darkness is 50% effective, each soldier with a light source (personal or squad), is 75% effective. Meanwhile how about this:

//Darkness
-10 L:-9 u:-2 // Human in Darkness

+10 L:-9 u:-2 W:-27 U:- // Human in Darkness w/Flare -OR-
+10 L:-9 u:-2 W:-4 W:-7 U:- // Human in Darkness w/In ammo and launcher HC/GC-IN -OR-
+10 L:-9 u:-2 W:-8 W:-11 U:- // Human in Darkness w/In ammo and launcher AC/HjC-IN -OR-
+10 L:-9 u:-2 W:-12 W:-15 U:- // Human in Darkness w/In ammo and launcher IN Rkt/Torp

-10 L:-9 u:4-14 // Alien in Darkness
:: Only thing I see is that this ''must'' come at the end. The U:- removes the unit from further consideration. --[[User:BladeFireLight|BladeFireLight]] 19:58, 9 March 2010 (EST)
::: Yes, to use the U: flag for this "OR" function, it must come at the end of the section for humans. That's how I have it my updated AutCombt.txt, these fragments are a bit out of context. It's not critical to have the "OR", it's just nice-to-have as it stops someone cheating by having a flare and one of each loaded incendiary launcher weapon in each hand and in their backpack, to get quadruple score. But hopefully people are unlikely to cheat at AutoCombat, there are easier ways such as the WIN flag. [[User:Spike|Spike]] 20:39, 9 March 2010 (EST)
* The Zombie is rated the same as a tank, a Chrysallid/Tentaculat or an effective Psi alien (-50). I think this is too high, as Zombies are much weaker than those units. A Zombie should be maybe -25.
: Disagree. the zombie should be slightly higher then a Chrysallid/Tentaculat as it will become one and you have to kill it twice. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:: OK good point! [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
* Area effect weapons (HE, IN, Small Launcher) should have at least the same bonus as effective-on-Auto weapons (+5). This is because they can damage/kill multiple targets. (The AC/HjC should not get both bonuses however.)

//Area Weapons. ToDo: compensating bonus for aliens. should not be cumulative. check if "effective?"
+5 u:-2 W:-4 W:-6 // Human w/HE ammo and launcher HC/GC-HE
+5 u:-2 W:-8 W:-10 // Human w/HE ammo and launcher AC/HjC-HE
+10 u:-2 W:-12 W:-13 // Human w/HE ammo and launcher Sm HE Rkt/Torp
+10 u:-2 W:-12 W:-13 // Human w/HE ammo and launcher Lg HE Rkt/Torp
+10 u:-2 W:-42 W:-43 // Human w/ Stun/Shok Launcher and ammo
+25 u:-2 W:-40 W:-41 // Human w/ Blaster/DP Launcher and ammo

-10 u:4-14 W:-42 W:-43 // Alien w/ Stun/Shok Launcher and ammo
-25 u:4-14 W:-40 W:-41 // Alien w/ Blaster/DP Launcher and ammo

::Having tested the first 2 rules, the first rule (HC-HE) does not work unless you remove the ammo specifier W:-6, making it just a test for an HC. But weirdly the second rule (AC-HE) works fine with its ammo specifier in place. Odd. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)

* Pistols with the burst mode option should not count as Auto weapons (maybe they don't).
: Burst and snap are based on default stats --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
* Blaster Launchers / DPLs (with ammo) should be worth as much as a tank, e.g. +/- 50 (including the single shot effective bonus it should already get - see suggested rule above under area weapons)
* Should distinguish between tanks. Even with improved armour, a Tank/Cannon is not the same as a Fusion Hovertank. I would suggest a range of 25 for a Tank/Cannon to 75 for a Hovertank/Fusion. Maybe 40 for a Tank/Rocket, 50 for Tank/Laser, 60 for a Hovertank/Plasma?
:This does not seem to be possible with the existing ruleset as all Tanks are unit type 3
::Hmm, byte 42 of [[UNITREF.DAT]] is Rank but also Tank chassis. So this ''might'' allow distinguishing tracked tanks from hover tanks, at least. An alternative approach would be to pick some stat (that has a StatStrings statid) and set it to a different unique value for each tank type. [[User:Spike|Spike]] 18:32, 9 March 2010 (EST)
* Flying units (either side) should be worth say +/- 5
:Not possible for XCom as no distinction between Power Suit and Flying Suit. Would be possible for aliens eg:

-5 T:0- u:6-6 // Flying Alien - Ethereal
-5 T:0- u:8-8 // Flying Alien - Floater

* If the squad is carrying some Smoke or Dye that should be worth maybe +5 - +10. But since the aliens don't ever carry that, you need some balancing factor for them.

+1 u:-2 W:-20 // +1 per human with smoke grenade(s) (hopefully not +1 per grenade!)

* Effective melee weapons should be counted. This is particularly important in TFTD when ranged weapons may be ineffective, e.g. vs Lobstermen.
* Similarly if the enemy are in heavy armour and therefore a soldier/alien does not have an effective weapon, any HE Pack / Alien Grenade / Sonic Pulser should be counted for something (if it is "effective").

//Melee weapons
+5 u:-2 W:1- W:-26 // Human w/o effective ranged weapon but w/ Stun Rod
+5 u:-2 W:3-26 // Human w/ effective Stun Rod (cumulative to above)

::The second rule doesn't work at all, it looks like it counts all items of types 3-6. The "superiority" function (first value before the hyphen) does not seem to operate, probably because it is a melee weapon. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
::: did you try W:255-26 ? not that I know if it would work. AutoCombat doesn't recognize stun rods as weapons when applying damage.--[[User:BladeFireLight|BladeFireLight]] 21:01, 9 March 2010 (EST)

//Grenades
+5 u:-2 W:1- W:-19 // Human w/o effective ranged weapon but w/ effective grenade(s)
+5 u:-2 W:1- W:-21 // Human w/o effective ranged weapon but w/ effective prox grenade(s)
+5 u:-2 W:1- W:-22 // Human w/o effective ranged weapon but w/ effective HE pack(s)
+5 u:-2 W:1- W:-44 // Human w/o effective ranged weapon but w/ effective Alien grenade(s)

-5 u:4-14 W:3-44 // -5 per Alien with effective Alien Grenade(s) (hope not -5 per grenade!)
:: Only one per unit. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)
::: Tested ok too! [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
* AutoCombat victories should award all UFO Components, not just some Navigation, Elerium and Alloys.
* Every Civilian on the map should be a penalty to XCom of maybe -5, due to the distraction effects of trying to save them / avoid killing them.

-5 u:15-16 U:- // Civilian distraction effect, no further effect

Let me know if I should try to work some of this up as AutoCombat rules. Some of it requires new coding of course, but a lot of it could probably be done with existing rules. [[User:Spike|Spike]] 13:15, 7 March 2010 (EST)
: I dont plan on any changing to the underlying code yet. Your welcome to make up a new set of rules and testing them out. --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
:: OK added some rules above. I have not tested them yet, some of the syntax might not work. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)
::: Syntax looks good to me. Give them a test and let me know how they go.
::: Just a quick note on how AutoCombat works. First the success percent chance is calculated using the AutoCombat StatStrings, dead and unconscious units dont count. (those that bleed to death are considers alive, need to fix this). If it's below AbortThreshold it aborts. If it's 100-199 then change to 90. 200+ change to 95 (success is never a guarantee.) Aliens roll d100, if over your success chance you lose. If You win. Then average damage by each side is calculated based on Loaded weapon being carried and time units. All aliens are killed or stunned by X-Com unit chosen at random. Each Alien gets a chance to wound an X-Com unit based on Success Percentage. Randomly choose unit using random damage (max is average alien damage) Leave at least one X-Com Unit alive. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)

==Fixed Bugs==
* standalone patches the fix the difficulty bug
::9.7 min install is the dificulty patch and changeing Copy protection questions to all 0's.
*Prompted Terrain displays the options but the prompt doesn't display until after a key press.
:: I guess Open Watcom's version of printf does not auto flush to the screen like Borland did.
*Version detection issues with obscure versions (Italian, 1.2a, etc.) causing corruption or lack of patching.
:: Cesium; XcomUtil doesn't have the offset for the copy protection for the Italian version coded. However the file you sent me is detecting as 1.3. none of the offsets will line up. The offsets Scott used to detect Italian are unique and may have been based on 1.0 or 1.2. Was that a clean unmodified copy? I need a clean one to validate all the offsets and update XcomUtil. --[[User:BladeFireLight|BladeFireLight]] 13:23, 16 February 2010 (EST)
:: I loaded it up and notice it does not ask for a language. this would imply it's based on X-Com 1.3 and not UFO 1.3. --[[User:BladeFireLight|BladeFireLight]] 13:33, 16 February 2010 (EST)
::: I didn't send you the installer since it's a mess (it requires some subst magic to work), but it looks authentic. Use the same link as before if you want to take a look at the installer. There's an Italian readme attached which points to some (now defunct) Italian sites. I didn't do any changes besides installing X-Com and then testing out XcomUtil. [[User:Cesium|Cesium]] 14:01, 16 February 2010 (EST)
:::: Italian UFO detection and offsets added, 1.2a offset's fixed.

*Various default options make the game easier, not harder (''harder'' being the intent of XComUtil, right?). These should not be defaults. (More discussion at [[Talk:Enemy_Unknown_Extended#Standard_Config_Discussions]]) E.g.
::: 9.7 only has 3 items on by default. Remove copy protection. Fix Difficulty bug and Split EXE (split EXE can be skiped but not the others). All other options are default to NO.
::: As for the intent of XcomUtil. Scott added features to
:::# Increase difficulty.
:::# Make useless items useful.
:::# Get the game Started faster.
::: I have added:
:::# Don't make unwanted changes.
:::# Fix game bugs
:::::Yes all of those are very sensible. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
::::Latter versions of XcomUtil will turn the last two forced items to prompted. with only the Difficulty bug and the split EXE as Default=Yes. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
**Basic tanks using advanced tank stats
**Improved High Explosive - very powerful in favour of X-Com, especially as alien spawn points and routes aren't set up to cover holes in UFO hulls.
**Gauss weapons have infinite ammo
::: 9.7 has a second option to just the increase power to closer match UFO.
**Using fighters as transports (carrying soldiers)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
**Using transports as fighters (weapon hardpoints)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
**Improved Heavy Laser / Heavy Gauss. OK, this should maybe be a ''recommended'' option since the unpatched weapons are nearly pointless. But, it does make the game easier.

[[User:Spike|Spike]] 20:12, 7 February 2010 (EST)

=XComUtil Wish List=
Things that are not bugs or inconsistencies in XComUtil but would be Nice To Have

== Features for 9.7 - Interface, consistency and bug fixes ==

=== Categorise Config Options ===

For each option, in the prompt, note which category of option this is, according your list above. E.g. faster start, making the game harder, making useless items useful, bug fix, variant game, etc. [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)

:Actually it might be even better to organise the options questions into sections, thematically grouped by these categories. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

:: Items are currently sorted like this.
* Windows EXE
* Game Fixes
* Game Mods
** Sound
** Craft
** Base
** Equipment
** Research
** Units
** Battlefield
** Alien Craft
** Misc
--[[User:BladeFireLight|BladeFireLight]] 19:25, 10 March 2010 (EST)

=== Improved Base Comes At Cost ===

The Improved Base is supposed to be a "faster start" option rather than a "make the game easier" option. But it does make the game easier, not least because it gives you a load of free base facility improvements. (Not to mention not having to struggle along the first month with only Small Radar and no Alien Containment) To partly avoid making the game easier, please add a sub-option that subtracts the cost of the extra facilities from your starting cash. This should be the ''full'' cost of the extra facilities, not just the difference between e.g. a Small Radar and a Large Radar.
[[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
: I dont have the offsets to the starting money ranges. so I cant do this. --[[User:BladeFireLight|BladeFireLight]] 19:13, 10 March 2010 (EST)

=== BFG Default To Unchanged ===

Is it possible when using the BattleFieldGenerator, for it to detect the actual conditions for the mission (terrain, enemy craft, and light level) and offer these as defaults? [[User:Spike|Spike]] 08:22, 13 February 2010 (EST)
:Press The esc key at the prompt. (Line 719 in Xcomutil.txt, not that I expect anyone to read the manual :) ) Enter should also work. --[[User:BladeFireLight|BladeFireLight]] 12:34, 13 February 2010 (EST)
:: RTFM eh? My biggest failing. Maybe you could add an explicit prompt "Esc or Enter = [whatever the unmodified value would be]". [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)
::: From what I can see, hitting Escape during BFG makes it continue with ''all'' values reverting to the original conditions. It would be nice to be able to select some but not all original conditions. My main use of this is to turn a night mission into a day mission without the hassle of keeping the landing craft hovering around until the terminator crosses the landing site. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
:::: You could just use the force all daylight option.
:::: After reviewing Scott's code. Esc leaves all setting as-is. Pressing enter or any other key not listed will randomly choose for you. I will see if I can change enter to leave as is. --[[User:BladeFireLight|BladeFireLight]] 11:00, 7 March 2010 (EST)

== Features for 9.8+ - New features ==

=== AutoCombat ===

==== Firepower Factors ====
You might want to consider replacing the weapon offensive weighting factors for Autocombat with some factors that are (inversely) related to the [[Weapon_Analysis#Quantitative_Analysis|% TUs Per Kill]]. I've tabulated these for each weapon (including tanks) vs each alien race. You would still need to account for Psi, light/darkness, and XCom armour. Plus you would need a similar offensive factor for the aliens' attacks. But I could probably help with that, I have the data that's directly comparable to the % TUs per Kill for XCom weapons. [[User:Spike|Spike]] 22:06, 12 February 2010 (EST)

==== AutoWithdrawal ====

One of the most tedious things you can try to do in XCom is to scavenge the battlefield and retreat to landing craft for an Abort. A great option would be an AutoWithdrawal, similar to an AutoCombat, but with an easier threshold of XCom vs Alien combat power.

Basically it would scavenge all loose equipment off the Battlescape - dropped friendly and alien items, friendly and alien corpses and wounded, all go back into the landing craft. Elerium, Alloys, and UFO Components would not be recovered, as this is (normally) impossible apart from full tactical victory. All friendly troops return to the landing craft. Friendly losses, and equipment recovered, would be proportional to the offensive factor ratios but much more favourable than for AutoCombat. E.g. as long as XCom factors were at least equal to Alien factors, they would be able to scavenge everything and recover without casualties. If the aliens were stronger than XCom, they would only recover part of the scavenged equipment, and risk partial casualties, at say one third the rate of AutoCombat. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

: It's too easy compared to actual game IMHO. Every time a battle went FUBAR for me, it got FUBAR all the way and I was lucky if I could salvage my own team/equipment and maybe a single alien weapon/body. An AutoWithdrawal without salvage might be useful, but perhaps instead we should change AutoCombat failure mode to work better (e.g. Make some X-COM people survive a failed AutoCombat, depending on strength vs aliens). [[User:Cesium|Cesium]] 15:00, 7 March 2010 (EST)

:: Yes fair point. I was not thinking of the FUBAR situations, and you are right about how hairy those are. I was thinking of the situation where you control a certain part of the battlefield, but you either don't want to go on an endless hunt for the last few aliens, or you pretty much know you can't take on the aliens that are left (e.g. in the UFO or some other stronghold) without getting creamed. You can exercise a safe withdrawal, it's just tedious to carry out all the bodies and equipment. But it's pretty hard for an AutoCombat algorithm to detect which of those situations it is - FUBAR, boredom, or tactical withdrawal. I'll have to think about that, there may be no realistic solution at all. And there is the existing "teleport loose items back to base" command line option to XComUtil, maybe that's enough. [[User:Spike|Spike]] 16:08, 7 March 2010 (EST)

=== Tougher UFOs ===

[[Wish_List_(EU)#Tougher_UFOs|Tougher UFOs]]
As this is entirely implemented by patching data and data files it is a good candidate for XComUtil rather than [[UFO Extender]].
: That would definitely make the game harder. 9.7 is about the installer and the bug fixes. This would be a good candidate for 9.8. --[[User:BladeFireLight|BladeFireLight]] 01:38, 19 February 2010 (EST)
:: Cool! [[User:Spike|Spike]] 02:25, 19 February 2010 (EST)

=== Rebalanced Craft Weapons ===

This fits under the "making useless things usefull" category. It would be a 9.8 or later option. The idea is to make the Cannon, Stingray, Laser Cannon and Fusion Ball Launcher useful. Hopefully it breaks up the monotony of Dual Avalanches followed by Dual Plasma Beams, every game.

There is one common element in the approach, and two options. The common element is to fix the stats on the Fusion Ball Launcher. The two options are to use a stat-based approach, or a cost-based approach, to fix the other weapons.

NB This proposal is still a draft and will need tweaking, but I've got it to the point where it is worth discussing. Feedback is welcome!

''(Ultimately, the Plasma Beam still ends up being pretty much the optimum weapon in the end game. To mitigate this, it is a good idea to select the existing Alternate Energy Weapons Manufacturing option in XComUtil.)''

==== Fusion Ball Launcher ====

Increase the ammo capacity from 2 to 3. Don't mess with the damage. Job done.

See [[User:Spike#Fusion_Ball_Launcher]] and discussions linked from there.

==== Cost Based Approach ====

This uses historically realistic costs to restore game balance between different craft weapons. The stand off advantage of Avalanche missiles is now purchased at a price which is significant in terms of XCom budgets and mission yields. Stingrays and Cannons become significantly cheaper alternatives. The Laser Cannon, with similar capabilities to Stingrays but free to operate, also becomes very attractive. Mounting dual launched weapons becomes a very expensive luxury.

*Increase Avalanche missile Purchase cost to $386,000
*Increase Stingray missile Purchase cost to $125,000
*Leave Sell prices unmodified (to avoid creating a cash reservoir at the start of the game)
*Leave Launcher buy/sell prices unmodified

See [[User:Spike#Cost_Based_Rebalancing]]

==== Stat Based Approach ====

This provides a benefit trade-off to shorter range weapons, by increasing their firepower or effectiveness relative to longer range weapons.

*Increase Cannon stats to 15 Damage, 50% hit. Firepower is tripled, slightly ahead of (unmodified) Avalanches launching in Aggressive mode. Increase rearming rate to 200.
*Increase Stingray accuracy to 80%. Decrease Avalanche accuracy to 60%. Stingray now has 50% more firepower relative to Avalanche. Increase Stingray rearming rate to 2, so a full craft can be re-armed in the same time period with either weapon (instead of twice as long for Stingray).
*Increase Laser Cannon stats to 100 Damage, 50% hit. Firepower is doubled, 20% more than (unmodified) Avalanches launching in Aggressive mode, 2/3rds of Plasma Beam firepower.

To avoid advanced XCom aircraft exploiting the extra firepower of the Cannon weapons and disregarding the return fire from UFOs, this is best used alongside the Tougher UFOs option.

See [[User:Spike#Stat_Based_Rebalancing]]

=== Rebalanced Infantry Weapons ===

See [[User:Spike#Balancing_Infantry_Weapons]]

Primarily this means making the Rifle a bit stronger, and probably making the Pistol a bit weaker.

==See Also==

[[Wish List]]

= Completed Wish List Items =

==Easier Inventory Management==
Inventory management is one of the things I hate about the first two X-Coms. I was hired to be a commander, not a supply clerk! A mod which made general stores have 10000 space (like Apoc) would be nice.. [[User:Cesium|Cesium]] 21:39, 9 February 2010 (EST)
: The manager of any facility has to deal with generalities of space issues. The clerk tells you if that fancy new tank you just bought will fit. He has to put it in storage and keep track of what shelf the ammo is on. --[[User:BladeFireLight|BladeFireLight]] 22:27, 9 February 2010 (EST)
:: That's the clerk's problem and if he complains too much I'll have him peel potatoes until his hands drop. In any event, the limit doesn't make any sense:
::* General stores size is 8x8x2 (8x8x3 in TFTD) per base defence map, and should have no problem storing more than 50 items.
::: The items taking up 1 item unit are typically about the size of humanoid body. I think it's not unreasonable to have no more than 50 of those in the area that the General Stores takes up.
:::: I can't find a list on the wiki of storage space requirements for items, so I'm not sure which items take up 1 item unit. Typically the main space wasters are Heavy Plasma ammo/Blaster Bombs/Stun Bombs (late game) and/or HWPs and avalanches (early game). These either are definitely not the size of a human body (ammo/Bombs), or shouldn't be stored in stores at all (HWPs gain nothing, and might as well lay around somewhere else in base).
::* The size of a fully built X-Com base is about the size of a city block (judging by comparison of base defence to terror missions), and should easily be able to hold hundreds of items even in the starting base if it's willing to put some stuff not in the general stores.
::* The space limit makes no sense. Why do Blaster Bombs and Heavy Plasma ammo take so much space whereas in the inventory view it doesn't take any more than normal ammo? Who stores <s>mini tanks</s> HWPs in the same compartment as light weapons? And the way X-Com (probably) stores ammo and explosives is scary...
::: As you suggest, extremely powerful ammunition probably requires a lot more space for safe and secure storage in-base, versus on a tactical mission. Imagine what would happen if a Blaster Bomb exploded in a base? Or was stolen? They probably use nuclear warhead style storage facilities for those. And similarly for Avalanche warheads, alien artifacts, Elerium, etc. Segregating dangerous/explosive items from other items probably uses up a lot of overhead in the construction of the storage space - think armoured, bomb-proof lockers and bulkheads, advanced security systems, airlocks, scanners, etc. This is not just like piling stuff up in your shed! And the Commander who left Elerium or Avalanche warheads lying around in his hanger or corridors would justifiably be sacked on the spot by XCom High Command. [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Well, judging by all the explosives in the hangar during base defence and the X-COM 1.0 Elerium bug, Elerium and explosive warheads ''are'' lying around in the base... And all the equipment in the General Stores is stored in ordinary lockers according to the General Stores map ;-) More to the point, if X-COM wants to store explosives safely (judging by said warheads X-COM doesn't care too much) they need a special facility for this, not to store them in the room which also contains all the base's weapons and priceless alien artifacts.

:::: Furthermore, I expect X-COM to improvise on storage in the interest of actually winning the war. X-COM does do this and ignore the limit when manufacturing stuff in-base or getting loot from missions. All that's needed is that X-COM will improvise for transfers too. I can't imagine a quartermaster informing the commander there isn't any room for the new armour and that the troops should go without. Maybe the reason X-COM doesn't pay quartermasters each month is that they keep getting themselves lynched by enraged X-COM troops...
::* Gameplay wise, inventory micromanagement is just no fun, especially in the late game when you have all the cash you need but still has to sell stuff after each combat (which can be prolonged if you haven't sold for awhile), otherwise you can't transfer items to the base where your main team is at.
::* Maybe this entire "stores" thing is a plot by the CFN to force X-Com to share its technology with them by forcing X-Com to sell sell sell. It's not like they pay X-Com the real worth of the technology anyway. [[User:Cesium|Cesium]] 23:47, 9 February 2010 (EST)
::: I think a lot of people do find the inventory management tedious, or unrealistically low. Personally I think it's about right for large equipment (missiles, tanks, bodies), but too low for small arms and personal equipment. And yes, it only reflects using the General Stores modules, not storing stuff at random points in the base - maybe fair enough. If the right offset to patch can be found, the storage limits could easily be raised. The last few bytes of [[BASE.DAT]] could be a good place to look for this offset. BASE.DAT can store up to 9,999 units of each item per base. The total limit for items per base would need to be found by experiment, but 9,999 might work for those who want to ignore inventory. For those who feel inventory management is OK but the limits set too tight, the capacity of each General Stores could be increased from 50 to 100 - assuming we can find the offset for this to patch it. [[User:Spike|Spike]] 19:50, 10 February 2010 (EST)
::::Maybe you can try there:
.text:00439C85 66 81 C5 F4 01 add bp, 500
::::[[User:Seb76|Seb76]] 13:03, 11 February 2010 (EST)
::::: Yes that works nicely. E.g. patch '''66 81 C5 E8 03''' at that location and you get 100 space per General Stores. Thanks Seb! [[User:Spike|Spike]] 18:21, 13 February 2010 (EST)
:::::: Now if only I had the offsets or search signature so we can add that as an options --[[User:BladeFireLight|BladeFireLight]] 18:24, 13 February 2010 (EST)
::::::: UFO 1.4 dos: offset 143748. TFTD 2.1 dos: offset 178462. TFTD v1 dos: offset 176861. TFTD CE: offset 252795. UFO CE: offset 236680. (all offsets are in decimal and point to the "F4 01" value to be patched).
::::::: Patching to "E8 03" has been tested on dos versions (not on CE) and it works. The "base information" screen will display the correct value, though the values to line length scale is such that the line will max at 250. [[User:Cesium|Cesium]] 05:57, 14 February 2010 (EST)
::::::::Are the preceding bytes the same from TFTD 1 and 2x? --[[User:BladeFireLight|BladeFireLight]] 17:26, 15 February 2010 (EST)
::::::::: Yes they are. '''81 C3 F4 01''' is the add instruction. [[User:Cesium|Cesium]] 17:48, 15 February 2010 (EST)
::::::::: Sig for UFO Dos is '''81 C6 F4 01''' --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
:::::::::: Do you also have the preceding bytes for UFO? with the signatures I can create a patch file for all versions --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
::::::::::: I am not sure I understand your question.. Judging the the two UFO versions I have available (1.3 per xcusetup and 1.4) the common preceding bytes are ''80 78 16 07 75 0C 80 78 3A 00 75 06'' (followed by the sig). You could try to use the sig alone - it exists only once in the file. [[User:Cesium|Cesium]] 19:35, 15 February 2010 (EST)
:::::::::::: Offset Locations are something I'm collecting but also the unique series of bytes to find them for the two geoscape/tactical that I dont have. (UFO Spanish, TFTD Italian) I hope to add a lot more options in the in the future. I do feel this one nerfs the storage system anything to get the game up and going faster is always a plus. --[[User:BladeFireLight|BladeFireLight]] 22:01, 15 February 2010 (EST)
::::::::::::: Well, you may want to add another General Stores to the improved starting base if you want to achieve the faster startup effect without "nerfing" storage system for rest of game (I prefer a "nerf" due to late-game reasons). Also, I suggest you add an message in Xcusetup to ask people to get in contact with you if they use an unknown/unrecognized version. [[User:Cesium|Cesium]] 14:27, 16 February 2010 (EST)
::: Inventory management is just as much a pain in the early game, where you almost always are out of space until your 2nd general stores is built. I like realistic constraints, but not tedium. Maybe upping the space per Stores from 50 units to 100 units would be a generally acceptable approach (now that Seb76 has kindly found the offset)? [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Yeah, that would be a great improvement. [[User:Cesium|Cesium]] 15:45, 13 February 2010 (EST)

:I can confirm Seb76 is correct, as ever. The 2 bytes at offsets '''0x39c88''' and '''0x39c89''' in geoscape.exe code for the capacity of each General Stores. Default value is 500 ('''F4 01''') which equates to 50 in-game internal capacity units. (Smallest item uses 0.1 in game capacity so I guess that is 1 unit in internal units). I am not sure about a signature. From what I can tell, the preceding bytes '''66 81 C5''' are unique in geoscape.exe, which seems pretty odd, so someone else should verify that. [[User:Spike|Spike]] 19:48, 13 February 2010 (EST)
:: Yes it is unique to CE. it does not exist in any DOS EXE, but "F4 01" can be found in 79 places. Trial and error could locate it. --[[User:BladeFireLight|BladeFireLight]] 20:50, 13 February 2010 (EST)

Talk:XcomUtil

2010-03-11T03:52:51Z

BladeFireLight: /* Build 435 */

=XcomUtil 9.7 Beta=

9.7 Beta is available on www.bladefirelight.com

==Release Notes==
===Build 200===
This is a Beta, so backup your files before using. If you have issues pleas post them to XcomUFO.com in the XcomUtil forum.

New in this version.

*Major overhall of the installer (XcuSetup) and the inclusion of 16/32bit exe's to support both DOSBox and Windows Vista/7 x64.
*New subfolders added to hold supporting files making the install c leaner
*New XcuSetup options were added to XcuSetup allowing for silent install and uninstallation.
*New XcuSetup option for debugging the install (XcuSetup debug) creating debug.txt.
*XcuSetup now can have minimal impact on the game.
**All options default to NO.
**Almost all changes are now prompted for (skyranger guns, interceptor as transport, Disjointed Base Bug, etc...).
***Items still done by default:
***Copy protection questions set to 0000000 for UFO 1.0-1.3 and X-Com 1.0
***Difficulty bug fixed in UFO 1.0-1.4 and X-Com 1.0-1.4
***Unique names for all maps in TFTD, Used for Hybrid Games
*XCOMUTIL.CFG is now pieced together and overwritten by XcuSetup (see XcomUtil.txt for how to make permanent changes).
*All game files are restored to the pre-XcomUtil state each time XcuSetup is ran. Any modifications by other utilities will have to be re-applied.
*Recovery of MIA soldiers has been removed as it had a habit of resurrecting all KIA units to.
*Vista/Win7 patch now an option for XcuSetup.
**This will fix the blank screen issue.
**Updated to support the split EXE.
*XcuSetup attempts to fix UAC issues by resetting folder permissions.
*A number of community made fixes are included and selectable with XcuSetup.
*Support for the DOS/Window STEAM Install.
**Windows EXE, just run XcuSetup from windows
**to launch Dos version from Steam Run XcomUtil/SteamSetup.bat to activate menu then lauch from steam.
*Out of the box support for UFO Extender. XcuSetup will detect it and ask if you want RunXcom to use it.

NOTE: If you use DosBox, this requires DosBox 0.72 (Does not work on 0.73)

--[[User:BladeFireLight|BladeFireLight]] 18:28, 17 January 2010 (EST)

===Build 204===

* Fix the goto and "ser" issue
* Fixed the version display on the DosBox version detection is back on.
--[[User:BladeFireLight|BladeFireLight]] 16:15, 18 January 2010 (EST)

===Build 219===

ok. Just posted Build 219

*New command line argument "nobackup" skips backup only if it has been ran.
*Fix f0ders loader path and option goto so it actually works.
*Fix prompted terrain option to create correct flag file.
*f0ders loader now available to Vista and Win7 users. (I have no idea if this will be of help)
*replace "if exist" on folders with "if exist" on file.
*Allow 0.73 with no command line args (as this is all it brakes)
*%X-COM% to %XCOM% for older OS's
*Fixed the beta message display
*Fixed version display in deader
*Fixed misleading message in SFX install scrip.
--[[User:BladeFireLight|BladeFireLight]] 22:57, 18 January 2010 (EST)

===Build 221===

*Fix issue following issue with XcomUtil and STEAM.
**only creating backups of the Windows EXE
**only applying changes to the DOS EXE's

STEAM USERS need to run "Verify Integrity of game cache" before updating to this build.
--[[User:BladeFireLight|BladeFireLight]] 18:02, 20 January 2010 (EST)

===Build 305===

Some major restructuring of Environment Variables to fit within the limits of the forthcoming DosBox 0.74. Previous LastOp.bat files will no longer work. (should limit XcuSetup's Environment usage to about 980 bytes. Will no longer crash DosBox 0.73 by overrunning environment buffer)
Corrected a massive error that caused corruption on x64 systems.

I recommend you uninstall the previous version of XcomUtil before installing this one. (or delete LastOp.bat)

New items:

*Backup and restore of additional folders added.
*Allow install on Unknown OS with warning.
*Re-order some option questions and adjust wording.
*Correct File location that was causing Random ship generation to hang or crash.
*Fixed Vista/Win7 Patch to run on Vista. (Thanks Dangermouse)
*Environment Vars size shrunk. This invalidates previous lastop.bat (Thanks to Peter on the DosBox Team)
*Fix issues with using space in IF statement in dosbox and Dos 5.0
*Clean up environment test variable to free up space
*Backup and Restore: Fixes time out issues on DosBox. Adds progress display.
*Set Default to split EXE.
*Allow xcusetup for Dos games in x64 OS with warning
*Switched compiler to Open Watcom for ResFix and ResINfo
*New code to detect EXE version and adjust Max Research in ResFix and ResInfo
*Resfix will no longer execute on UFO
*Switched compiler to Open Watcom xcomutil xcomutrt and sdump.
*Fixed issues with 32bit structure packing leading to wide spread file corruption
*Fixed Alien Research Help math error
--[[User:BladeFireLight|BladeFireLight]] 18:28, 6 February 2010 (EST)

===Build 317===

Don't forget to re-run XcuSetup after you extract the files. For a almost quite install use "XcuSetup lastop skip"
If upgrading from pre-305 versions you need to uninstall with "XcuSetup uninstall" and run XcuSetup Fresh.

You can now use XcuSetup in Windows to configure a game you intend to play in DosBox OR run XcuSetup in DosBox and play from Windows. Even on x64 systems. XcuSetup can be slow in Dosbox this will allow for faster setup.

RunXcom now makes on-the-fly choices about x86 vs x64 XcomUtil EXE's and Steam Dos vs Windows. If you have Vista or Win7 x64 and a Steam copy you can switch between Dos/Windows Xcom by either runing from Steam or directly starting RunXcom.

A few caveats for STEAM users. Because of how XcomUtil detects the game, while XcuSetup will apply changes to both EXE's. Running XcomUtil from the command line will only effect the Dos version.

Complete List of changes.

*XcuSetup can be run from windows and RunXcom run from DosBox
*Renamed "New Laser" to Alternate Laser
*SortStats now back in XcomUtil.cfg
*Runxcom now uses x86 or x64 EXE's based on OS at time of execution
*Steam choice of Windows or DOS EXE now based on if RunXcom is started in DosBox.
*Xcomutil settings applied to both EXE's in Steam
*SteamSetup.bat displays message on success.
*Minor error fixes with 4DOS
*Better handling of unknown OS.
*New Steam Menu Options
** Run X-Com Sound Setup
** eXit to Windows
--[[User:BladeFireLight|BladeFireLight]] 03:21, 8 February 2010 (EST)

===Build 333===

Some Minor tweaks. Only major thing is I have given up on DOSBox 0.73 it's to buggy and crashes often. Although some of the bug fixes I worked out with the DOSBox dev team will not make it in until 0.75. They tell me most of them will be in 0.74 and it should not have this issue.

Luckily STEAM uses 0.72 and works as expected.

If you run another Command interpreter like 4DOS it should work.

*Random alien craft shape now works.
*Fixed Text color on BFG prompting on UFO under DOSBox.
*XCLoader.exe properly removed on uninstall and Gamefile restore
*Fixed display of Unit type on Fighter as transport prompt.
*Apply of Seb Loader from DosBox fixed.
*Commented RunXcom
*Removed Exit Point and replaced with Pauses in XcuSetup
*Updated DOSBox 0.73 error (to unstable. frequent buffer overflows setting ERRORLEVEL on program exit.)

-Blade FireLight

===Build 339===

This fixes the issue with 4DOS failing to do an initial backup, that lead to SDUMP being unable to apply patches, that led to empty designation files.
9.6 replaced the Hammer Head map by default. 9.7 does not but the unit placement was never updated. The 12 unit placement section has been added to fix units spawning outside the craft. (Scott's version of the Hammer Head is in the patches folder but requires manual modification of the config files to fully use. )

*Disable stderr redirection on 4DOS
*More debug and ArchFile now able to be run independently
*Add unit placement section for standard Hammerhead.
*Added Apply of Transport Hard Point.
*Fix Missing Terrain on TFTD Very Small

--[[User:BladeFireLight|BladeFireLight]] 21:14, 12 February 2010 (EST)

===Build 340===

*Fixed missing label causing exit in build 399.

--[[User:BladeFireLight|BladeFireLight]] 01:48, 13 February 2010 (EST)

===Build 348===

Fixed some obscure bugs.
Win7 32x on some computers would not run 16bit code(something to to with chip-set drivers and the 16bit xcopy), so now all NT based Windows will use 32bit EXE's.
Some STEAM users had issue with the windows EXE either being replace by or replacing the _patched.exe (f0ders loader) I saw this happen but was unable to repeat it. Hopefully the change of not using short file names when long ones can be will fix this issue.

*Fix BFG Prompting Display
*replace delete with del in RunXcom
*32bit EXE used on most versions of windows.
*Skip copy short file name if can find long file name.
--[[User:BladeFireLight|BladeFireLight]] 00:44, 14 February 2010 (EST)

===Build 350===

The EXE download now uses an updated script to prompt for steamsetup (if detected) and start xcusetup. This makes it more "consumer friendly".

*New SFX Installer Script.
*Cleaned up / updated xcomutil.txt and moved to xcomutil folder

--[[User:BladeFireLight|BladeFireLight]] 18:49, 14 February 2010 (EST)

===Build 361===

By popular demand the EQL now works on any turn.

*EQL allowed any turn.
*Fix Display of Forced patches for UFO Spanish/Italian
*Fix BFG questions to avoid invalid options.
*Add Xcom UFO Italian Support

--[[User:BladeFireLight|BladeFireLight]] 19:28, 17 February 2010 (EST)

===Build 384===

Lots of bug fixes. Hybrid now working, Fixed issues with auto combat and combining clips.

*Fix Hybrid Implementation
*Auto Combat will not run on second half of two part using first parts saved data.
*Auto Combat will no longer run if combat was won.
*MIA Recovery on won combat only
*Auto equip no longer triggers on second part of 2 stage missions.
*Add skip of combine clips if between stages of 2-3 part missions.
*Lost of debug info to in XcomUtil.log
*Add Headers to XcomUtil.log section brakes.
*XcomUtil's Apply action now in debug.txt
*Update and move f0dders read me per his request.
*Fixed typo stopping Lab PSI/MC Screen from working.
*Fix Infinite loop when not splitting EXE
*Fix nonexistent %no% variable
*Limit STDERR redirection to MS OS's

--[[User:BladeFireLight|BladeFireLight]] 02:44, 22 February 2010 (EST)

===Build 413===

Fixed Hybrid and Prompted BFG on Windows EXE's. Hybrid now uses Boom Blokes Pallet conversion. (removes lighting artifacts) "XcomUtil uninstall" now removes the hybrid game maps and terrain. Updated the Vista/Win7 patch. Recommend applying if you get odd colors that only go away with a reboot or playing a video in Media Player. Created new Add-on ability to allow others to plug-in to XcuSetup and RunXcom.

*Add-on support added. see XcomUtil\XcomUtil.txt and XcomUtil\Addon\Example.txt
*Restore and Backup ran second time on Hybrid games to resolve issues with cross pollination
*Update Vista/Win7 Patch to address alt + tab color issues. (restores color pallet on next start of Goescape or Tactical. Does not stop the corrupt pallet)
*Create windows flag file to force XcomUtil to update windows EXE when playing Xcom Windows
*Better UFO Hybrid integration and uninstall of copied files.
*Bomb Bloke's Hybrid Pallet Map
*command line option for config file now searches %CWD%\, %CWD%\XcomUtil\ and %CWD%\XcomUtil\Batch\
*Hybrid path detection change to look for \maps\ATLAN00.map OR %1\maps\URBAN00.map
*Move XcomUtRt and LastOp to sub-folders older LastOp moved if it exists.
*All Flags moved to the flags folder.
*If debug.txt exists zero out file (deletion caused problems with WinTail)
*uninstall a few missed files.
*Fix debug log of config flags.
*Fix echo------ error in RunXcom.bat

--[[User:BladeFireLight|BladeFireLight]] 17:40, 28 February 2010 (EST)

===Build 422===

*Fixed unit placing where units were placed outside of sub or inside of tanks.
*Fixed Display of Starting Transport and Fighter names for TFTD
*Updated addon example.txt to streamline and clarify a few things.
*Switched to Bomb Bloke updated Color Pallet
*Units who bleed to death no longer rise from the grave. (unless they die the same turn as you kill the last alien)
*Units under mind control when the last alien dies are no longer MIA.
*Fix messed up goto in Line 8 used for addons (Was causing exit of RunXcom)
*Fix RME error

--[[User:BladeFireLight|BladeFireLight]] 02:33, 2 March 2010 (EST)

===Build 435===

Original Sound Effects from UFO were re-sampled to work with 1.4 and CE.

*Add Category to option headers.
*Improve randomness by using current time instead of game date/time in srand()
*Added Option to keep Current terrain/UFO to BFG.
*Original UFO 1.2 Sounds for Geoscape and Tactical added as an option for UFO 1.4 and CE.
*Force Split EXE on STEAM. Fixes issues with setup failing.
*Reset Laser/Gauss craft weapons stats to be default.
*Example addon now uses different flag extension to avoid deletion by XcuSetup
*fix issue with Lab Screen on DosBox always screening

==Beta Disscusion==
===Build 219===

: Well, I tried running it, and noticed a few errors in the batch setup system:
:#The existence of a directory can't be tested by using "if exist". It won't work on real DOS and many DOS emulations. The suggested workaround fails sometimes (see [http://support.microsoft.com/kb/65994] or [http://www.faqs.org/faqs/msdos-programmer-faq/part3/section-7.html]).
:#* I dont have access to every platform. Your help on this would be invaluable.
:#** It's been a long long time since I wrote batch scripts... First, I suggest creating the directories unconditionally (redirect output or clear screen if you're worried about error output). Second, either drop checking for game_1 directory existence afterwards or if you must check for it - write a dummy batchfile into the directory which only runs one command: a command which exits with a specific known errorlevel (probably sdump or other xcomutil binary would work). Then try to run said batch. Then you can test for said errorlevel - if it's there, than the directory exists. Then erase dummy batchfile.
:#*** My solution is similar. i'm using the dum.bin If it dosent exist create the directory with >>%redir% and copy in a dum.bin. should work on any OS.
:#Please don't test existence of correct running environment for X-COM in the setup file (e.g. don't prevent patching windows version while running in dosbox, or vice versa). Or at least don't abort the setup, but just print out a warning. This is patronizing - it's none of Xcomutil business, and people who downloaded this probably already know how to run software. Besides, this is likely to ruin at least some possible combinations. Maybe some future bug in dosbox/Windows will make people want to run the setup batch file under cmd.exe/dosbox? Or maybe some people may even want to run XCOM CE in [http://www.winehq.com Wine] for example, and the check keeps in the way? (Also there's a spelling error - "hoast" -> "host").
:#* I dont expect everyone who got the game for the first time from STEAM to know their way around the computer. If RunXcom uses 16bit EXE's setup in DosBox in Windows 7 x64 it will throw an error. I could integrate the system checks into RunXcom so It can select the right EXE's however for STEAM and similar setup with both EXE I would have to setup a menu in RunXcom to select what version to actually use if they have Steam on a 32 bit platform.
:#* I dont intend to support OS2 or Wine like Scott did. What OS's I can support will be based on what feedback I get and what I have the time/interest in fixing.
:#** Then can you add a parameter to let us override the checks without editing xcusetup? These checks are bound to fail for some OS/dosbox combination now or in the future...
:#*** It's not that simple. The values in the syscheck are required for making decisions. like is the OS x64, is the game UFO or TFTD. does the OS have UAC. will the OS accept SHIM's. Can I find the files needed to run the commands ... --[[User:BladeFireLight|BladeFireLight]] 20:53, 18 January 2010 (EST)
:#4DOS (v7.5 and v8) at least don't like X-COM environment variable name (it returns -COM when doing %X-Com%), and I suspect it may not work under MS-DOS's COMMAND.COM either. Try something like "%X_Com%" for example.
:#* That will be fixed soon.
:# EnvClean.bat has an error in line 172: ser -> set.
:#* Fixed in build 204.
:# Note that ansi escape sequences aren't necessarily supported on a real dos environment/emulation.
:#* Good point I will move that to DosBox only.
:# FreeDOS breaks horribly on the setup files, but I think that's due to bugs on their end.
:#* I dont know what can be done about that.
:# Thanks for continuing work on XComUtil.
:#* Your welcome. I should have started on this sooner.
:# Btw, what's wrong with DosBox 0.73? It sure didn't stop XcomUtil 9.6.. [[User:Cesium|Cesium]] 09:45, 18 January 2010 (EST)
:#* 0.73 had two changes. 1. the shell closes the batch file after each line and remembers where it was then reads the file again starting at the next line. (this was to alow for menus that modify themselves. 2. They made shift move %1 to %0. I'm sure you can see what that does. I do a special shift test to detect 0.73. While the basic setup would work none of the command line options would. This was fixed in there current nightly build 2 months back so it will be working in 0.74.
:#** Grrr. They did this for "self modifying menus" (which don't need this performance killing stupidity) but ignored my patch...
::I have verified the new setup works if 4DOS is used under DosBox 0.73 (with some small changes outlined above. 4Dos had to be started with "4DOS /E:16384"). Now to test the game.. [[User:Cesium|Cesium]] 15:00, 18 January 2010 (EST)
::* Well, the Dart gun seems to be still useless. The change gave me an auto shot which takes 3xTU than snap shot but with same percentage...
::** This the same as the UFO pistol update. all it's doing is making 3 snap shots with no chance for reaction fire. --[[User:BladeFireLight|BladeFireLight]] 20:53, 18 January 2010 (EST)
::* Small wish: Have the option to make the Gauss Tank require only Gauss Cannon research - this can make it more distinct than the Sonic Displacer and maybe slightly useful for a while...
::** I plan on it. just not this version. --[[User:BladeFireLight|BladeFireLight]] 20:53, 18 January 2010 (EST)

:* One other think I noticed (with 200 but that's probably with 204 too), is that if xcusetup is run again after a successful setup, than it restores from backup, then backups the restored files again... Not sure if this is needed. Maybe there's a scenario where it is? [[User:Cesium|Cesium]] 17:32, 18 January 2010 (EST)
::* Yes it does. on DosBox this can be painfully slow to :( The reason for this is Hybrid games or map packs being added sense the last backup. When I have the new BFG and make a C++ version of the XcomUtTE.jar that 9.6 XcuSetup had, this will be of more important. perhaps I will make a command line option to skip backup so you dont have to run it. --[[User:BladeFireLight|BladeFireLight]] 20:53, 18 January 2010 (EST)

: I've noticed a bug (with 200, but since no in-game changes are mentioned in the changelog, I'm guessing its unchanged): XcomUtil is set to restore previous equipment. I'm packing a few Sonic Pulsars for the first time (I think?), and XcomUtil packs a few Pulsars into one spot in the backpack.. Savegame: [http://www.ufopaedia.org/images/3/34/Bugged_save.zip] [[User:Cesium|Cesium]] 23:32, 18 January 2010 (EST)
:: This behavior has been around since that option was added. see "Automatic Re-Equipment of Troops:" on line 1025 of XcomUtil.txt. I have not modified that section of code. It will be addressed eventually --[[User:BladeFireLight|BladeFireLight]] 23:39, 18 January 2010 (EST)

===Build 221===

:* Playing further, I noticed that If all the aliens are down (some of them stunned), the last save is named "AutoCombat" and I end turn, XcomUtil may still run "AutoCombat" phase. This may have slightly different results than end of combat would have had. (Also, the score is low in AutoCombat use since all agents are regarded as KIA, but you probably already knew that). [[User:Cesium|Cesium]] 22:57, 20 January 2010 (EST)

:: Autocombat should only run on Abort, and only if: slot ten is named "autocombat" AND it's date,time and combat round match the one just aborted. By "all agents KIA" are you saying they all were killed by auto combat? --[[User:BladeFireLight|BladeFireLight]] 12:14, 21 January 2010 (EST)

::* This is not the case. Set up XcomUtil so that it leaves messages after battle. Then get [http://www.ufopaedia.org/images/c/c3/Buggy_autocombat1.zip]. Load the game and press "End Turn" - AutoCombat will run when it shouldn't... As for all agents KIA I mean score-wise - I do get them back, but in score display I get points deducted as if they are all dead. Same for civilians at terror sites. I'm using build 200, as there's nothing in the changelogs that suggests changes to XcomUtil's behaviour in-game and I already got it installed.. [Edit: tested with 219 too - still fails] [Edit2: this turns out not to be entirely accurate: agents not in exit locations would be lost after running AutoCombat. Edit date: [[User:Cesium|Cesium]] 19:44, 30 January 2010 (EST)]
::: AutoCombat should only run then tactical exits with abort mission. if it's runing on end turn then tactical is crashing. Can you send me your debug.txt? --[[User:BladeFireLight|BladeFireLight]] 14:06, 21 January 2010 (EST)
:::: Well, there's a link to a buggy savegame above so you can verify it yourself (I'm using TFTD v2.1 DOS under DosBox 0.73 right now). I've erased debug.txt and loaded the savegame again - nothing is written to debug.txt. Also, X-COM is behaving fine (mission successful end, etc.) when this is run without XcomUtil. I suspect Tactical is just exiting normally and for some reason XcomUtil just decided to run AutoCombat. [[User:Cesium|Cesium]] 14:18, 21 January 2010 (EST)
::::: The debug.txt is created by XcuSetup. it tells me what options you chose and what happend when it tried to apply them. This would give me a baseline to replicate your setup. With 0.73 you cant run "XcuSetup lastop skip" to re-create what it did the last time you ran it Can you either send me the lastop.bat or if you run XcuSetup again with the same options and send me the debug.txt. Then I can get the same configuration your having issues with. (I need to add a CRC check to the before and after conditions of the EXE's to the debug so I can tell if they have changing consistently.) --[[User:BladeFireLight|BladeFireLight]] 15:44, 21 January 2010 (EST)
:::::: I can run "Xcusetup lastop skip" under DosBox 0.73 if I use a different batch interpreter like 4DOS... Here it is: [[Image:Debug.zip]] [[User:Cesium|Cesium]] 16:12, 21 January 2010 (EST).
::::::: That is good to know. The setup should not give an error in that case, if it passes the shift then it could care less. I would think that with a diferent interprater, %COMSPEC% would be somthing other then Z:\COMMAND.COM. am I correct about that?
:::::::: Well, in this case COMSPEC isn't changed and than it works fine. If COMSPEC is changed to point to 4DOS, than:
::::::::# "Processing" is displayed as the "Operating System".
::::::::# setup fails on the "Path to Xcopy" check.
::::::::: I tried to use the 4DOS batch file debugger to see exactly where it fails, but it's too unwieldy for this. (Note that 4DOS needs to be started using /E:16384 or something similar, since default environment size is too small). [[User:Cesium|Cesium]] 02:29, 23 January 2010 (EST)
:::::::::: It should fail on an Unknown OS. If you have a sure fire way to detect 4DOS i would be happy to add it. I would treat it the same as dosbox.
::::::::::: It's funny that a DOS program won't work on a real DOS but only on dosbox... It would be a lot easier to make the OS checks not abort, than to try and detect everything... Anyway, you can test for 4DOS like this: 'if NOT "%_4VER%". == "". (then 4DOS)'.
:::::::::: As for the environment size I'm not surprised it's to small. I use it extensively so I check for a lot of it. I dont know how the larger command.com footprint will effect available memory on a bare mettle dos install. --[[User:BladeFireLight|BladeFireLight]] 23:05, 23 January 2010 (EST)
::::::::::: Well, Environment requirement can be reduced, but this is likely to reduce legibility of setup batch. I doubt it's worth it. Even ancient DOS systems had 640KB.. [[User:Cesium|Cesium]] 00:05, 24 January 2010 (EST)
::::::: I will look at the debug and the saved game this weekend or monday. I have to finish migrating all my code to another compiler. XcomUtil was written with Borland 2.0 in mind. I had to use 5.5 for the 32 but but it's giving me fits. So I'm trying to move all the code over to Open Watcom this weekend. It will be nice having debugger to use. --[[User:BladeFireLight|BladeFireLight]] 01:22, 23 January 2010 (EST)
::::::: Took a look at why the autocombat would run when not intended. If you have the same date/time in the autocombat as the current save and press end turn with with all aliens dead it will trigger autocombat. to avoid this rename the save in slot 10 if your playing the same battle again. --[[User:BladeFireLight|BladeFireLight]] 17:40, 30 January 2010 (EST)
:::::::* OK, so it can run if end turn rather than abort is used (that's not a problem to get around). However, there's a bug: Even though tactical has concluded the aliens are no longer a threat, XcomUtil can still run an AutoCombat against a few "zombie" aliens (I think the uploaded save has this? If not, I probably have an archived save exhibiting this)... X-Com would win, but it might be possible to lose valuable research help from accidentally killing said aliens. I suspect that's due to some stun calculations failing somehow and concluding some stunned aliens can still fight. [[User:Cesium|Cesium]] 19:40, 30 January 2010 (EST)

::* P.S. Can I get research help from captive at first stage of 2-stage missions? And Has XcomUtil's behaviour for 2/3-stage TFTD missions been improved? Well, I'm doing an Artifact site now, so I'll find out soon anyway... 9.6 used to be real buggy in T'Leth third stage transition (and I have a save game for that too) and IIRC didn't let me get captives from first stage. Never played research help till now though... [[User:Cesium|Cesium]] 13:41, 21 January 2010 (EST)
::: I have only made one change to XcomUtil.exe that that was to remove the MIA recovery. I expect the clip recovery issue will still be their between stages. This is a major frustration to me and I will address it once the installer is stable. --[[User:BladeFireLight|BladeFireLight]] 14:06, 21 January 2010 (EST)
:::: I managed to overwrite my own game saves, but eventually I did quite a few two part missions. I notice that sometimes XcomUtil can emit "Divide error" when calculating research help. This seems to happen usually (but not exclusively) when calculating the second part of a two-part... The attached savegame ([[Image:Autocombat_research_bug.zip]] - unzip than save slot 10 at "AutoCombat" and abort) has this behaviour. [[User:Cesium|Cesium]] 08:44, 25 January 2010 (EST)
::::: I played around with that game and didn't get a "divide error" with vanila 0.72 but it did lockup on me doing the research calculations aborting the second stage if I autocombated the first. I also had tactical skip the equip screen and crash. This will require some more research. --[[User:BladeFireLight|BladeFireLight]] 18:03, 30 January 2010 (EST)

===Build 305===

:: I haven't played with this yet, but running setup I noticed the following:
:* I get this warning when running XcuSetup under 4DOS: "restore.bat [485] Duplicate redirection ">>debug.txt"". It's harmless though.
::: This will be fixed in the next build. --[[User:BladeFireLight|BladeFireLight]] 15:14, 7 February 2010 (EST)
:* Redirecting the "attrib -R /S" line to nul would be nice (it outputs a lot under 4DOS, FreeDos and maybe other interpreters).
::: Ditto --[[User:BladeFireLight|BladeFireLight]] 15:14, 7 February 2010 (EST)
:* Install on unknown OS doesn't seem to work - it gives "Unable to continue!" right after asking "Shell We Continue?" (without waiting for input). I've tested this on DosBox 0.73 where COMSPEC has been changed..
::: Same here. DosBox a number of things missing in the command interprater I relyed on detecting the comspec var to know it's dosbox becaus of the lack of a native find. and if I use a | it only runs the first part. I am re-writing the detection to now use the included 16bit find.com on all but x64 systems to check the ver statement. --[[User:BladeFireLight|BladeFireLight]] 15:14, 7 February 2010 (EST)
:* Why is the sound directory backed up? Perhaps you intend to add an "UFO 1.2 sounds for 1.4" or "Playstation mp3s for UFO CE" options in the future? It seems useless for TFTD though.. [[User:Cesium|Cesium]] 03:12, 7 February 2010 (EST)
::: Yes I intend to include the sound fixes eventualy. While TFTD would not be needed Its more of a pain to skip then to backup. The Geograph folder that is Slooooow. I may limit it to just files I may replace.
:* One more thing: I've tried running "command /E:512" with dosbox 0.73 and then running xcusetup. Instead of exiting with an environment space error, the setup breaks in a very odd way (dosbox is stuck and has to be terminated [edit: sometimes this requires running xcusetup more than once to trigger]). Also, the real requirement seems to be more than 980 bytes (unless the check is intentionally pessimistic?). [[User:Cesium|Cesium]] 03:29, 7 February 2010 (EST)
::: the DOSBox team is addressing this in 0.74. It was my complaints of crashing that led to us working on fixing the environment buffer overflow issue. I had to shrink my environment usage to the official size (1088) and they fixed the overflow. --[[User:BladeFireLight|BladeFireLight]] 15:14, 7 February 2010 (EST)
:: Btw, you might be interested in [http://forums.somethingawful.com/showthread.php?threadid=3220122]. The thread uses XcomUtil (9.6) multiplayer quite heavily and they probably have bug reports... [[User:Cesium|Cesium]] 03:15, 7 February 2010 (EST)

===Build 317===

:* Unknown OS now works: I've successfully ran xcusetup under FreeDOS in dosemu.
:* DosBox 0.73 doesn't work though.. It gets stuck right after asking whether to apply the bugfixes.
:* I wonder why the research fix for TFTD isn't enabled by default? I guess it will be once testing is done? [[User:Cesium|Cesium]] 12:25, 8 February 2010 (EST)
:: Minor problem with XCUSETUP of build 317. Note the missing "what" transports can carry.

-= XcomUtil 9.7 Beta (Build 317) setup =-
:: Fighters / Transport ::
Change the Interceptor and Firestorm to carry 's
[NOTE: modifies Tactical and adds additional map, route and terrain
files.]
Do you want to enable Interceptor and Firestorm as Fighter Transports? (N)

::This is my first install of the new XCU and I am VERY impressed. Nice job! [[User:Spike|Spike]] 19:23, 11 February 2010 (EST)

::: Thanks This will be fixed. --[[User:BladeFireLight|BladeFireLight]] 21:21, 11 February 2010 (EST)
:* A fully loaded Hammerhead's initial deployment has three aquanauts outside the craft. This doesn't happen when XcomUtil isn't started (i.e. via TERROR.COM). [[User:Cesium|Cesium]] 01:54, 12 February 2010 (EST)
::: Can you give me a save that is that far along. I dont have one handy. --[[User:BladeFireLight|BladeFireLight]] 02:10, 12 February 2010 (EST)
:::: Sure. [[Image:Hammerhead_bug_saves.zip]]. [[User:Cesium|Cesium]] 02:34, 12 February 2010 (EST)
:::: [[Image:Hbug2.zip]]. Maybe that would be more convenient for you. [[User:Cesium|Cesium]] 04:32, 12 February 2010 (EST)

:* I've managed to accidentally make a truncated geoscape/obdata.dat file using xcusetup. I uninstalled it, then ran "xcusetup nobackup" (it still made a backup), and chose "n" to everything besides the prompted bug fixed and improved gauss weapons. I'll try to reproduce this.
::: "uninstall" removes the backup's. "nobackup" only works if it finds backup files.
:* I've also noticed "improved gauss weapons" doesn't change the Heavy Gauss clip power in the entry in ufopedia (should be 80 instead of 75). [[User:Cesium|Cesium]] 03:03, 12 February 2010 (EST)
::: Works for me on Win7 and DOSBox 0.72. --[[User:BladeFireLight|BladeFireLight]] 15:11, 12 February 2010 (EST)
:::: I'm talking about the clip page, not the weapon page. TFTD displays the power on both the gauss weapon and gauss ammo pages. [[User:Cesium|Cesium]] 16:36, 12 February 2010 (EST)
::::: This must be with remove clip turned on. with just a power increase the damage is not displayed on the weapon. I need to look into disabling clip research as part of removing the clip requirement. for now I can add the damage levels to the clips when removing the need for them. --[[User:BladeFireLight|BladeFireLight]] 16:43, 12 February 2010 (EST)
:::::: Per description in xcusetup, Heavy Gauss is upgraded from 75 to 80 power even when "Improved Gauss Weapons" change is on, but "Remove Clip" change is off (i.e. gauss weapons still need clips), so the Heavy Gauss Clip page needs to be updated regardless of "Remove Clip" setting in xcusetup (unless you manage to disable clips altogether when its turned on). [[User:Cesium|Cesium]] 16:58, 12 February 2010 (EST)
::::::: UFOPedia pulls the information from obdata.dat. 4DOS has a number of issues that cascade though out XcuSetup I'm tracking them back. I will have to do some regression testing with 4DOS tonight. Seems redirection of STDERR varies from one DOS to another. --[[User:BladeFireLight|BladeFireLight]] 18:38, 12 February 2010 (EST)
:::::::: Ah, yes. "Real" DOS has no stderr redirection support at all. 4DOS has ">&>" extension, but NT cmd.exe uses "2>". I saw these errors, but thought they were harmless... [[User:Cesium|Cesium]] 19:20, 12 February 2010 (EST)

:Weirdness. I'm using Aliens Help Research and I win a Laser technology every day with 50 Scientists. One day I doubled up and got Laser Rifle and Heavy Laser on the same day (a known, non-XCU bug). Got Laser Cannon in 2 days. Is this supposed to happen with the human tech when you opt for Aliens Help Research? The Alien tech becomes impossible without them. Also I am getting Battlescape crashes, or rather it just skips the Battlescape altogether and replays the results of the previous battle. It also seems to lose the equipment in the transport, revert it to what was in the transport on the previous battle. I'm using the BFG and the Seb76 loader equipment management, that could be part of the problem. [[User:Spike|Spike]] 22:00, 12 February 2010 (EST)

:: OK I see what's going on. It is prompting me for terrain, but offering not terrain options but light level options. Then after I select a light level, it prompts me for light level, but does not wait for input and goes straight to battlescape, which fails.

0 = Jungle
1 = Farm
2 = Forest
3 = Human Base
4 = Alien Base
5 = Urban
6 = Desert
7 = Mountain
8 = Polar
9 = Mars

''[here I enter "5"]''
Select terrain:
0 = Darkness
1 = Twilight
2 = Daylight

''[here I enter "2"]''
Select light:

:: Basically it seems to be reading my input one step before I am prompted for it, and possibly giving the wrong input for the wrong question. It also is getting stuck in a loop of the BFG prompt. So probably it's a simple logic glitch in the batch file. I will update to the latest build and see if can replicate it. If I can, I will attach the game save file and config files. [[User:Spike|Spike]] 08:32, 13 February 2010 (EST)

::: I noticed this to. This is the underlying code.
<pre> printf( "\nSelect terrain: " );

if ( ESCAPE == ( i = getch() ) )</pre>
::: The prompt displayed before waiting for a key press. This may be an issue with Open Watcom. --[[User:BladeFireLight|BladeFireLight]] 18:39, 13 February 2010 (EST)

===Build 333===

:* One can make a truncated geodata/obdata.dat file in builds 317/333. I've run xcusetup, selected nothing but the fixes and improved gauss weapons, and pressed enter for everything else (4DOS/DosBox 0.73). The truncated file prevents the game from starting. [[User:Cesium|Cesium]] 03:23, 12 February 2010 (EST)
:: I think this may be a 4DOS issue. jpsoft.com does not look to support it any more. What version are you on on where do I get a copy? --[[User:BladeFireLight|BladeFireLight]] 15:08, 12 February 2010 (EST)
::: I've tried now with both last official version (7.50) and last open source version (8.00). Same issue with both. You just get a copy of either from [http://www.4dos.info/v4dos.htm] [[User:Cesium|Cesium]] 16:52, 12 February 2010 (EST)

===Build 340===

-= XcomUtil 9.7 Beta (Build 340) setup =-

::Creating Backup Files::

Geoscape Backup ................... OK
Tactical Backup ................... None
Maps Directory Backup ............. Processing.

16-bit MS-DOS Subsystem
Windows Command Processor - xcusetup
NTVDM has encountered a System Error
The handle is invalid.
Choose Close to terminate the application.

version is

Microsoft Windows [Version 6.1.7100]
Win7

last debug.txt message is

ResConfig=None
1 file(s) copied.
GeoBak=OK
Copying C:\games\xcom-all\MAPS\AVENGER.MAP
1 file(s) copied

xcsetup goes into a loop, the close option does not stop xcusetup but just loops

[[User:Spike|Spike]] 15:41, 13 February 2010 (EST)

:Lovely. I think I know what is going but I dont have a win7 32bit to test on. Do you have a Google Talk account? I would like to test something.
: on a side note. that is not actually a loop. it's copying groups of files at a time to avoid the timeout issue on dosbox. --[[User:BladeFireLight|BladeFireLight]] 16:40, 13 February 2010 (EST)

===Build 361===
*There's no Italian text for the New Laser Weapons option. Applying the patch seems to work, but it displays the text for the default laser weapons. Unfortunately, I don't know enough Italian to translate it myself.
:: Neither do I --[[User:BladeFireLight|BladeFireLight]] 21:51, 17 February 2010 (EST)
*There are two places in SysCheck.bat which use "%NO%" (lines 46, 164). I don't see that set anywhere. I think you meant something like "%clErr%NO%clOff%"? It's also possible to remove "set NO=" line from EnvClean.bat.
:: Thanks I will fix that --[[User:BladeFireLight|BladeFireLight]] 21:51, 17 February 2010 (EST)
*Apply.bat has two overt redirections to stderr (lines 830, 831). Since you're doing the stderr redirection support check several times, you may want to centralize it in Xcusetup.bat and than use something like %output%.
:: This is why you used to have to do "/E:16384" and why DosBox crashed so often. I have to keep under 950 bytes of environment usage.
::: I still have to do "/E:1024" etc. since 4Dos default environment size is 512 bytes. I think it's possible to save a bit more though by using a trick: instead of using %OLDPATH%, save the value of %PATH% to a batch file ("echo set PATH=%PATH >>" etc.) and then run said file after running EnvClean.bat at the end. There's more savings in this approach than just %OLDPATH%, since there are environment variables which tend to exist in DosBox before running xcusetup and can be cleared: %COMSPEC% (unused after DosBox test), %BLASTER% (iff sb emulation is on), %ULTRASND% and %ULTRADIR% (iff gus emulation is on). These can be unset at batch file start to save space and later restored by the temporary batch file. [[User:Cesium|Cesium]] 20:24, 18 February 2010 (EST)
::::All true DOS's only have 512 by default. I had thought about doing something similar with the default.bat and lastop.bat. using a series of of jumps to read it parts and then creating flag files for each setting. This would eliminate the need for most of the environment vars, but it also means another week for the overhaul. --[[User:BladeFireLight|BladeFireLight]] 21:07, 18 February 2010 (EST)
*Xcomutil.txt line 569: Telling the user to reboot isn't the best advice for multitasking OSs... Best to limit that advice to DOS. [[User:Cesium|Cesium]] 21:03, 17 February 2010 (EST)
::: Made sense when it was written. :) --[[User:BladeFireLight|BladeFireLight]] 21:51, 17 February 2010 (EST)

* I'm looking at the autocombat issue you mentioned above. AutoCombat is designed to kill every alien, no mater if they are unconscious. This has obvious issues with Alien Research. --[[User:BladeFireLight|BladeFireLight]] 22:42, 17 February 2010 (EST)

===Build 384===
* Hooray! This build is much better. I did find some stuff on initial check though:
* The number of aliens in the mission report is inconsistent with the number of live aliens captured per research help. See [[Image:Alien_numbers_mismatch.zip]] and [[Image:Dead_alien_count.zip]].
* You can get X-COM MIA if you abort a mission, even if everyone is in the exit. Possibly a second stage bug only? See [[Image:X-COM_MIA.zip]]. Note that this only affects the report - after mission all the X-COM troops are still available.
:* This happens even on vanilla TFTD with that save. Given it's TFTD it could be an issue with the mapfiles. --[[User:BladeFireLight|BladeFireLight]] 00:23, 24 February 2010 (EST)
* Morale is random at start of second stage after autocombat of first stage?
:* Actually Morale is used as the clip size and time units as the weapon damage. Don't ask me why. It would take a major re-write of auto combat to fix this. --[[User:BladeFireLight|BladeFireLight]] 19:34, 23 February 2010 (EST)
* All Civilians are dead if AutoCombat is used to end a Terror mission. It's too not much of a problem, since score is likely to be positive anyway. It would possibly be an improvement to assume all civs from first stage are dead (if ran at second stage) and get a random number (using mission seed) for dead civs at current stage? [[User:Cesium|Cesium]] 07:00, 22 February 2010 (EST)
:* This is odd. Autocombat is supposed to skip over civilians when using the kill function. --[[User:BladeFireLight|BladeFireLight]] 00:18, 24 February 2010 (EST)
::Maybe kill civilians (or not) according to the force ratios. If XCom has only enough force to win the mission, all Civilians are dead. If XCom bring a certain amount of "excessive force", all or nearly all Civilians are saved. By the way I love AutoCombat, it is great for avoiding repetitive combat and only playing the new, interesting bits. [[User:Spike|Spike]] 15:53, 22 February 2010 (EST)

::: Thinking about this, I recalled the scenario where someone fights the mission and uses AutoCombat to hunt the last aliens (another reason AutoCombat is great). Spike's suggestion is better from pure RNG, since in this case probably all civs that were at risk already died. So lets see what we suggest XcomUtil do:

:::* Count civs from first stage if there was one as dead (since IIRC XcomUtil has no memory of first stage when exiting second stage, so we can't take them into account?).
:::* Deduct dead civs from current stage.
:::* Calculate extra dead civs using force ratio to bias the RNG (I prefer merely biasing the RNG rather than precluding results, since Xcom in general has a large variance in almost every gameplay mechanic). [[User:Cesium|Cesium]] 18:27, 22 February 2010 (EST)

* "if %xOS%. == DosBox. if %xOS%. == 4DOS. if %xOS%. == Unknown. dir *.xcf" - this is not an OR statement. This line will simply never be executed. You can use a goto to emulate if/else and to test the condition only once, e.g.:

if NOT %xOS%. == DosBox. if NOT %xOS%. == 4DOS. if NOT %xOS%. == Unknown. goto win
dir ...
goto next
win:
dir /b ...
next:
[[User:Cesium|Cesium]] 07:42, 22 February 2010 (EST)

==Open Bugs==
*Various second stage bugs - ammo clip recovery, crashes after autocombat of first stage, etc. Mainly for TFTD, but possibly Cydonia in UFO is also affected.
*RPL bug, when you turn creatures into Gill Men, they are reported as Snakemen
:: Reported how? Is this consistent? The name's used are from xcomutil.cfg. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
:::Sorry. It's reported in morale failure pop up messages. Though maybe this is an original TFTD bug rather than an XComUtil bug. [[User:Spike|Spike]] 19:21, 21 February 2010 (EST)
::: See this: [http://www.youtube.com/watch?v=uGlSghf7aTU]. In that case, all Gill man (were lobster man before RPL) were reported as snakemen.. [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST)
*RPL bug, when you turn Lobstermen into other creatures (e.g. Gill Men), they are very hard to kill despite having the stats of the creature they turned in to. Possibly they are keeping their damage resistance? Maybe the race is stored in more than one place, for different purposes, and XComUtil misses one of these places?
:: I will look into this --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: The RPL only changes the basics; The race, rank, name, TimeUnits, Health, Energy, Reactions, Armor(front,back,left,right), Strenght and PSI Strenght. All other stats are left as-is. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
:::: I'm not so sure about this. See 05:00 mark at [http://www.youtube.com/watch?v=y-_zLdjhUHI]. The armour doesn't match the one Gill man should have (per UFOpaedia, at least). [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST). See also 04:17 mark at [http://www.youtube.com/watch?v=z5LfzFSkRnI] for reason to suspect resistances aren't always changed. It's possible he just was unlucky though... [[User:Cesium|Cesium]] 19:53, 21 February 2010 (EST)
::::: Actually the function is something like this
<pre>#define UpdateStat(x,y) pur->x = (unsigned char) \
( ( (unsigned int)pur->x \
* (unsigned int)pasTo->y \
) / (unsigned int)pasFrom->y )
UpdateStat( TimeUnits0, TimeUnits );
UpdateStat( Health0, Health );
UpdateStat( Energy0, Energy );
UpdateStat( Reactions0, Reactions );
UpdateStat( AFront0, AFront2 );
UpdateStat( ALeft0, ALeft2 );
UpdateStat( ARight0, ARight2 );
UpdateStat( ARear0, ARear2 );
UpdateStat( AUnder0, AUnder2 );
UpdateStat( Strength, Strength );
UpdateStat( PsiStrength, PsiStrength );
</pre>
::::: the 0's are values at start of tactical.
::::: I read that as Current(from game_x) * Target default(from xcomutil.cfg) / source default (from Xcomutil.cfg) so the stats will be different. --[[User:BladeFireLight|BladeFireLight]] 21:33, 21 February 2010 (EST)
:::::: I'd have expected Current(game_x) == Source default if applied on first turn? This would end up with result == Target default, no? Hmmm... We already saw some compiler multiplication wackiness with the research help bug. Possibly this affected these calculations too?
:::::: As for the code, you're not updating PsiSkill, so non Psi-users can't get Psi after RPL. [[User:Cesium|Cesium]] 22:03, 21 February 2010 (EST)
::::::: I didn't write this. I'm amusing Scott did it this way to adjust for difficulty because XcomUtil.cfg has the beginner level stats. It need's an overhaul to use the full stat entries including the unknowns adjusted correctly for the level. Something for latter. --[[User:BladeFireLight|BladeFireLight]] 22:09, 21 February 2010 (EST)
:::::::: For this specific issue I think you will need to update 0x37 of [[UNITREF.DAT]] which is the Damage Modifier. In addition to the Psi Strength. Also Firing Accuracy, energy regen rate, movement class... loads of stuff. And of course LOFTEMPS. So with current RPL not changing LOFTEMPS, changed aliens are the wrong size and shape probably. This would be visible using the LOFTEMPS map viewer I suppose. [[User:Spike|Spike]] 18:39, 9 March 2010 (EST)
*[[Known Bugs#XComUtil Inventory Stacking Bug]]
:: I hope to overcome this but Scott's notes point to a technical limitation. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*Removal of Small Scout map / Survey Ship map, making it impossible to do these Battlescape missions.
:: 9.7 only removes the maps if you use the BFG. This will be addressed eventually. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*Was it really intended to '''not''' have nerfed the [[Manufacturing_Profitability#XComUtil_manufacturing_profitability|Profitability]] of the Fusion Ball Launcher along with everything else? More generally, the profit nerfing could be revised to be more orderly and more systematic.
:: I dont really know what Scott intended as for the profiteering off of the changed items. If you want to suggest alternative values I'm open to discussion. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: A preliminary suggestion would be to make the Fusion Ball Launcher similarly difficult to manufacture as the Plasma Beam, so about ten times harder vs the unmodified game. E.g. Workshop space 6 -> 60, 400 -> 4000 Engineer hours. And perhaps require 4 Elerium and 20 Alloys, placing it midway between Laser Cannon and Plasma Beams. These changes (even without the materials) make the FBL unprofitable, like the (modified) Plasma Beam. I'm sure part of Scott's intent was to prevent "Laser Cannon Factories", but "FBL Factories" are 75% as profitable.
::: General reform of the profitability of manufacturing would require a lot of thought. Suffice to say I don't think '''any''' thought went into this for the original game. In reforming the economics of XCom, a basic problem is that realism is at odds with game balance. Realistically, governments would pay handsomely for almost anything XCom can produce. What would be reasonable is to get a moderate rate of return, rising more or less linear with investment (research effort), for ''all'' items. For game balance, this could be tweaked down for items that are useful in the game, or have research predecessors / successors that are useful in the game. A simpler case is to say that no item has negative profit, you can at least get 'cost price' back for it. Aircraft should arguably be in this category (since they would sell for 100s of millions which would be totally unbalancing). A rationalisation for nerfing any prices is that the money received by XCom is not the whole sale amount, but just a small commission paid by the Council of Funding Nations, which actually controls the sales and takes (in exchange for its funding) most of the profits. [[User:Spike|Spike]] 19:40, 8 February 2010 (EST)
:::: FBLs are already pretty useless, and you want to nerf these further? I'd rather think of a way to make them more useful in-game, otherwise the profit should be kept (Note how it's the mostly useless craft weapons which are profitable - I suspect there was some thought into this..). In comparison, the Laser Cannon profit does get nerfed with XcomUtil, but we get a useful weapon instead. I'd suggest a modified FBL will have a very high elerium requirement, and the power of the weapon should be raised a bit to compensate. [[User:Cesium|Cesium]] 20:04, 8 February 2010 (EST)
::::: For example: Raise power to 240, and add another charge (almost enough to sink a battleship if a craft has two FBLs loaded), but make it cost 100 elerium to make launcher. Raise hours for Balls by factor of 10. [[User:Cesium|Cesium]] 20:16, 8 February 2010 (EST)
::: Actually you're right, it makes more sense to make FBLs viable, instead of (just) nerfing the profits. Obviously high Elerium requirements will make them non-profitable. But of the 2 problems - making things useful and preventing 'factory farming' - I think making things useful is more important. I didn't realise FBLs were not tactically useful. I've never built them, only Plasma Beams. 3 ammo is reasonable, it means that 2 FBL armed aircraft have a good chance to take down a Battleship, if they can fire 9-10 out of 12 fusion balls before they are both killed. But 100 Elerium is way too much for an improved FBL that's only slightly more powerful. I think my suggestion (4 Elerium, 20 Alloys, 10x hours, 10x space) fits with the requirements of other XComUtil-modified weapons. Combined with your suggestion of 3 ammo and 240 damage, I think it would make FBLs ''useful'' again, which is one of the original goals of XComUtil.
::: Of course, it's ''possible'' that Scott was cleverly making FBLs useful, by making them so much cheaper (net) to manufacture than Plasma Beams. In an XComUtil modified game, you might well deploy FBLs first, and only work your way up to Plasma Beams later, because of the huge manufacturing costs of Plasma Beams. But personally I think it was an oversight. [[User:Spike|Spike]] 17:21, 9 February 2010 (EST)
:::: I've never played with XcomUtil modified lasers, so if you say this fits in better that's fine with me. It's unfortunate it involves increasing space: inventory management is one of the things I hate about the first two X-Coms. I was hired to be a commander, not a supply clerk! A mod which made general stores have 10000 space (like Apoc) would be nice.. [[User:Cesium|Cesium]] 21:39, 9 February 2010 (EST)
:::: Actually the energy weapon mod means they uses more ''workshop'' space to build but not more inventory space to store.
::::However "An army marches on its stomach ", Napoleon said, by which he meant that wars are won or lost on logistics. Other famous commanders have said similar things. So a general should pay attention to logistics. One of the great things about XCOM is it's not just a tactical game, it's a combined political - strategic - operational - tactical game. [[User:Spike|Spike]] 04:37, 14 February 2010 (EST)
*Zrbite lying around in odd places. Objects lying around in odd places in general - these are map modifying errors, probably only occur when customising terrain etc.
:: Will be part of an overhaul of the BFG --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*Also the '''xcsetup.bat''' prompt for the option of less-profitable weapons manufacturing is misleadingly called "new laser weapons". This should be much more clear eg "Much more difficult to manufacture advanced weapons [except FBLs]" or similar.
:: This seems to be a common complaint. I will look into better wording. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: Actually it might be an idea to break this up into sub-options. It does a lot of things! The "new laser weapons" option requires the use of extra alien materials in order to manufacture almost all energy beam weapons (not just lasers). It also makes the human manufacture of the alien plasma beam small arms impossible (research success merely allows X-COM to use captured weapons). The manufacture of craft Plasma Beams is still possible, but is made significantly more difficult (ten times the labour and workspace requirement as well as additional materials). As Scott says this "seriously changes the economics of the game". It also significantly alters the balance of firepower in the air and (to a lesser extent) on the ground. [[User:Spike|Spike]] 19:40, 8 February 2010 (EST)
*There is a small problem in editing/customising craft using '''XComUtil.cfg'''. Certain X-Com craft weapon values - the rate of fire value - can't be set. Or more specifically, they can be set (patched) in the executable but it has no effect in the game. To avoid confusion they should perhaps be removed from the format of custom craft, or commented out. (This rate of fire patching ''might'' work on UFOs, haven't tested it).
:: Can you be more specific? --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: There is a section in '''xcomutil.cfg''' which is used for patching XCom craft weapon characteristics. This is where Scott changed values for the Laser Cannon, etc. Probably very few people use these fields. I only used them because I was doing research into the game mechanics. One of the values changed in this section is the reload time. These values are present in the executable, and can be patched, but patching them has no effect (other than to change the UFOPaedia entry). The reload time seems to be hard coded elsewhere in the executable, based (broadly) on the class of weapon. So you might want to comment this column with an a note saying "cannot be modified for combat". On the other hand I could be wrong, or someone still might want to modify these fields. Discussion is at [[Talk:UFO_Interception#Observed_Rates_of_Fire]]. Offsets are at [[Talk:GEOSCAPE.EXE#Craft_weapon_stats]]. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
:::: Or maybe change these display-only values so that they reflect the [[Talk:UFO_Interception#Observed_Rates_of_Fire|observed reload rates]]? I am not yet 100% sure I have got these right, might want to wait until I do some more confirmation tests. [[User:Spike|Spike]] 15:26, 22 February 2010 (EST)
*EQL only works on turn 1 (see discussion above)
::: Added to my to do list. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)

*Remove 3rd burst for Pistol - it's already good enough, as NKF has shown
::: do you have a link to NKF's comments? --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:::: Having trouble finding his comments, maybe he'll show up here! See [[Rifle_vs_Pistol]], also [[Talk:Squad_Composition_and_Tactics#Starting_Sniper_Weapon]]. If anything there is a case for the Pistol to be nerfed slightly (eg Damage=20, Ammo=8), or for the Rifle to be buffed. Also worth looking through [[Weapon Analysis]] for general thoughts on weapon power and balance. The weapon set in EU is actually remarkably well balanced already.
::::: Further to this - not a bug but it's really wrong for a projectile weapon, a firearm, to have the same accuracy on Auto as on Snap fire (60). Even plasma weapons have Auto accuracy somewhat lower than Snap. If you reduce the Pistol burst mode accuracy by anything less than 2/3rds, the burst function is still useful, but more balanced. Actually even with a reduction of ''greater'' than 2/3rds, it would be useful, because of the increased damage at point blank range. Which is perhaps realistic for a burst-mode pistol. 60 Accuracy is higher than any Auto weapon in the game, for what ought to be the least accurate auto weapon. The best auto firearm is the Rifle at 35. Anything over 20 is still a bonus for the Pistol. How about 25? This still gives burst mode a 25% edge over Snap mode at long ranges, and a big improvement at close/point blank. 30 would make it more accurate than a Laser Pistol is on Auto (28), which is hard to justify. Admittedly the Pistol burst mode uses 3x (?) the TUs, so maybe some latitude can be given. Maybe go to 30 Accuracy, then, but no higher. [[User:Spike|Spike]] 19:49, 11 February 2010 (EST)
:::::: An interesting idea. Scott felt that this was just to make the pistol useful by allowing three snaps to be treated as one action so you dont deal with Reaction fire. The end results is the massive time units and same accuracy. If I lowered the accuracy I would have to lower the time to. I believe there is a reason the pistol doesn't have full auto in the vanilla game. You have seen a military issue full auto pistol? --[[User:BladeFireLight|BladeFireLight]] 21:15, 11 February 2010 (EST)
: Indent reset! I can't remember what my comments were either, but it's probably has to do with the weapon anaylsis and how useful snap shots already are. 'tis a jolly good weapon. I agree that you can't just make the auto mode identical to three snaps - you've got the added bonus of uninterrupted fire for the first two shots. You need to pay this off either with reduced accuracy or increase the usage cost.
: For consideration, I was actually fiddling with the weapons a few months back and was testing a 10% accuracy burst mode at 15% TU costs. I think 10 or 15 AP damage. Turned out way-way too powerful a weapon (against soft enemies) - and this was on a rookie I just picked randomly. It was probably too fast, but it still worked fairly well at 10% accuracy. 60% accuracy does feel quite high. -[[User:NKF|NKF]] 00:14, 12 February 2010 (EST)
:: Exactly. The point is that a 3-rd burst makes the Pistol more useful, ''even if the per-shot accuracy is lower'', because you get 3 attempts to kill the target before it Reaction Fires, rather than just one. As long as the ''net'' 3-rd accuracy isn't less than a single Snap shot, the weapon has been improved. The break-even point is about 26% accuracy on auto. At this level, 3 rounds have a ~60% chance of getting ''at least one'' hit. Even if the 3-rd accuracy was lower than a single Snap shot, you would still get the advantage of multiple hits at very close range. I would strongly suggest no more than 25% accuracy for Pistol auto burst, at the same level of TUs (3x Snap right?). This will definitely still be a significant improvement for the Pistol. Probably what was not fully understood at the time Scott did the original mod, is that the Pistol is arguably ''already'' the most effective starting weapon, certainly against the initial opponents. [[User:Spike|Spike]] 13:19, 12 February 2010 (EST)

* Fusion weapons inconsistently exempted from the "more difficult" energy weapons manufacturing option ("alternate laser Tech"). Blaster Bombs and Blaster Launchers, Fusion hovertanks and ammo, and Fusion Balls and Fusion Ball Launchers - none of these are harder to build or use with the "alternate Tech" option. Why make laser weapons/tanks and plasma weapons/tanks harder but not Fusion weapons? It's not consistent. I wonder if Scott didn't look at these because he never used Blaster Launchers or Fusion Hovertanks, as he considered them to unbalancing already? And ignored FBLs because, well, most people ignore them? But this should be consistent. Or, the "harder weapons" option could be broken down into sub options, e.g. for each weapon technology:
** Much more expensive (typically: add some exotic materials, 10x workshop space and 10x Engineer hours)
** Can/can't manufacture the battlescape weapons/tanks (pure alien weapons only)
** Can/can't manufacture the ammo (pure alien weapons only)
:Personally I would prefer it to be all-or-nothing but include the Fusion weapons as being more difficult to make and use. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)

* SteamSetup.bat won't run from DOSBox. It says "This needs to be run from Windows". Though, does it make any sense to run SteamSetup.bat under DOSBox (eg for a linux system with no Steam)? [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)

* It's actually quite hard to downgrade to DOSBox 0.72 in Ubuntu. Only 0.73 is offered, there is no ability to Force back to a lower package level with Synaptic Package Manager. Unix guru skilz are required to rollback to 0.72, and I guess 0.74 is not around yet, or not packaged for Ubunut APT? Is there any way to fudge around this, e.g. by providing the command line arguments in an optional text file for xcusetup.bat to parse? Having said that, even with no command line arguments, xcusetup hangs on my 0.73 DOSBox while executing SDUMP. I had to reboot in Windows to run xcusetup.bat - something that is only possible on a dual boot machine / Wubi machine. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
** Try using a different batch interpreter like 4DOS [http://www.4dos.info] to execute xcusetup inside DosBox. I tested this throughly before under DosBox/Linux and it works well with recent 9.7 builds. I suggest running "config -set cpu core=dynamic" and "config -set cpu cycles=max" before xcusetup to speed it up (xcusetup doesn't detect DosBox when 4Dos is run, so it doesn't run these automatically unlike normal DosBox case). [[User:Cesium|Cesium]] 09:48, 7 March 2010 (EST)
** Oh, and downgrading isn't that difficult: Get a dosbox 0.72 deb, and run "dpkg -i" on it, and then do "echo dosbox hold | dpkg --set-selections" to prevent future upgrades. [[User:Cesium|Cesium]] 09:50, 7 March 2010 (EST)
** Another option is to install the dosemu package, and run xcusetup under that. EU/TFTD can be run under that, but it doesn't work as well there. (Oh, and there's no mount command there. UFO/TFTD needs to exist under ~/.dosemu/drive_c which is C:) [[User:Cesium|Cesium]] 11:42, 7 March 2010 (EST)

:Thanks Cesium I will check this out. I still think it would be good to have a solution that works for people who are not knowledgeable with the unix command line though. [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)

:: Why use Linux if you dont know how to use the console? It is a text mode OS with a separate GUI. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)

::: Well Ubuntu is a bit different, as it's supposed to be an OS for the general public, where you never need to touch text mode! Incidentally I can't find any DEB or other packages for 0.72, all that is available on the DOSBox website is the source code. They really don't seem to realise that 0.73 is buggy! So I guess I will need to '''make''' it. Or just wait for 0.74 as I think it's out soon. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)

:::: See [http://archive.ubuntu.com/ubuntu/pool/universe/d/dosbox/] for 0.72 debs. Unlike Windows, package systems in Unix land are centralized, so best location to search is typically a package server mirror or a distro mirror, not a vendor's website. [[User:Cesium|Cesium]] 17:36, 9 March 2010 (EST)

* '''cfg/ShipDefU.txt''' has the XCU values for improved Laser Cannon (35/35/35), not the original values (21/35/70). Is this correct - is this file supposed to be the original defaults? [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)
:: I was unawhare that this had been changed. The weapons are not prompted for any change so they should not be changed. I'm reseting them all to defaults and looking to see if Scott had anything about them in the notes. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)

=== AutoCombat issues ===
* Day vs Night
** The Day/night algorithm breaks. For example, at any point when XCom has twice more flare-carrying soldiers than there are aliens, XCom is actually ''stronger'' in darkness than it would be in full daylight. Toward the end of a battle this is a very common situation. But fixing the algorithm is tricky. What might work is to give -10 for each Soldier in darkness, reduce from -20 to -10 for each Alien in darkness, then add back +10 for every soldier with a light source. Thus there is no way XCom can go 'net positive' from light sources.
:: If you have more units then they do you can see more of the battle field. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:::It never makes sense for XCom to be stronger at night, than during the day, for the same force ratio. But that is what happens. An example. 10 XCom soldiers with flares and 3 aliens. At night there is an extra -30 modifier for the aliens, but a +100 modifier for XCom, net +70. The same 10 soldiers against the same 3 aliens are +70 ''more'' effective in darkness than they would be in daylight. It does not make any sense. [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
** The definition of a light source should be expanded to include a Flare ''or'' an Incendiary weapon. In fact, one Incendiary-capable weapon of any type (AC/HC/HjC/GC), with appropriate Incendiary rounds carried, should be enough for the entire squad to be considered as having a light source. But this may be hard to implement without a special flag and a special pre-search for a valid Incendiary weapon, since AutoCombat normally scores by individual soldiers, not by whole squads.
:: This would take a rewrite. currently the ammo is not used by W: --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
** To be honest I would prefer that each soldier without a light source in darkness is 50% effective, each soldier with a light source (personal or squad), is 75% effective. Meanwhile how about this:

//Darkness
-10 L:-9 u:-2 // Human in Darkness

+10 L:-9 u:-2 W:-27 U:- // Human in Darkness w/Flare -OR-
+10 L:-9 u:-2 W:-4 W:-7 U:- // Human in Darkness w/In ammo and launcher HC/GC-IN -OR-
+10 L:-9 u:-2 W:-8 W:-11 U:- // Human in Darkness w/In ammo and launcher AC/HjC-IN -OR-
+10 L:-9 u:-2 W:-12 W:-15 U:- // Human in Darkness w/In ammo and launcher IN Rkt/Torp

-10 L:-9 u:4-14 // Alien in Darkness
:: Only thing I see is that this ''must'' come at the end. The U:- removes the unit from further consideration. --[[User:BladeFireLight|BladeFireLight]] 19:58, 9 March 2010 (EST)
::: Yes, to use the U: flag for this "OR" function, it must come at the end of the section for humans. That's how I have it my updated AutCombt.txt, these fragments are a bit out of context. It's not critical to have the "OR", it's just nice-to-have as it stops someone cheating by having a flare and one of each loaded incendiary launcher weapon in each hand and in their backpack, to get quadruple score. But hopefully people are unlikely to cheat at AutoCombat, there are easier ways such as the WIN flag. [[User:Spike|Spike]] 20:39, 9 March 2010 (EST)
* The Zombie is rated the same as a tank, a Chrysallid/Tentaculat or an effective Psi alien (-50). I think this is too high, as Zombies are much weaker than those units. A Zombie should be maybe -25.
: Disagree. the zombie should be slightly higher then a Chrysallid/Tentaculat as it will become one and you have to kill it twice. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:: OK good point! [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
* Area effect weapons (HE, IN, Small Launcher) should have at least the same bonus as effective-on-Auto weapons (+5). This is because they can damage/kill multiple targets. (The AC/HjC should not get both bonuses however.)

//Area Weapons. ToDo: compensating bonus for aliens. should not be cumulative. check if "effective?"
+5 u:-2 W:-4 W:-6 // Human w/HE ammo and launcher HC/GC-HE
+5 u:-2 W:-8 W:-10 // Human w/HE ammo and launcher AC/HjC-HE
+10 u:-2 W:-12 W:-13 // Human w/HE ammo and launcher Sm HE Rkt/Torp
+10 u:-2 W:-12 W:-13 // Human w/HE ammo and launcher Lg HE Rkt/Torp
+10 u:-2 W:-42 W:-43 // Human w/ Stun/Shok Launcher and ammo
+25 u:-2 W:-40 W:-41 // Human w/ Blaster/DP Launcher and ammo

-10 u:4-14 W:-42 W:-43 // Alien w/ Stun/Shok Launcher and ammo
-25 u:4-14 W:-40 W:-41 // Alien w/ Blaster/DP Launcher and ammo

::Having tested the first 2 rules, the first rule (HC-HE) does not work unless you remove the ammo specifier W:-6, making it just a test for an HC. But weirdly the second rule (AC-IN) works fine with its ammo specifier in place. Odd. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)

* Pistols with the burst mode option should not count as Auto weapons (maybe they don't).
: Burst and snap are based on default stats --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
* Blaster Launchers / DPLs (with ammo) should be worth as much as a tank, e.g. +/- 50 (including the single shot effective bonus it should already get - see suggested rule above under area weapons)
* Should distinguish between tanks. Even with improved armour, a Tank/Cannon is not the same as a Fusion Hovertank. I would suggest a range of 25 for a Tank/Cannon to 75 for a Hovertank/Fusion. Maybe 40 for a Tank/Rocket, 50 for Tank/Laser, 60 for a Hovertank/Plasma?
:This does not seem to be possible with the existing ruleset as all Tanks are unit type 3
::Hmm, byte 42 of [[UNITREF.DAT]] is Rank but also Tank chassis. So this ''might'' allow distinguishing tracked tanks from hover tanks, at least. An alternative approach would be to pick some stat (that has a StatStrings statid) and set it to a different unique value for each tank type. [[User:Spike|Spike]] 18:32, 9 March 2010 (EST)
* Flying units (either side) should be worth say +/- 5
:Not possible for XCom as no distinction between Power Suit and Flying Suit. Would be possible for aliens eg:

-5 T:0- u:6-6 // Flying Alien - Ethereal
-5 T:0- u:8-8 // Flying Alien - Floater

* If the squad is carrying some Smoke or Dye that should be worth maybe +5 - +10. But since the aliens don't ever carry that, you need some balancing factor for them.

+1 u:-2 W:-20 // +1 per human with smoke grenade(s) (hopefully not +1 per grenade!)

* Effective melee weapons should be counted. This is particularly important in TFTD when ranged weapons may be ineffective, e.g. vs Lobstermen.
* Similarly if the enemy are in heavy armour and therefore a soldier/alien does not have an effective weapon, any HE Pack / Alien Grenade / Sonic Pulser should be counted for something (if it is "effective").

//Melee weapons
+5 u:-2 W:1- W:-26 // Human w/o effective ranged weapon but w/ Stun Rod
+5 u:-2 W:3-26 // Human w/ effective Stun Rod (cumulative to above)

::The second rule doesn't work at all, it looks like it counts all items of types 3-6. The "superiority" function (first value before the hyphen) does not seem to operate, probably because it is a melee weapon. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
::: did you try W:255-26 ? not that I know if it would work. AutoCombat doesn't recognize stun rods as weapons when applying damage.--[[User:BladeFireLight|BladeFireLight]] 21:01, 9 March 2010 (EST)

//Grenades
+5 u:-2 W:1- W:-19 // Human w/o effective ranged weapon but w/ effective grenade(s)
+5 u:-2 W:1- W:-21 // Human w/o effective ranged weapon but w/ effective prox grenade(s)
+5 u:-2 W:1- W:-22 // Human w/o effective ranged weapon but w/ effective HE pack(s)
+5 u:-2 W:1- W:-44 // Human w/o effective ranged weapon but w/ effective Alien grenade(s)

-5 u:4-14 W:3-44 // -5 per Alien with effective Alien Grenade(s) (hope not -5 per grenade!)
:: Only one per unit. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)
::: Tested ok too! [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
* AutoCombat victories should award all UFO Components, not just some Navigation, Elerium and Alloys.
* Every Civilian on the map should be a penalty to XCom of maybe -5, due to the distraction effects of trying to save them / avoid killing them.

-5 u:15-16 U:- // Civilian distraction effect, no further effect

Let me know if I should try to work some of this up as AutoCombat rules. Some of it requires new coding of course, but a lot of it could probably be done with existing rules. [[User:Spike|Spike]] 13:15, 7 March 2010 (EST)
: I dont plan on any changing to the underlying code yet. Your welcome to make up a new set of rules and testing them out. --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
:: OK added some rules above. I have not tested them yet, some of the syntax might not work. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)
::: Syntax looks good to me. Give them a test and let me know how they go.
::: Just a quick note on how AutoCombat works. First the success percent chance is calculated using the AutoCombat StatStrings, dead and unconscious units dont count. (those that bleed to death are considers alive, need to fix this). If it's below AbortThreshold it aborts. If it's 100-199 then change to 90. 200+ change to 95 (success is never a guarantee.) Aliens roll d100, if over your success chance you lose. If You win. Then average damage by each side is calculated based on Loaded weapon being carried and time units. All aliens are killed or stunned by X-Com unit chosen at random. Each Alien gets a chance to wound an X-Com unit based on Success Percentage. Randomly choose unit using random damage (max is average alien damage) Leave at least one X-Com Unit alive. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)

==Fixed Bugs==
* standalone patches the fix the difficulty bug
::9.7 min install is the dificulty patch and changeing Copy protection questions to all 0's.
*Prompted Terrain displays the options but the prompt doesn't display until after a key press.
:: I guess Open Watcom's version of printf does not auto flush to the screen like Borland did.
*Version detection issues with obscure versions (Italian, 1.2a, etc.) causing corruption or lack of patching.
:: Cesium; XcomUtil doesn't have the offset for the copy protection for the Italian version coded. However the file you sent me is detecting as 1.3. none of the offsets will line up. The offsets Scott used to detect Italian are unique and may have been based on 1.0 or 1.2. Was that a clean unmodified copy? I need a clean one to validate all the offsets and update XcomUtil. --[[User:BladeFireLight|BladeFireLight]] 13:23, 16 February 2010 (EST)
:: I loaded it up and notice it does not ask for a language. this would imply it's based on X-Com 1.3 and not UFO 1.3. --[[User:BladeFireLight|BladeFireLight]] 13:33, 16 February 2010 (EST)
::: I didn't send you the installer since it's a mess (it requires some subst magic to work), but it looks authentic. Use the same link as before if you want to take a look at the installer. There's an Italian readme attached which points to some (now defunct) Italian sites. I didn't do any changes besides installing X-Com and then testing out XcomUtil. [[User:Cesium|Cesium]] 14:01, 16 February 2010 (EST)
:::: Italian UFO detection and offsets added, 1.2a offset's fixed.

*Various default options make the game easier, not harder (''harder'' being the intent of XComUtil, right?). These should not be defaults. (More discussion at [[Talk:Enemy_Unknown_Extended#Standard_Config_Discussions]]) E.g.
::: 9.7 only has 3 items on by default. Remove copy protection. Fix Difficulty bug and Split EXE (split EXE can be skiped but not the others). All other options are default to NO.
::: As for the intent of XcomUtil. Scott added features to
:::# Increase difficulty.
:::# Make useless items useful.
:::# Get the game Started faster.
::: I have added:
:::# Don't make unwanted changes.
:::# Fix game bugs
:::::Yes all of those are very sensible. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
::::Latter versions of XcomUtil will turn the last two forced items to prompted. with only the Difficulty bug and the split EXE as Default=Yes. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
**Basic tanks using advanced tank stats
**Improved High Explosive - very powerful in favour of X-Com, especially as alien spawn points and routes aren't set up to cover holes in UFO hulls.
**Gauss weapons have infinite ammo
::: 9.7 has a second option to just the increase power to closer match UFO.
**Using fighters as transports (carrying soldiers)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
**Using transports as fighters (weapon hardpoints)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
**Improved Heavy Laser / Heavy Gauss. OK, this should maybe be a ''recommended'' option since the unpatched weapons are nearly pointless. But, it does make the game easier.

[[User:Spike|Spike]] 20:12, 7 February 2010 (EST)

=XComUtil Wish List=
Things that are not bugs or inconsistencies in XComUtil but would be Nice To Have

== Features for 9.7 - Interface, consistency and bug fixes ==

=== Categorise Config Options ===

For each option, in the prompt, note which category of option this is, according your list above. E.g. faster start, making the game harder, making useless items useful, bug fix, variant game, etc. [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)

:Actually it might be even better to organise the options questions into sections, thematically grouped by these categories. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

:: Items are currently sorted like this.
* Windows EXE
* Game Fixes
* Game Mods
** Sound
** Craft
** Base
** Equipment
** Research
** Units
** Battlefield
** Alien Craft
** Misc
--[[User:BladeFireLight|BladeFireLight]] 19:25, 10 March 2010 (EST)

=== Improved Base Comes At Cost ===

The Improved Base is supposed to be a "faster start" option rather than a "make the game easier" option. But it does make the game easier, not least because it gives you a load of free base facility improvements. (Not to mention not having to struggle along the first month with only Small Radar and no Alien Containment) To partly avoid making the game easier, please add a sub-option that subtracts the cost of the extra facilities from your starting cash. This should be the ''full'' cost of the extra facilities, not just the difference between e.g. a Small Radar and a Large Radar.
[[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
: I dont have the offsets to the starting money ranges. so I cant do this. --[[User:BladeFireLight|BladeFireLight]] 19:13, 10 March 2010 (EST)

=== BFG Default To Unchanged ===

Is it possible when using the BattleFieldGenerator, for it to detect the actual conditions for the mission (terrain, enemy craft, and light level) and offer these as defaults? [[User:Spike|Spike]] 08:22, 13 February 2010 (EST)
:Press The esc key at the prompt. (Line 719 in Xcomutil.txt, not that I expect anyone to read the manual :) ) Enter should also work. --[[User:BladeFireLight|BladeFireLight]] 12:34, 13 February 2010 (EST)
:: RTFM eh? My biggest failing. Maybe you could add an explicit prompt "Esc or Enter = [whatever the unmodified value would be]". [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)
::: From what I can see, hitting Escape during BFG makes it continue with ''all'' values reverting to the original conditions. It would be nice to be able to select some but not all original conditions. My main use of this is to turn a night mission into a day mission without the hassle of keeping the landing craft hovering around until the terminator crosses the landing site. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
:::: You could just use the force all daylight option.
:::: After reviewing Scott's code. Esc leaves all setting as-is. Pressing enter or any other key not listed will randomly choose for you. I will see if I can change enter to leave as is. --[[User:BladeFireLight|BladeFireLight]] 11:00, 7 March 2010 (EST)

== Features for 9.8+ - New features ==

=== AutoCombat ===

==== Firepower Factors ====
You might want to consider replacing the weapon offensive weighting factors for Autocombat with some factors that are (inversely) related to the [[Weapon_Analysis#Quantitative_Analysis|% TUs Per Kill]]. I've tabulated these for each weapon (including tanks) vs each alien race. You would still need to account for Psi, light/darkness, and XCom armour. Plus you would need a similar offensive factor for the aliens' attacks. But I could probably help with that, I have the data that's directly comparable to the % TUs per Kill for XCom weapons. [[User:Spike|Spike]] 22:06, 12 February 2010 (EST)

==== AutoWithdrawal ====

One of the most tedious things you can try to do in XCom is to scavenge the battlefield and retreat to landing craft for an Abort. A great option would be an AutoWithdrawal, similar to an AutoCombat, but with an easier threshold of XCom vs Alien combat power.

Basically it would scavenge all loose equipment off the Battlescape - dropped friendly and alien items, friendly and alien corpses and wounded, all go back into the landing craft. Elerium, Alloys, and UFO Components would not be recovered, as this is (normally) impossible apart from full tactical victory. All friendly troops return to the landing craft. Friendly losses, and equipment recovered, would be proportional to the offensive factor ratios but much more favourable than for AutoCombat. E.g. as long as XCom factors were at least equal to Alien factors, they would be able to scavenge everything and recover without casualties. If the aliens were stronger than XCom, they would only recover part of the scavenged equipment, and risk partial casualties, at say one third the rate of AutoCombat. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

: It's too easy compared to actual game IMHO. Every time a battle went FUBAR for me, it got FUBAR all the way and I was lucky if I could salvage my own team/equipment and maybe a single alien weapon/body. An AutoWithdrawal without salvage might be useful, but perhaps instead we should change AutoCombat failure mode to work better (e.g. Make some X-COM people survive a failed AutoCombat, depending on strength vs aliens). [[User:Cesium|Cesium]] 15:00, 7 March 2010 (EST)

:: Yes fair point. I was not thinking of the FUBAR situations, and you are right about how hairy those are. I was thinking of the situation where you control a certain part of the battlefield, but you either don't want to go on an endless hunt for the last few aliens, or you pretty much know you can't take on the aliens that are left (e.g. in the UFO or some other stronghold) without getting creamed. You can exercise a safe withdrawal, it's just tedious to carry out all the bodies and equipment. But it's pretty hard for an AutoCombat algorithm to detect which of those situations it is - FUBAR, boredom, or tactical withdrawal. I'll have to think about that, there may be no realistic solution at all. And there is the existing "teleport loose items back to base" command line option to XComUtil, maybe that's enough. [[User:Spike|Spike]] 16:08, 7 March 2010 (EST)

=== Tougher UFOs ===

[[Wish_List_(EU)#Tougher_UFOs|Tougher UFOs]]
As this is entirely implemented by patching data and data files it is a good candidate for XComUtil rather than [[UFO Extender]].
: That would definitely make the game harder. 9.7 is about the installer and the bug fixes. This would be a good candidate for 9.8. --[[User:BladeFireLight|BladeFireLight]] 01:38, 19 February 2010 (EST)
:: Cool! [[User:Spike|Spike]] 02:25, 19 February 2010 (EST)

=== Rebalanced Craft Weapons ===

This fits under the "making useless things usefull" category. It would be a 9.8 or later option. The idea is to make the Cannon, Stingray, Laser Cannon and Fusion Ball Launcher useful. Hopefully it breaks up the monotony of Dual Avalanches followed by Dual Plasma Beams, every game.

There is one common element in the approach, and two options. The common element is to fix the stats on the Fusion Ball Launcher. The two options are to use a stat-based approach, or a cost-based approach, to fix the other weapons.

NB This proposal is still a draft and will need tweaking, but I've got it to the point where it is worth discussing. Feedback is welcome!

''(Ultimately, the Plasma Beam still ends up being pretty much the optimum weapon in the end game. To mitigate this, it is a good idea to select the existing Alternate Energy Weapons Manufacturing option in XComUtil.)''

==== Fusion Ball Launcher ====

Increase the ammo capacity from 2 to 3. Don't mess with the damage. Job done.

See [[User:Spike#Fusion_Ball_Launcher]] and discussions linked from there.

==== Cost Based Approach ====

This uses historically realistic costs to restore game balance between different craft weapons. The stand off advantage of Avalanche missiles is now purchased at a price which is significant in terms of XCom budgets and mission yields. Stingrays and Cannons become significantly cheaper alternatives. The Laser Cannon, with similar capabilities to Stingrays but free to operate, also becomes very attractive. Mounting dual launched weapons becomes a very expensive luxury.

*Increase Avalanche missile Purchase cost to $386,000
*Increase Stingray missile Purchase cost to $125,000
*Leave Sell prices unmodified (to avoid creating a cash reservoir at the start of the game)
*Leave Launcher buy/sell prices unmodified

See [[User:Spike#Cost_Based_Rebalancing]]

==== Stat Based Approach ====

This provides a benefit trade-off to shorter range weapons, by increasing their firepower or effectiveness relative to longer range weapons.

*Increase Cannon stats to 15 Damage, 50% hit. Firepower is tripled, slightly ahead of (unmodified) Avalanches launching in Aggressive mode. Increase rearming rate to 200.
*Increase Stingray accuracy to 80%. Decrease Avalanche accuracy to 60%. Stingray now has 50% more firepower relative to Avalanche. Increase Stingray rearming rate to 2, so a full craft can be re-armed in the same time period with either weapon (instead of twice as long for Stingray).
*Increase Laser Cannon stats to 100 Damage, 50% hit. Firepower is doubled, 20% more than (unmodified) Avalanches launching in Aggressive mode, 2/3rds of Plasma Beam firepower.

To avoid advanced XCom aircraft exploiting the extra firepower of the Cannon weapons and disregarding the return fire from UFOs, this is best used alongside the Tougher UFOs option.

See [[User:Spike#Stat_Based_Rebalancing]]

=== Rebalanced Infantry Weapons ===

See [[User:Spike#Balancing_Infantry_Weapons]]

Primarily this means making the Rifle a bit stronger, and probably making the Pistol a bit weaker.

==See Also==

[[Wish List]]

= Completed Wish List Items =

==Easier Inventory Management==
Inventory management is one of the things I hate about the first two X-Coms. I was hired to be a commander, not a supply clerk! A mod which made general stores have 10000 space (like Apoc) would be nice.. [[User:Cesium|Cesium]] 21:39, 9 February 2010 (EST)
: The manager of any facility has to deal with generalities of space issues. The clerk tells you if that fancy new tank you just bought will fit. He has to put it in storage and keep track of what shelf the ammo is on. --[[User:BladeFireLight|BladeFireLight]] 22:27, 9 February 2010 (EST)
:: That's the clerk's problem and if he complains too much I'll have him peel potatoes until his hands drop. In any event, the limit doesn't make any sense:
::* General stores size is 8x8x2 (8x8x3 in TFTD) per base defence map, and should have no problem storing more than 50 items.
::: The items taking up 1 item unit are typically about the size of humanoid body. I think it's not unreasonable to have no more than 50 of those in the area that the General Stores takes up.
:::: I can't find a list on the wiki of storage space requirements for items, so I'm not sure which items take up 1 item unit. Typically the main space wasters are Heavy Plasma ammo/Blaster Bombs/Stun Bombs (late game) and/or HWPs and avalanches (early game). These either are definitely not the size of a human body (ammo/Bombs), or shouldn't be stored in stores at all (HWPs gain nothing, and might as well lay around somewhere else in base).
::* The size of a fully built X-Com base is about the size of a city block (judging by comparison of base defence to terror missions), and should easily be able to hold hundreds of items even in the starting base if it's willing to put some stuff not in the general stores.
::* The space limit makes no sense. Why do Blaster Bombs and Heavy Plasma ammo take so much space whereas in the inventory view it doesn't take any more than normal ammo? Who stores <s>mini tanks</s> HWPs in the same compartment as light weapons? And the way X-Com (probably) stores ammo and explosives is scary...
::: As you suggest, extremely powerful ammunition probably requires a lot more space for safe and secure storage in-base, versus on a tactical mission. Imagine what would happen if a Blaster Bomb exploded in a base? Or was stolen? They probably use nuclear warhead style storage facilities for those. And similarly for Avalanche warheads, alien artifacts, Elerium, etc. Segregating dangerous/explosive items from other items probably uses up a lot of overhead in the construction of the storage space - think armoured, bomb-proof lockers and bulkheads, advanced security systems, airlocks, scanners, etc. This is not just like piling stuff up in your shed! And the Commander who left Elerium or Avalanche warheads lying around in his hanger or corridors would justifiably be sacked on the spot by XCom High Command. [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Well, judging by all the explosives in the hangar during base defence and the X-COM 1.0 Elerium bug, Elerium and explosive warheads ''are'' lying around in the base... And all the equipment in the General Stores is stored in ordinary lockers according to the General Stores map ;-) More to the point, if X-COM wants to store explosives safely (judging by said warheads X-COM doesn't care too much) they need a special facility for this, not to store them in the room which also contains all the base's weapons and priceless alien artifacts.

:::: Furthermore, I expect X-COM to improvise on storage in the interest of actually winning the war. X-COM does do this and ignore the limit when manufacturing stuff in-base or getting loot from missions. All that's needed is that X-COM will improvise for transfers too. I can't imagine a quartermaster informing the commander there isn't any room for the new armour and that the troops should go without. Maybe the reason X-COM doesn't pay quartermasters each month is that they keep getting themselves lynched by enraged X-COM troops...
::* Gameplay wise, inventory micromanagement is just no fun, especially in the late game when you have all the cash you need but still has to sell stuff after each combat (which can be prolonged if you haven't sold for awhile), otherwise you can't transfer items to the base where your main team is at.
::* Maybe this entire "stores" thing is a plot by the CFN to force X-Com to share its technology with them by forcing X-Com to sell sell sell. It's not like they pay X-Com the real worth of the technology anyway. [[User:Cesium|Cesium]] 23:47, 9 February 2010 (EST)
::: I think a lot of people do find the inventory management tedious, or unrealistically low. Personally I think it's about right for large equipment (missiles, tanks, bodies), but too low for small arms and personal equipment. And yes, it only reflects using the General Stores modules, not storing stuff at random points in the base - maybe fair enough. If the right offset to patch can be found, the storage limits could easily be raised. The last few bytes of [[BASE.DAT]] could be a good place to look for this offset. BASE.DAT can store up to 9,999 units of each item per base. The total limit for items per base would need to be found by experiment, but 9,999 might work for those who want to ignore inventory. For those who feel inventory management is OK but the limits set too tight, the capacity of each General Stores could be increased from 50 to 100 - assuming we can find the offset for this to patch it. [[User:Spike|Spike]] 19:50, 10 February 2010 (EST)
::::Maybe you can try there:
.text:00439C85 66 81 C5 F4 01 add bp, 500
::::[[User:Seb76|Seb76]] 13:03, 11 February 2010 (EST)
::::: Yes that works nicely. E.g. patch '''66 81 C5 E8 03''' at that location and you get 100 space per General Stores. Thanks Seb! [[User:Spike|Spike]] 18:21, 13 February 2010 (EST)
:::::: Now if only I had the offsets or search signature so we can add that as an options --[[User:BladeFireLight|BladeFireLight]] 18:24, 13 February 2010 (EST)
::::::: UFO 1.4 dos: offset 143748. TFTD 2.1 dos: offset 178462. TFTD v1 dos: offset 176861. TFTD CE: offset 252795. UFO CE: offset 236680. (all offsets are in decimal and point to the "F4 01" value to be patched).
::::::: Patching to "E8 03" has been tested on dos versions (not on CE) and it works. The "base information" screen will display the correct value, though the values to line length scale is such that the line will max at 250. [[User:Cesium|Cesium]] 05:57, 14 February 2010 (EST)
::::::::Are the preceding bytes the same from TFTD 1 and 2x? --[[User:BladeFireLight|BladeFireLight]] 17:26, 15 February 2010 (EST)
::::::::: Yes they are. '''81 C3 F4 01''' is the add instruction. [[User:Cesium|Cesium]] 17:48, 15 February 2010 (EST)
::::::::: Sig for UFO Dos is '''81 C6 F4 01''' --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
:::::::::: Do you also have the preceding bytes for UFO? with the signatures I can create a patch file for all versions --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
::::::::::: I am not sure I understand your question.. Judging the the two UFO versions I have available (1.3 per xcusetup and 1.4) the common preceding bytes are ''80 78 16 07 75 0C 80 78 3A 00 75 06'' (followed by the sig). You could try to use the sig alone - it exists only once in the file. [[User:Cesium|Cesium]] 19:35, 15 February 2010 (EST)
:::::::::::: Offset Locations are something I'm collecting but also the unique series of bytes to find them for the two geoscape/tactical that I dont have. (UFO Spanish, TFTD Italian) I hope to add a lot more options in the in the future. I do feel this one nerfs the storage system anything to get the game up and going faster is always a plus. --[[User:BladeFireLight|BladeFireLight]] 22:01, 15 February 2010 (EST)
::::::::::::: Well, you may want to add another General Stores to the improved starting base if you want to achieve the faster startup effect without "nerfing" storage system for rest of game (I prefer a "nerf" due to late-game reasons). Also, I suggest you add an message in Xcusetup to ask people to get in contact with you if they use an unknown/unrecognized version. [[User:Cesium|Cesium]] 14:27, 16 February 2010 (EST)
::: Inventory management is just as much a pain in the early game, where you almost always are out of space until your 2nd general stores is built. I like realistic constraints, but not tedium. Maybe upping the space per Stores from 50 units to 100 units would be a generally acceptable approach (now that Seb76 has kindly found the offset)? [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Yeah, that would be a great improvement. [[User:Cesium|Cesium]] 15:45, 13 February 2010 (EST)

:I can confirm Seb76 is correct, as ever. The 2 bytes at offsets '''0x39c88''' and '''0x39c89''' in geoscape.exe code for the capacity of each General Stores. Default value is 500 ('''F4 01''') which equates to 50 in-game internal capacity units. (Smallest item uses 0.1 in game capacity so I guess that is 1 unit in internal units). I am not sure about a signature. From what I can tell, the preceding bytes '''66 81 C5''' are unique in geoscape.exe, which seems pretty odd, so someone else should verify that. [[User:Spike|Spike]] 19:48, 13 February 2010 (EST)
:: Yes it is unique to CE. it does not exist in any DOS EXE, but "F4 01" can be found in 79 places. Trial and error could locate it. --[[User:BladeFireLight|BladeFireLight]] 20:50, 13 February 2010 (EST)

Talk:XcomUtil

2010-03-11T00:25:25Z

BladeFireLight: /* Categorise Config Options */

=XcomUtil 9.7 Beta=

9.7 Beta is available on www.bladefirelight.com

==Release Notes==
===Build 200===
This is a Beta, so backup your files before using. If you have issues pleas post them to XcomUFO.com in the XcomUtil forum.

New in this version.

*Major overhall of the installer (XcuSetup) and the inclusion of 16/32bit exe's to support both DOSBox and Windows Vista/7 x64.
*New subfolders added to hold supporting files making the install c leaner
*New XcuSetup options were added to XcuSetup allowing for silent install and uninstallation.
*New XcuSetup option for debugging the install (XcuSetup debug) creating debug.txt.
*XcuSetup now can have minimal impact on the game.
**All options default to NO.
**Almost all changes are now prompted for (skyranger guns, interceptor as transport, Disjointed Base Bug, etc...).
***Items still done by default:
***Copy protection questions set to 0000000 for UFO 1.0-1.3 and X-Com 1.0
***Difficulty bug fixed in UFO 1.0-1.4 and X-Com 1.0-1.4
***Unique names for all maps in TFTD, Used for Hybrid Games
*XCOMUTIL.CFG is now pieced together and overwritten by XcuSetup (see XcomUtil.txt for how to make permanent changes).
*All game files are restored to the pre-XcomUtil state each time XcuSetup is ran. Any modifications by other utilities will have to be re-applied.
*Recovery of MIA soldiers has been removed as it had a habit of resurrecting all KIA units to.
*Vista/Win7 patch now an option for XcuSetup.
**This will fix the blank screen issue.
**Updated to support the split EXE.
*XcuSetup attempts to fix UAC issues by resetting folder permissions.
*A number of community made fixes are included and selectable with XcuSetup.
*Support for the DOS/Window STEAM Install.
**Windows EXE, just run XcuSetup from windows
**to launch Dos version from Steam Run XcomUtil/SteamSetup.bat to activate menu then lauch from steam.
*Out of the box support for UFO Extender. XcuSetup will detect it and ask if you want RunXcom to use it.

NOTE: If you use DosBox, this requires DosBox 0.72 (Does not work on 0.73)

--[[User:BladeFireLight|BladeFireLight]] 18:28, 17 January 2010 (EST)

===Build 204===

* Fix the goto and "ser" issue
* Fixed the version display on the DosBox version detection is back on.
--[[User:BladeFireLight|BladeFireLight]] 16:15, 18 January 2010 (EST)

===Build 219===

ok. Just posted Build 219

*New command line argument "nobackup" skips backup only if it has been ran.
*Fix f0ders loader path and option goto so it actually works.
*Fix prompted terrain option to create correct flag file.
*f0ders loader now available to Vista and Win7 users. (I have no idea if this will be of help)
*replace "if exist" on folders with "if exist" on file.
*Allow 0.73 with no command line args (as this is all it brakes)
*%X-COM% to %XCOM% for older OS's
*Fixed the beta message display
*Fixed version display in deader
*Fixed misleading message in SFX install scrip.
--[[User:BladeFireLight|BladeFireLight]] 22:57, 18 January 2010 (EST)

===Build 221===

*Fix issue following issue with XcomUtil and STEAM.
**only creating backups of the Windows EXE
**only applying changes to the DOS EXE's

STEAM USERS need to run "Verify Integrity of game cache" before updating to this build.
--[[User:BladeFireLight|BladeFireLight]] 18:02, 20 January 2010 (EST)

===Build 305===

Some major restructuring of Environment Variables to fit within the limits of the forthcoming DosBox 0.74. Previous LastOp.bat files will no longer work. (should limit XcuSetup's Environment usage to about 980 bytes. Will no longer crash DosBox 0.73 by overrunning environment buffer)
Corrected a massive error that caused corruption on x64 systems.

I recommend you uninstall the previous version of XcomUtil before installing this one. (or delete LastOp.bat)

New items:

*Backup and restore of additional folders added.
*Allow install on Unknown OS with warning.
*Re-order some option questions and adjust wording.
*Correct File location that was causing Random ship generation to hang or crash.
*Fixed Vista/Win7 Patch to run on Vista. (Thanks Dangermouse)
*Environment Vars size shrunk. This invalidates previous lastop.bat (Thanks to Peter on the DosBox Team)
*Fix issues with using space in IF statement in dosbox and Dos 5.0
*Clean up environment test variable to free up space
*Backup and Restore: Fixes time out issues on DosBox. Adds progress display.
*Set Default to split EXE.
*Allow xcusetup for Dos games in x64 OS with warning
*Switched compiler to Open Watcom for ResFix and ResINfo
*New code to detect EXE version and adjust Max Research in ResFix and ResInfo
*Resfix will no longer execute on UFO
*Switched compiler to Open Watcom xcomutil xcomutrt and sdump.
*Fixed issues with 32bit structure packing leading to wide spread file corruption
*Fixed Alien Research Help math error
--[[User:BladeFireLight|BladeFireLight]] 18:28, 6 February 2010 (EST)

===Build 317===

Don't forget to re-run XcuSetup after you extract the files. For a almost quite install use "XcuSetup lastop skip"
If upgrading from pre-305 versions you need to uninstall with "XcuSetup uninstall" and run XcuSetup Fresh.

You can now use XcuSetup in Windows to configure a game you intend to play in DosBox OR run XcuSetup in DosBox and play from Windows. Even on x64 systems. XcuSetup can be slow in Dosbox this will allow for faster setup.

RunXcom now makes on-the-fly choices about x86 vs x64 XcomUtil EXE's and Steam Dos vs Windows. If you have Vista or Win7 x64 and a Steam copy you can switch between Dos/Windows Xcom by either runing from Steam or directly starting RunXcom.

A few caveats for STEAM users. Because of how XcomUtil detects the game, while XcuSetup will apply changes to both EXE's. Running XcomUtil from the command line will only effect the Dos version.

Complete List of changes.

*XcuSetup can be run from windows and RunXcom run from DosBox
*Renamed "New Laser" to Alternate Laser
*SortStats now back in XcomUtil.cfg
*Runxcom now uses x86 or x64 EXE's based on OS at time of execution
*Steam choice of Windows or DOS EXE now based on if RunXcom is started in DosBox.
*Xcomutil settings applied to both EXE's in Steam
*SteamSetup.bat displays message on success.
*Minor error fixes with 4DOS
*Better handling of unknown OS.
*New Steam Menu Options
** Run X-Com Sound Setup
** eXit to Windows
--[[User:BladeFireLight|BladeFireLight]] 03:21, 8 February 2010 (EST)

===Build 333===

Some Minor tweaks. Only major thing is I have given up on DOSBox 0.73 it's to buggy and crashes often. Although some of the bug fixes I worked out with the DOSBox dev team will not make it in until 0.75. They tell me most of them will be in 0.74 and it should not have this issue.

Luckily STEAM uses 0.72 and works as expected.

If you run another Command interpreter like 4DOS it should work.

*Random alien craft shape now works.
*Fixed Text color on BFG prompting on UFO under DOSBox.
*XCLoader.exe properly removed on uninstall and Gamefile restore
*Fixed display of Unit type on Fighter as transport prompt.
*Apply of Seb Loader from DosBox fixed.
*Commented RunXcom
*Removed Exit Point and replaced with Pauses in XcuSetup
*Updated DOSBox 0.73 error (to unstable. frequent buffer overflows setting ERRORLEVEL on program exit.)

-Blade FireLight

===Build 339===

This fixes the issue with 4DOS failing to do an initial backup, that lead to SDUMP being unable to apply patches, that led to empty designation files.
9.6 replaced the Hammer Head map by default. 9.7 does not but the unit placement was never updated. The 12 unit placement section has been added to fix units spawning outside the craft. (Scott's version of the Hammer Head is in the patches folder but requires manual modification of the config files to fully use. )

*Disable stderr redirection on 4DOS
*More debug and ArchFile now able to be run independently
*Add unit placement section for standard Hammerhead.
*Added Apply of Transport Hard Point.
*Fix Missing Terrain on TFTD Very Small

--[[User:BladeFireLight|BladeFireLight]] 21:14, 12 February 2010 (EST)

===Build 340===

*Fixed missing label causing exit in build 399.

--[[User:BladeFireLight|BladeFireLight]] 01:48, 13 February 2010 (EST)

===Build 348===

Fixed some obscure bugs.
Win7 32x on some computers would not run 16bit code(something to to with chip-set drivers and the 16bit xcopy), so now all NT based Windows will use 32bit EXE's.
Some STEAM users had issue with the windows EXE either being replace by or replacing the _patched.exe (f0ders loader) I saw this happen but was unable to repeat it. Hopefully the change of not using short file names when long ones can be will fix this issue.

*Fix BFG Prompting Display
*replace delete with del in RunXcom
*32bit EXE used on most versions of windows.
*Skip copy short file name if can find long file name.
--[[User:BladeFireLight|BladeFireLight]] 00:44, 14 February 2010 (EST)

===Build 350===

The EXE download now uses an updated script to prompt for steamsetup (if detected) and start xcusetup. This makes it more "consumer friendly".

*New SFX Installer Script.
*Cleaned up / updated xcomutil.txt and moved to xcomutil folder

--[[User:BladeFireLight|BladeFireLight]] 18:49, 14 February 2010 (EST)

===Build 361===

By popular demand the EQL now works on any turn.

*EQL allowed any turn.
*Fix Display of Forced patches for UFO Spanish/Italian
*Fix BFG questions to avoid invalid options.
*Add Xcom UFO Italian Support

--[[User:BladeFireLight|BladeFireLight]] 19:28, 17 February 2010 (EST)

===Build 384===

Lots of bug fixes. Hybrid now working, Fixed issues with auto combat and combining clips.

*Fix Hybrid Implementation
*Auto Combat will not run on second half of two part using first parts saved data.
*Auto Combat will no longer run if combat was won.
*MIA Recovery on won combat only
*Auto equip no longer triggers on second part of 2 stage missions.
*Add skip of combine clips if between stages of 2-3 part missions.
*Lost of debug info to in XcomUtil.log
*Add Headers to XcomUtil.log section brakes.
*XcomUtil's Apply action now in debug.txt
*Update and move f0dders read me per his request.
*Fixed typo stopping Lab PSI/MC Screen from working.
*Fix Infinite loop when not splitting EXE
*Fix nonexistent %no% variable
*Limit STDERR redirection to MS OS's

--[[User:BladeFireLight|BladeFireLight]] 02:44, 22 February 2010 (EST)

===Build 413===

Fixed Hybrid and Prompted BFG on Windows EXE's. Hybrid now uses Boom Blokes Pallet conversion. (removes lighting artifacts) "XcomUtil uninstall" now removes the hybrid game maps and terrain. Updated the Vista/Win7 patch. Recommend applying if you get odd colors that only go away with a reboot or playing a video in Media Player. Created new Add-on ability to allow others to plug-in to XcuSetup and RunXcom.

*Add-on support added. see XcomUtil\XcomUtil.txt and XcomUtil\Addon\Example.txt
*Restore and Backup ran second time on Hybrid games to resolve issues with cross pollination
*Update Vista/Win7 Patch to address alt + tab color issues. (restores color pallet on next start of Goescape or Tactical. Does not stop the corrupt pallet)
*Create windows flag file to force XcomUtil to update windows EXE when playing Xcom Windows
*Better UFO Hybrid integration and uninstall of copied files.
*Bomb Bloke's Hybrid Pallet Map
*command line option for config file now searches %CWD%\, %CWD%\XcomUtil\ and %CWD%\XcomUtil\Batch\
*Hybrid path detection change to look for \maps\ATLAN00.map OR %1\maps\URBAN00.map
*Move XcomUtRt and LastOp to sub-folders older LastOp moved if it exists.
*All Flags moved to the flags folder.
*If debug.txt exists zero out file (deletion caused problems with WinTail)
*uninstall a few missed files.
*Fix debug log of config flags.
*Fix echo------ error in RunXcom.bat

--[[User:BladeFireLight|BladeFireLight]] 17:40, 28 February 2010 (EST)

===Build 422===

*Fixed unit placing where units were placed outside of sub or inside of tanks.
*Fixed Display of Starting Transport and Fighter names for TFTD
*Updated addon example.txt to streamline and clarify a few things.
*Switched to Bomb Bloke updated Color Pallet
*Units who bleed to death no longer rise from the grave. (unless they die the same turn as you kill the last alien)
*Units under mind control when the last alien dies are no longer MIA.
*Fix messed up goto in Line 8 used for addons (Was causing exit of RunXcom)
*Fix RME error

--[[User:BladeFireLight|BladeFireLight]] 02:33, 2 March 2010 (EST)

==Beta Disscusion==
===Build 219===

: Well, I tried running it, and noticed a few errors in the batch setup system:
:#The existence of a directory can't be tested by using "if exist". It won't work on real DOS and many DOS emulations. The suggested workaround fails sometimes (see [http://support.microsoft.com/kb/65994] or [http://www.faqs.org/faqs/msdos-programmer-faq/part3/section-7.html]).
:#* I dont have access to every platform. Your help on this would be invaluable.
:#** It's been a long long time since I wrote batch scripts... First, I suggest creating the directories unconditionally (redirect output or clear screen if you're worried about error output). Second, either drop checking for game_1 directory existence afterwards or if you must check for it - write a dummy batchfile into the directory which only runs one command: a command which exits with a specific known errorlevel (probably sdump or other xcomutil binary would work). Then try to run said batch. Then you can test for said errorlevel - if it's there, than the directory exists. Then erase dummy batchfile.
:#*** My solution is similar. i'm using the dum.bin If it dosent exist create the directory with >>%redir% and copy in a dum.bin. should work on any OS.
:#Please don't test existence of correct running environment for X-COM in the setup file (e.g. don't prevent patching windows version while running in dosbox, or vice versa). Or at least don't abort the setup, but just print out a warning. This is patronizing - it's none of Xcomutil business, and people who downloaded this probably already know how to run software. Besides, this is likely to ruin at least some possible combinations. Maybe some future bug in dosbox/Windows will make people want to run the setup batch file under cmd.exe/dosbox? Or maybe some people may even want to run XCOM CE in [http://www.winehq.com Wine] for example, and the check keeps in the way? (Also there's a spelling error - "hoast" -> "host").
:#* I dont expect everyone who got the game for the first time from STEAM to know their way around the computer. If RunXcom uses 16bit EXE's setup in DosBox in Windows 7 x64 it will throw an error. I could integrate the system checks into RunXcom so It can select the right EXE's however for STEAM and similar setup with both EXE I would have to setup a menu in RunXcom to select what version to actually use if they have Steam on a 32 bit platform.
:#* I dont intend to support OS2 or Wine like Scott did. What OS's I can support will be based on what feedback I get and what I have the time/interest in fixing.
:#** Then can you add a parameter to let us override the checks without editing xcusetup? These checks are bound to fail for some OS/dosbox combination now or in the future...
:#*** It's not that simple. The values in the syscheck are required for making decisions. like is the OS x64, is the game UFO or TFTD. does the OS have UAC. will the OS accept SHIM's. Can I find the files needed to run the commands ... --[[User:BladeFireLight|BladeFireLight]] 20:53, 18 January 2010 (EST)
:#4DOS (v7.5 and v8) at least don't like X-COM environment variable name (it returns -COM when doing %X-Com%), and I suspect it may not work under MS-DOS's COMMAND.COM either. Try something like "%X_Com%" for example.
:#* That will be fixed soon.
:# EnvClean.bat has an error in line 172: ser -> set.
:#* Fixed in build 204.
:# Note that ansi escape sequences aren't necessarily supported on a real dos environment/emulation.
:#* Good point I will move that to DosBox only.
:# FreeDOS breaks horribly on the setup files, but I think that's due to bugs on their end.
:#* I dont know what can be done about that.
:# Thanks for continuing work on XComUtil.
:#* Your welcome. I should have started on this sooner.
:# Btw, what's wrong with DosBox 0.73? It sure didn't stop XcomUtil 9.6.. [[User:Cesium|Cesium]] 09:45, 18 January 2010 (EST)
:#* 0.73 had two changes. 1. the shell closes the batch file after each line and remembers where it was then reads the file again starting at the next line. (this was to alow for menus that modify themselves. 2. They made shift move %1 to %0. I'm sure you can see what that does. I do a special shift test to detect 0.73. While the basic setup would work none of the command line options would. This was fixed in there current nightly build 2 months back so it will be working in 0.74.
:#** Grrr. They did this for "self modifying menus" (which don't need this performance killing stupidity) but ignored my patch...
::I have verified the new setup works if 4DOS is used under DosBox 0.73 (with some small changes outlined above. 4Dos had to be started with "4DOS /E:16384"). Now to test the game.. [[User:Cesium|Cesium]] 15:00, 18 January 2010 (EST)
::* Well, the Dart gun seems to be still useless. The change gave me an auto shot which takes 3xTU than snap shot but with same percentage...
::** This the same as the UFO pistol update. all it's doing is making 3 snap shots with no chance for reaction fire. --[[User:BladeFireLight|BladeFireLight]] 20:53, 18 January 2010 (EST)
::* Small wish: Have the option to make the Gauss Tank require only Gauss Cannon research - this can make it more distinct than the Sonic Displacer and maybe slightly useful for a while...
::** I plan on it. just not this version. --[[User:BladeFireLight|BladeFireLight]] 20:53, 18 January 2010 (EST)

:* One other think I noticed (with 200 but that's probably with 204 too), is that if xcusetup is run again after a successful setup, than it restores from backup, then backups the restored files again... Not sure if this is needed. Maybe there's a scenario where it is? [[User:Cesium|Cesium]] 17:32, 18 January 2010 (EST)
::* Yes it does. on DosBox this can be painfully slow to :( The reason for this is Hybrid games or map packs being added sense the last backup. When I have the new BFG and make a C++ version of the XcomUtTE.jar that 9.6 XcuSetup had, this will be of more important. perhaps I will make a command line option to skip backup so you dont have to run it. --[[User:BladeFireLight|BladeFireLight]] 20:53, 18 January 2010 (EST)

: I've noticed a bug (with 200, but since no in-game changes are mentioned in the changelog, I'm guessing its unchanged): XcomUtil is set to restore previous equipment. I'm packing a few Sonic Pulsars for the first time (I think?), and XcomUtil packs a few Pulsars into one spot in the backpack.. Savegame: [http://www.ufopaedia.org/images/3/34/Bugged_save.zip] [[User:Cesium|Cesium]] 23:32, 18 January 2010 (EST)
:: This behavior has been around since that option was added. see "Automatic Re-Equipment of Troops:" on line 1025 of XcomUtil.txt. I have not modified that section of code. It will be addressed eventually --[[User:BladeFireLight|BladeFireLight]] 23:39, 18 January 2010 (EST)

===Build 221===

:* Playing further, I noticed that If all the aliens are down (some of them stunned), the last save is named "AutoCombat" and I end turn, XcomUtil may still run "AutoCombat" phase. This may have slightly different results than end of combat would have had. (Also, the score is low in AutoCombat use since all agents are regarded as KIA, but you probably already knew that). [[User:Cesium|Cesium]] 22:57, 20 January 2010 (EST)

:: Autocombat should only run on Abort, and only if: slot ten is named "autocombat" AND it's date,time and combat round match the one just aborted. By "all agents KIA" are you saying they all were killed by auto combat? --[[User:BladeFireLight|BladeFireLight]] 12:14, 21 January 2010 (EST)

::* This is not the case. Set up XcomUtil so that it leaves messages after battle. Then get [http://www.ufopaedia.org/images/c/c3/Buggy_autocombat1.zip]. Load the game and press "End Turn" - AutoCombat will run when it shouldn't... As for all agents KIA I mean score-wise - I do get them back, but in score display I get points deducted as if they are all dead. Same for civilians at terror sites. I'm using build 200, as there's nothing in the changelogs that suggests changes to XcomUtil's behaviour in-game and I already got it installed.. [Edit: tested with 219 too - still fails] [Edit2: this turns out not to be entirely accurate: agents not in exit locations would be lost after running AutoCombat. Edit date: [[User:Cesium|Cesium]] 19:44, 30 January 2010 (EST)]
::: AutoCombat should only run then tactical exits with abort mission. if it's runing on end turn then tactical is crashing. Can you send me your debug.txt? --[[User:BladeFireLight|BladeFireLight]] 14:06, 21 January 2010 (EST)
:::: Well, there's a link to a buggy savegame above so you can verify it yourself (I'm using TFTD v2.1 DOS under DosBox 0.73 right now). I've erased debug.txt and loaded the savegame again - nothing is written to debug.txt. Also, X-COM is behaving fine (mission successful end, etc.) when this is run without XcomUtil. I suspect Tactical is just exiting normally and for some reason XcomUtil just decided to run AutoCombat. [[User:Cesium|Cesium]] 14:18, 21 January 2010 (EST)
::::: The debug.txt is created by XcuSetup. it tells me what options you chose and what happend when it tried to apply them. This would give me a baseline to replicate your setup. With 0.73 you cant run "XcuSetup lastop skip" to re-create what it did the last time you ran it Can you either send me the lastop.bat or if you run XcuSetup again with the same options and send me the debug.txt. Then I can get the same configuration your having issues with. (I need to add a CRC check to the before and after conditions of the EXE's to the debug so I can tell if they have changing consistently.) --[[User:BladeFireLight|BladeFireLight]] 15:44, 21 January 2010 (EST)
:::::: I can run "Xcusetup lastop skip" under DosBox 0.73 if I use a different batch interpreter like 4DOS... Here it is: [[Image:Debug.zip]] [[User:Cesium|Cesium]] 16:12, 21 January 2010 (EST).
::::::: That is good to know. The setup should not give an error in that case, if it passes the shift then it could care less. I would think that with a diferent interprater, %COMSPEC% would be somthing other then Z:\COMMAND.COM. am I correct about that?
:::::::: Well, in this case COMSPEC isn't changed and than it works fine. If COMSPEC is changed to point to 4DOS, than:
::::::::# "Processing" is displayed as the "Operating System".
::::::::# setup fails on the "Path to Xcopy" check.
::::::::: I tried to use the 4DOS batch file debugger to see exactly where it fails, but it's too unwieldy for this. (Note that 4DOS needs to be started using /E:16384 or something similar, since default environment size is too small). [[User:Cesium|Cesium]] 02:29, 23 January 2010 (EST)
:::::::::: It should fail on an Unknown OS. If you have a sure fire way to detect 4DOS i would be happy to add it. I would treat it the same as dosbox.
::::::::::: It's funny that a DOS program won't work on a real DOS but only on dosbox... It would be a lot easier to make the OS checks not abort, than to try and detect everything... Anyway, you can test for 4DOS like this: 'if NOT "%_4VER%". == "". (then 4DOS)'.
:::::::::: As for the environment size I'm not surprised it's to small. I use it extensively so I check for a lot of it. I dont know how the larger command.com footprint will effect available memory on a bare mettle dos install. --[[User:BladeFireLight|BladeFireLight]] 23:05, 23 January 2010 (EST)
::::::::::: Well, Environment requirement can be reduced, but this is likely to reduce legibility of setup batch. I doubt it's worth it. Even ancient DOS systems had 640KB.. [[User:Cesium|Cesium]] 00:05, 24 January 2010 (EST)
::::::: I will look at the debug and the saved game this weekend or monday. I have to finish migrating all my code to another compiler. XcomUtil was written with Borland 2.0 in mind. I had to use 5.5 for the 32 but but it's giving me fits. So I'm trying to move all the code over to Open Watcom this weekend. It will be nice having debugger to use. --[[User:BladeFireLight|BladeFireLight]] 01:22, 23 January 2010 (EST)
::::::: Took a look at why the autocombat would run when not intended. If you have the same date/time in the autocombat as the current save and press end turn with with all aliens dead it will trigger autocombat. to avoid this rename the save in slot 10 if your playing the same battle again. --[[User:BladeFireLight|BladeFireLight]] 17:40, 30 January 2010 (EST)
:::::::* OK, so it can run if end turn rather than abort is used (that's not a problem to get around). However, there's a bug: Even though tactical has concluded the aliens are no longer a threat, XcomUtil can still run an AutoCombat against a few "zombie" aliens (I think the uploaded save has this? If not, I probably have an archived save exhibiting this)... X-Com would win, but it might be possible to lose valuable research help from accidentally killing said aliens. I suspect that's due to some stun calculations failing somehow and concluding some stunned aliens can still fight. [[User:Cesium|Cesium]] 19:40, 30 January 2010 (EST)

::* P.S. Can I get research help from captive at first stage of 2-stage missions? And Has XcomUtil's behaviour for 2/3-stage TFTD missions been improved? Well, I'm doing an Artifact site now, so I'll find out soon anyway... 9.6 used to be real buggy in T'Leth third stage transition (and I have a save game for that too) and IIRC didn't let me get captives from first stage. Never played research help till now though... [[User:Cesium|Cesium]] 13:41, 21 January 2010 (EST)
::: I have only made one change to XcomUtil.exe that that was to remove the MIA recovery. I expect the clip recovery issue will still be their between stages. This is a major frustration to me and I will address it once the installer is stable. --[[User:BladeFireLight|BladeFireLight]] 14:06, 21 January 2010 (EST)
:::: I managed to overwrite my own game saves, but eventually I did quite a few two part missions. I notice that sometimes XcomUtil can emit "Divide error" when calculating research help. This seems to happen usually (but not exclusively) when calculating the second part of a two-part... The attached savegame ([[Image:Autocombat_research_bug.zip]] - unzip than save slot 10 at "AutoCombat" and abort) has this behaviour. [[User:Cesium|Cesium]] 08:44, 25 January 2010 (EST)
::::: I played around with that game and didn't get a "divide error" with vanila 0.72 but it did lockup on me doing the research calculations aborting the second stage if I autocombated the first. I also had tactical skip the equip screen and crash. This will require some more research. --[[User:BladeFireLight|BladeFireLight]] 18:03, 30 January 2010 (EST)

===Build 305===

:: I haven't played with this yet, but running setup I noticed the following:
:* I get this warning when running XcuSetup under 4DOS: "restore.bat [485] Duplicate redirection ">>debug.txt"". It's harmless though.
::: This will be fixed in the next build. --[[User:BladeFireLight|BladeFireLight]] 15:14, 7 February 2010 (EST)
:* Redirecting the "attrib -R /S" line to nul would be nice (it outputs a lot under 4DOS, FreeDos and maybe other interpreters).
::: Ditto --[[User:BladeFireLight|BladeFireLight]] 15:14, 7 February 2010 (EST)
:* Install on unknown OS doesn't seem to work - it gives "Unable to continue!" right after asking "Shell We Continue?" (without waiting for input). I've tested this on DosBox 0.73 where COMSPEC has been changed..
::: Same here. DosBox a number of things missing in the command interprater I relyed on detecting the comspec var to know it's dosbox becaus of the lack of a native find. and if I use a | it only runs the first part. I am re-writing the detection to now use the included 16bit find.com on all but x64 systems to check the ver statement. --[[User:BladeFireLight|BladeFireLight]] 15:14, 7 February 2010 (EST)
:* Why is the sound directory backed up? Perhaps you intend to add an "UFO 1.2 sounds for 1.4" or "Playstation mp3s for UFO CE" options in the future? It seems useless for TFTD though.. [[User:Cesium|Cesium]] 03:12, 7 February 2010 (EST)
::: Yes I intend to include the sound fixes eventualy. While TFTD would not be needed Its more of a pain to skip then to backup. The Geograph folder that is Slooooow. I may limit it to just files I may replace.
:* One more thing: I've tried running "command /E:512" with dosbox 0.73 and then running xcusetup. Instead of exiting with an environment space error, the setup breaks in a very odd way (dosbox is stuck and has to be terminated [edit: sometimes this requires running xcusetup more than once to trigger]). Also, the real requirement seems to be more than 980 bytes (unless the check is intentionally pessimistic?). [[User:Cesium|Cesium]] 03:29, 7 February 2010 (EST)
::: the DOSBox team is addressing this in 0.74. It was my complaints of crashing that led to us working on fixing the environment buffer overflow issue. I had to shrink my environment usage to the official size (1088) and they fixed the overflow. --[[User:BladeFireLight|BladeFireLight]] 15:14, 7 February 2010 (EST)
:: Btw, you might be interested in [http://forums.somethingawful.com/showthread.php?threadid=3220122]. The thread uses XcomUtil (9.6) multiplayer quite heavily and they probably have bug reports... [[User:Cesium|Cesium]] 03:15, 7 February 2010 (EST)

===Build 317===

:* Unknown OS now works: I've successfully ran xcusetup under FreeDOS in dosemu.
:* DosBox 0.73 doesn't work though.. It gets stuck right after asking whether to apply the bugfixes.
:* I wonder why the research fix for TFTD isn't enabled by default? I guess it will be once testing is done? [[User:Cesium|Cesium]] 12:25, 8 February 2010 (EST)
:: Minor problem with XCUSETUP of build 317. Note the missing "what" transports can carry.

-= XcomUtil 9.7 Beta (Build 317) setup =-
:: Fighters / Transport ::
Change the Interceptor and Firestorm to carry 's
[NOTE: modifies Tactical and adds additional map, route and terrain
files.]
Do you want to enable Interceptor and Firestorm as Fighter Transports? (N)

::This is my first install of the new XCU and I am VERY impressed. Nice job! [[User:Spike|Spike]] 19:23, 11 February 2010 (EST)

::: Thanks This will be fixed. --[[User:BladeFireLight|BladeFireLight]] 21:21, 11 February 2010 (EST)
:* A fully loaded Hammerhead's initial deployment has three aquanauts outside the craft. This doesn't happen when XcomUtil isn't started (i.e. via TERROR.COM). [[User:Cesium|Cesium]] 01:54, 12 February 2010 (EST)
::: Can you give me a save that is that far along. I dont have one handy. --[[User:BladeFireLight|BladeFireLight]] 02:10, 12 February 2010 (EST)
:::: Sure. [[Image:Hammerhead_bug_saves.zip]]. [[User:Cesium|Cesium]] 02:34, 12 February 2010 (EST)
:::: [[Image:Hbug2.zip]]. Maybe that would be more convenient for you. [[User:Cesium|Cesium]] 04:32, 12 February 2010 (EST)

:* I've managed to accidentally make a truncated geoscape/obdata.dat file using xcusetup. I uninstalled it, then ran "xcusetup nobackup" (it still made a backup), and chose "n" to everything besides the prompted bug fixed and improved gauss weapons. I'll try to reproduce this.
::: "uninstall" removes the backup's. "nobackup" only works if it finds backup files.
:* I've also noticed "improved gauss weapons" doesn't change the Heavy Gauss clip power in the entry in ufopedia (should be 80 instead of 75). [[User:Cesium|Cesium]] 03:03, 12 February 2010 (EST)
::: Works for me on Win7 and DOSBox 0.72. --[[User:BladeFireLight|BladeFireLight]] 15:11, 12 February 2010 (EST)
:::: I'm talking about the clip page, not the weapon page. TFTD displays the power on both the gauss weapon and gauss ammo pages. [[User:Cesium|Cesium]] 16:36, 12 February 2010 (EST)
::::: This must be with remove clip turned on. with just a power increase the damage is not displayed on the weapon. I need to look into disabling clip research as part of removing the clip requirement. for now I can add the damage levels to the clips when removing the need for them. --[[User:BladeFireLight|BladeFireLight]] 16:43, 12 February 2010 (EST)
:::::: Per description in xcusetup, Heavy Gauss is upgraded from 75 to 80 power even when "Improved Gauss Weapons" change is on, but "Remove Clip" change is off (i.e. gauss weapons still need clips), so the Heavy Gauss Clip page needs to be updated regardless of "Remove Clip" setting in xcusetup (unless you manage to disable clips altogether when its turned on). [[User:Cesium|Cesium]] 16:58, 12 February 2010 (EST)
::::::: UFOPedia pulls the information from obdata.dat. 4DOS has a number of issues that cascade though out XcuSetup I'm tracking them back. I will have to do some regression testing with 4DOS tonight. Seems redirection of STDERR varies from one DOS to another. --[[User:BladeFireLight|BladeFireLight]] 18:38, 12 February 2010 (EST)
:::::::: Ah, yes. "Real" DOS has no stderr redirection support at all. 4DOS has ">&>" extension, but NT cmd.exe uses "2>". I saw these errors, but thought they were harmless... [[User:Cesium|Cesium]] 19:20, 12 February 2010 (EST)

:Weirdness. I'm using Aliens Help Research and I win a Laser technology every day with 50 Scientists. One day I doubled up and got Laser Rifle and Heavy Laser on the same day (a known, non-XCU bug). Got Laser Cannon in 2 days. Is this supposed to happen with the human tech when you opt for Aliens Help Research? The Alien tech becomes impossible without them. Also I am getting Battlescape crashes, or rather it just skips the Battlescape altogether and replays the results of the previous battle. It also seems to lose the equipment in the transport, revert it to what was in the transport on the previous battle. I'm using the BFG and the Seb76 loader equipment management, that could be part of the problem. [[User:Spike|Spike]] 22:00, 12 February 2010 (EST)

:: OK I see what's going on. It is prompting me for terrain, but offering not terrain options but light level options. Then after I select a light level, it prompts me for light level, but does not wait for input and goes straight to battlescape, which fails.

0 = Jungle
1 = Farm
2 = Forest
3 = Human Base
4 = Alien Base
5 = Urban
6 = Desert
7 = Mountain
8 = Polar
9 = Mars

''[here I enter "5"]''
Select terrain:
0 = Darkness
1 = Twilight
2 = Daylight

''[here I enter "2"]''
Select light:

:: Basically it seems to be reading my input one step before I am prompted for it, and possibly giving the wrong input for the wrong question. It also is getting stuck in a loop of the BFG prompt. So probably it's a simple logic glitch in the batch file. I will update to the latest build and see if can replicate it. If I can, I will attach the game save file and config files. [[User:Spike|Spike]] 08:32, 13 February 2010 (EST)

::: I noticed this to. This is the underlying code.
<pre> printf( "\nSelect terrain: " );

if ( ESCAPE == ( i = getch() ) )</pre>
::: The prompt displayed before waiting for a key press. This may be an issue with Open Watcom. --[[User:BladeFireLight|BladeFireLight]] 18:39, 13 February 2010 (EST)

===Build 333===

:* One can make a truncated geodata/obdata.dat file in builds 317/333. I've run xcusetup, selected nothing but the fixes and improved gauss weapons, and pressed enter for everything else (4DOS/DosBox 0.73). The truncated file prevents the game from starting. [[User:Cesium|Cesium]] 03:23, 12 February 2010 (EST)
:: I think this may be a 4DOS issue. jpsoft.com does not look to support it any more. What version are you on on where do I get a copy? --[[User:BladeFireLight|BladeFireLight]] 15:08, 12 February 2010 (EST)
::: I've tried now with both last official version (7.50) and last open source version (8.00). Same issue with both. You just get a copy of either from [http://www.4dos.info/v4dos.htm] [[User:Cesium|Cesium]] 16:52, 12 February 2010 (EST)

===Build 340===

-= XcomUtil 9.7 Beta (Build 340) setup =-

::Creating Backup Files::

Geoscape Backup ................... OK
Tactical Backup ................... None
Maps Directory Backup ............. Processing.

16-bit MS-DOS Subsystem
Windows Command Processor - xcusetup
NTVDM has encountered a System Error
The handle is invalid.
Choose Close to terminate the application.

version is

Microsoft Windows [Version 6.1.7100]
Win7

last debug.txt message is

ResConfig=None
1 file(s) copied.
GeoBak=OK
Copying C:\games\xcom-all\MAPS\AVENGER.MAP
1 file(s) copied

xcsetup goes into a loop, the close option does not stop xcusetup but just loops

[[User:Spike|Spike]] 15:41, 13 February 2010 (EST)

:Lovely. I think I know what is going but I dont have a win7 32bit to test on. Do you have a Google Talk account? I would like to test something.
: on a side note. that is not actually a loop. it's copying groups of files at a time to avoid the timeout issue on dosbox. --[[User:BladeFireLight|BladeFireLight]] 16:40, 13 February 2010 (EST)

===Build 361===
*There's no Italian text for the New Laser Weapons option. Applying the patch seems to work, but it displays the text for the default laser weapons. Unfortunately, I don't know enough Italian to translate it myself.
:: Neither do I --[[User:BladeFireLight|BladeFireLight]] 21:51, 17 February 2010 (EST)
*There are two places in SysCheck.bat which use "%NO%" (lines 46, 164). I don't see that set anywhere. I think you meant something like "%clErr%NO%clOff%"? It's also possible to remove "set NO=" line from EnvClean.bat.
:: Thanks I will fix that --[[User:BladeFireLight|BladeFireLight]] 21:51, 17 February 2010 (EST)
*Apply.bat has two overt redirections to stderr (lines 830, 831). Since you're doing the stderr redirection support check several times, you may want to centralize it in Xcusetup.bat and than use something like %output%.
:: This is why you used to have to do "/E:16384" and why DosBox crashed so often. I have to keep under 950 bytes of environment usage.
::: I still have to do "/E:1024" etc. since 4Dos default environment size is 512 bytes. I think it's possible to save a bit more though by using a trick: instead of using %OLDPATH%, save the value of %PATH% to a batch file ("echo set PATH=%PATH >>" etc.) and then run said file after running EnvClean.bat at the end. There's more savings in this approach than just %OLDPATH%, since there are environment variables which tend to exist in DosBox before running xcusetup and can be cleared: %COMSPEC% (unused after DosBox test), %BLASTER% (iff sb emulation is on), %ULTRASND% and %ULTRADIR% (iff gus emulation is on). These can be unset at batch file start to save space and later restored by the temporary batch file. [[User:Cesium|Cesium]] 20:24, 18 February 2010 (EST)
::::All true DOS's only have 512 by default. I had thought about doing something similar with the default.bat and lastop.bat. using a series of of jumps to read it parts and then creating flag files for each setting. This would eliminate the need for most of the environment vars, but it also means another week for the overhaul. --[[User:BladeFireLight|BladeFireLight]] 21:07, 18 February 2010 (EST)
*Xcomutil.txt line 569: Telling the user to reboot isn't the best advice for multitasking OSs... Best to limit that advice to DOS. [[User:Cesium|Cesium]] 21:03, 17 February 2010 (EST)
::: Made sense when it was written. :) --[[User:BladeFireLight|BladeFireLight]] 21:51, 17 February 2010 (EST)

* I'm looking at the autocombat issue you mentioned above. AutoCombat is designed to kill every alien, no mater if they are unconscious. This has obvious issues with Alien Research. --[[User:BladeFireLight|BladeFireLight]] 22:42, 17 February 2010 (EST)

===Build 384===
* Hooray! This build is much better. I did find some stuff on initial check though:
* The number of aliens in the mission report is inconsistent with the number of live aliens captured per research help. See [[Image:Alien_numbers_mismatch.zip]] and [[Image:Dead_alien_count.zip]].
* You can get X-COM MIA if you abort a mission, even if everyone is in the exit. Possibly a second stage bug only? See [[Image:X-COM_MIA.zip]]. Note that this only affects the report - after mission all the X-COM troops are still available.
:* This happens even on vanilla TFTD with that save. Given it's TFTD it could be an issue with the mapfiles. --[[User:BladeFireLight|BladeFireLight]] 00:23, 24 February 2010 (EST)
* Morale is random at start of second stage after autocombat of first stage?
:* Actually Morale is used as the clip size and time units as the weapon damage. Don't ask me why. It would take a major re-write of auto combat to fix this. --[[User:BladeFireLight|BladeFireLight]] 19:34, 23 February 2010 (EST)
* All Civilians are dead if AutoCombat is used to end a Terror mission. It's too not much of a problem, since score is likely to be positive anyway. It would possibly be an improvement to assume all civs from first stage are dead (if ran at second stage) and get a random number (using mission seed) for dead civs at current stage? [[User:Cesium|Cesium]] 07:00, 22 February 2010 (EST)
:* This is odd. Autocombat is supposed to skip over civilians when using the kill function. --[[User:BladeFireLight|BladeFireLight]] 00:18, 24 February 2010 (EST)
::Maybe kill civilians (or not) according to the force ratios. If XCom has only enough force to win the mission, all Civilians are dead. If XCom bring a certain amount of "excessive force", all or nearly all Civilians are saved. By the way I love AutoCombat, it is great for avoiding repetitive combat and only playing the new, interesting bits. [[User:Spike|Spike]] 15:53, 22 February 2010 (EST)

::: Thinking about this, I recalled the scenario where someone fights the mission and uses AutoCombat to hunt the last aliens (another reason AutoCombat is great). Spike's suggestion is better from pure RNG, since in this case probably all civs that were at risk already died. So lets see what we suggest XcomUtil do:

:::* Count civs from first stage if there was one as dead (since IIRC XcomUtil has no memory of first stage when exiting second stage, so we can't take them into account?).
:::* Deduct dead civs from current stage.
:::* Calculate extra dead civs using force ratio to bias the RNG (I prefer merely biasing the RNG rather than precluding results, since Xcom in general has a large variance in almost every gameplay mechanic). [[User:Cesium|Cesium]] 18:27, 22 February 2010 (EST)

* "if %xOS%. == DosBox. if %xOS%. == 4DOS. if %xOS%. == Unknown. dir *.xcf" - this is not an OR statement. This line will simply never be executed. You can use a goto to emulate if/else and to test the condition only once, e.g.:

if NOT %xOS%. == DosBox. if NOT %xOS%. == 4DOS. if NOT %xOS%. == Unknown. goto win
dir ...
goto next
win:
dir /b ...
next:
[[User:Cesium|Cesium]] 07:42, 22 February 2010 (EST)

==Open Bugs==
*Various second stage bugs - ammo clip recovery, crashes after autocombat of first stage, etc. Mainly for TFTD, but possibly Cydonia in UFO is also affected.
*RPL bug, when you turn creatures into Gill Men, they are reported as Snakemen
:: Reported how? Is this consistent? The name's used are from xcomutil.cfg. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
:::Sorry. It's reported in morale failure pop up messages. Though maybe this is an original TFTD bug rather than an XComUtil bug. [[User:Spike|Spike]] 19:21, 21 February 2010 (EST)
::: See this: [http://www.youtube.com/watch?v=uGlSghf7aTU]. In that case, all Gill man (were lobster man before RPL) were reported as snakemen.. [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST)
*RPL bug, when you turn Lobstermen into other creatures (e.g. Gill Men), they are very hard to kill despite having the stats of the creature they turned in to. Possibly they are keeping their damage resistance? Maybe the race is stored in more than one place, for different purposes, and XComUtil misses one of these places?
:: I will look into this --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: The RPL only changes the basics; The race, rank, name, TimeUnits, Health, Energy, Reactions, Armor(front,back,left,right), Strenght and PSI Strenght. All other stats are left as-is. --[[User:BladeFireLight|BladeFireLight]] 18:50, 21 February 2010 (EST)
:::: I'm not so sure about this. See 05:00 mark at [http://www.youtube.com/watch?v=y-_zLdjhUHI]. The armour doesn't match the one Gill man should have (per UFOpaedia, at least). [[User:Cesium|Cesium]] 19:34, 21 February 2010 (EST). See also 04:17 mark at [http://www.youtube.com/watch?v=z5LfzFSkRnI] for reason to suspect resistances aren't always changed. It's possible he just was unlucky though... [[User:Cesium|Cesium]] 19:53, 21 February 2010 (EST)
::::: Actually the function is something like this
<pre>#define UpdateStat(x,y) pur->x = (unsigned char) \
( ( (unsigned int)pur->x \
* (unsigned int)pasTo->y \
) / (unsigned int)pasFrom->y )
UpdateStat( TimeUnits0, TimeUnits );
UpdateStat( Health0, Health );
UpdateStat( Energy0, Energy );
UpdateStat( Reactions0, Reactions );
UpdateStat( AFront0, AFront2 );
UpdateStat( ALeft0, ALeft2 );
UpdateStat( ARight0, ARight2 );
UpdateStat( ARear0, ARear2 );
UpdateStat( AUnder0, AUnder2 );
UpdateStat( Strength, Strength );
UpdateStat( PsiStrength, PsiStrength );
</pre>
::::: the 0's are values at start of tactical.
::::: I read that as Current(from game_x) * Target default(from xcomutil.cfg) / source default (from Xcomutil.cfg) so the stats will be different. --[[User:BladeFireLight|BladeFireLight]] 21:33, 21 February 2010 (EST)
:::::: I'd have expected Current(game_x) == Source default if applied on first turn? This would end up with result == Target default, no? Hmmm... We already saw some compiler multiplication wackiness with the research help bug. Possibly this affected these calculations too?
:::::: As for the code, you're not updating PsiSkill, so non Psi-users can't get Psi after RPL. [[User:Cesium|Cesium]] 22:03, 21 February 2010 (EST)
::::::: I didn't write this. I'm amusing Scott did it this way to adjust for difficulty because XcomUtil.cfg has the beginner level stats. It need's an overhaul to use the full stat entries including the unknowns adjusted correctly for the level. Something for latter. --[[User:BladeFireLight|BladeFireLight]] 22:09, 21 February 2010 (EST)
:::::::: For this specific issue I think you will need to update 0x37 of [[UNITREF.DAT]] which is the Damage Modifier. In addition to the Psi Strength. Also Firing Accuracy, energy regen rate, movement class... loads of stuff. And of course LOFTEMPS. So with current RPL not changing LOFTEMPS, changed aliens are the wrong size and shape probably. This would be visible using the LOFTEMPS map viewer I suppose. [[User:Spike|Spike]] 18:39, 9 March 2010 (EST)
*[[Known Bugs#XComUtil Inventory Stacking Bug]]
:: I hope to overcome this but Scott's notes point to a technical limitation. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*Removal of Small Scout map / Survey Ship map, making it impossible to do these Battlescape missions.
:: 9.7 only removes the maps if you use the BFG. This will be addressed eventually. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*Was it really intended to '''not''' have nerfed the [[Manufacturing_Profitability#XComUtil_manufacturing_profitability|Profitability]] of the Fusion Ball Launcher along with everything else? More generally, the profit nerfing could be revised to be more orderly and more systematic.
:: I dont really know what Scott intended as for the profiteering off of the changed items. If you want to suggest alternative values I'm open to discussion. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: A preliminary suggestion would be to make the Fusion Ball Launcher similarly difficult to manufacture as the Plasma Beam, so about ten times harder vs the unmodified game. E.g. Workshop space 6 -> 60, 400 -> 4000 Engineer hours. And perhaps require 4 Elerium and 20 Alloys, placing it midway between Laser Cannon and Plasma Beams. These changes (even without the materials) make the FBL unprofitable, like the (modified) Plasma Beam. I'm sure part of Scott's intent was to prevent "Laser Cannon Factories", but "FBL Factories" are 75% as profitable.
::: General reform of the profitability of manufacturing would require a lot of thought. Suffice to say I don't think '''any''' thought went into this for the original game. In reforming the economics of XCom, a basic problem is that realism is at odds with game balance. Realistically, governments would pay handsomely for almost anything XCom can produce. What would be reasonable is to get a moderate rate of return, rising more or less linear with investment (research effort), for ''all'' items. For game balance, this could be tweaked down for items that are useful in the game, or have research predecessors / successors that are useful in the game. A simpler case is to say that no item has negative profit, you can at least get 'cost price' back for it. Aircraft should arguably be in this category (since they would sell for 100s of millions which would be totally unbalancing). A rationalisation for nerfing any prices is that the money received by XCom is not the whole sale amount, but just a small commission paid by the Council of Funding Nations, which actually controls the sales and takes (in exchange for its funding) most of the profits. [[User:Spike|Spike]] 19:40, 8 February 2010 (EST)
:::: FBLs are already pretty useless, and you want to nerf these further? I'd rather think of a way to make them more useful in-game, otherwise the profit should be kept (Note how it's the mostly useless craft weapons which are profitable - I suspect there was some thought into this..). In comparison, the Laser Cannon profit does get nerfed with XcomUtil, but we get a useful weapon instead. I'd suggest a modified FBL will have a very high elerium requirement, and the power of the weapon should be raised a bit to compensate. [[User:Cesium|Cesium]] 20:04, 8 February 2010 (EST)
::::: For example: Raise power to 240, and add another charge (almost enough to sink a battleship if a craft has two FBLs loaded), but make it cost 100 elerium to make launcher. Raise hours for Balls by factor of 10. [[User:Cesium|Cesium]] 20:16, 8 February 2010 (EST)
::: Actually you're right, it makes more sense to make FBLs viable, instead of (just) nerfing the profits. Obviously high Elerium requirements will make them non-profitable. But of the 2 problems - making things useful and preventing 'factory farming' - I think making things useful is more important. I didn't realise FBLs were not tactically useful. I've never built them, only Plasma Beams. 3 ammo is reasonable, it means that 2 FBL armed aircraft have a good chance to take down a Battleship, if they can fire 9-10 out of 12 fusion balls before they are both killed. But 100 Elerium is way too much for an improved FBL that's only slightly more powerful. I think my suggestion (4 Elerium, 20 Alloys, 10x hours, 10x space) fits with the requirements of other XComUtil-modified weapons. Combined with your suggestion of 3 ammo and 240 damage, I think it would make FBLs ''useful'' again, which is one of the original goals of XComUtil.
::: Of course, it's ''possible'' that Scott was cleverly making FBLs useful, by making them so much cheaper (net) to manufacture than Plasma Beams. In an XComUtil modified game, you might well deploy FBLs first, and only work your way up to Plasma Beams later, because of the huge manufacturing costs of Plasma Beams. But personally I think it was an oversight. [[User:Spike|Spike]] 17:21, 9 February 2010 (EST)
:::: I've never played with XcomUtil modified lasers, so if you say this fits in better that's fine with me. It's unfortunate it involves increasing space: inventory management is one of the things I hate about the first two X-Coms. I was hired to be a commander, not a supply clerk! A mod which made general stores have 10000 space (like Apoc) would be nice.. [[User:Cesium|Cesium]] 21:39, 9 February 2010 (EST)
:::: Actually the energy weapon mod means they uses more ''workshop'' space to build but not more inventory space to store.
::::However "An army marches on its stomach ", Napoleon said, by which he meant that wars are won or lost on logistics. Other famous commanders have said similar things. So a general should pay attention to logistics. One of the great things about XCOM is it's not just a tactical game, it's a combined political - strategic - operational - tactical game. [[User:Spike|Spike]] 04:37, 14 February 2010 (EST)
*Zrbite lying around in odd places. Objects lying around in odd places in general - these are map modifying errors, probably only occur when customising terrain etc.
:: Will be part of an overhaul of the BFG --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
*Also the '''xcsetup.bat''' prompt for the option of less-profitable weapons manufacturing is misleadingly called "new laser weapons". This should be much more clear eg "Much more difficult to manufacture advanced weapons [except FBLs]" or similar.
:: This seems to be a common complaint. I will look into better wording. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: Actually it might be an idea to break this up into sub-options. It does a lot of things! The "new laser weapons" option requires the use of extra alien materials in order to manufacture almost all energy beam weapons (not just lasers). It also makes the human manufacture of the alien plasma beam small arms impossible (research success merely allows X-COM to use captured weapons). The manufacture of craft Plasma Beams is still possible, but is made significantly more difficult (ten times the labour and workspace requirement as well as additional materials). As Scott says this "seriously changes the economics of the game". It also significantly alters the balance of firepower in the air and (to a lesser extent) on the ground. [[User:Spike|Spike]] 19:40, 8 February 2010 (EST)
*There is a small problem in editing/customising craft using '''XComUtil.cfg'''. Certain X-Com craft weapon values - the rate of fire value - can't be set. Or more specifically, they can be set (patched) in the executable but it has no effect in the game. To avoid confusion they should perhaps be removed from the format of custom craft, or commented out. (This rate of fire patching ''might'' work on UFOs, haven't tested it).
:: Can you be more specific? --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
::: There is a section in '''xcomutil.cfg''' which is used for patching XCom craft weapon characteristics. This is where Scott changed values for the Laser Cannon, etc. Probably very few people use these fields. I only used them because I was doing research into the game mechanics. One of the values changed in this section is the reload time. These values are present in the executable, and can be patched, but patching them has no effect (other than to change the UFOPaedia entry). The reload time seems to be hard coded elsewhere in the executable, based (broadly) on the class of weapon. So you might want to comment this column with an a note saying "cannot be modified for combat". On the other hand I could be wrong, or someone still might want to modify these fields. Discussion is at [[Talk:UFO_Interception#Observed_Rates_of_Fire]]. Offsets are at [[Talk:GEOSCAPE.EXE#Craft_weapon_stats]]. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
:::: Or maybe change these display-only values so that they reflect the [[Talk:UFO_Interception#Observed_Rates_of_Fire|observed reload rates]]? I am not yet 100% sure I have got these right, might want to wait until I do some more confirmation tests. [[User:Spike|Spike]] 15:26, 22 February 2010 (EST)
*EQL only works on turn 1 (see discussion above)
::: Added to my to do list. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)

*Remove 3rd burst for Pistol - it's already good enough, as NKF has shown
::: do you have a link to NKF's comments? --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
:::: Having trouble finding his comments, maybe he'll show up here! See [[Rifle_vs_Pistol]], also [[Talk:Squad_Composition_and_Tactics#Starting_Sniper_Weapon]]. If anything there is a case for the Pistol to be nerfed slightly (eg Damage=20, Ammo=8), or for the Rifle to be buffed. Also worth looking through [[Weapon Analysis]] for general thoughts on weapon power and balance. The weapon set in EU is actually remarkably well balanced already.
::::: Further to this - not a bug but it's really wrong for a projectile weapon, a firearm, to have the same accuracy on Auto as on Snap fire (60). Even plasma weapons have Auto accuracy somewhat lower than Snap. If you reduce the Pistol burst mode accuracy by anything less than 2/3rds, the burst function is still useful, but more balanced. Actually even with a reduction of ''greater'' than 2/3rds, it would be useful, because of the increased damage at point blank range. Which is perhaps realistic for a burst-mode pistol. 60 Accuracy is higher than any Auto weapon in the game, for what ought to be the least accurate auto weapon. The best auto firearm is the Rifle at 35. Anything over 20 is still a bonus for the Pistol. How about 25? This still gives burst mode a 25% edge over Snap mode at long ranges, and a big improvement at close/point blank. 30 would make it more accurate than a Laser Pistol is on Auto (28), which is hard to justify. Admittedly the Pistol burst mode uses 3x (?) the TUs, so maybe some latitude can be given. Maybe go to 30 Accuracy, then, but no higher. [[User:Spike|Spike]] 19:49, 11 February 2010 (EST)
:::::: An interesting idea. Scott felt that this was just to make the pistol useful by allowing three snaps to be treated as one action so you dont deal with Reaction fire. The end results is the massive time units and same accuracy. If I lowered the accuracy I would have to lower the time to. I believe there is a reason the pistol doesn't have full auto in the vanilla game. You have seen a military issue full auto pistol? --[[User:BladeFireLight|BladeFireLight]] 21:15, 11 February 2010 (EST)
: Indent reset! I can't remember what my comments were either, but it's probably has to do with the weapon anaylsis and how useful snap shots already are. 'tis a jolly good weapon. I agree that you can't just make the auto mode identical to three snaps - you've got the added bonus of uninterrupted fire for the first two shots. You need to pay this off either with reduced accuracy or increase the usage cost.
: For consideration, I was actually fiddling with the weapons a few months back and was testing a 10% accuracy burst mode at 15% TU costs. I think 10 or 15 AP damage. Turned out way-way too powerful a weapon (against soft enemies) - and this was on a rookie I just picked randomly. It was probably too fast, but it still worked fairly well at 10% accuracy. 60% accuracy does feel quite high. -[[User:NKF|NKF]] 00:14, 12 February 2010 (EST)
:: Exactly. The point is that a 3-rd burst makes the Pistol more useful, ''even if the per-shot accuracy is lower'', because you get 3 attempts to kill the target before it Reaction Fires, rather than just one. As long as the ''net'' 3-rd accuracy isn't less than a single Snap shot, the weapon has been improved. The break-even point is about 26% accuracy on auto. At this level, 3 rounds have a ~60% chance of getting ''at least one'' hit. Even if the 3-rd accuracy was lower than a single Snap shot, you would still get the advantage of multiple hits at very close range. I would strongly suggest no more than 25% accuracy for Pistol auto burst, at the same level of TUs (3x Snap right?). This will definitely still be a significant improvement for the Pistol. Probably what was not fully understood at the time Scott did the original mod, is that the Pistol is arguably ''already'' the most effective starting weapon, certainly against the initial opponents. [[User:Spike|Spike]] 13:19, 12 February 2010 (EST)

* Fusion weapons inconsistently exempted from the "more difficult" energy weapons manufacturing option ("alternate laser Tech"). Blaster Bombs and Blaster Launchers, Fusion hovertanks and ammo, and Fusion Balls and Fusion Ball Launchers - none of these are harder to build or use with the "alternate Tech" option. Why make laser weapons/tanks and plasma weapons/tanks harder but not Fusion weapons? It's not consistent. I wonder if Scott didn't look at these because he never used Blaster Launchers or Fusion Hovertanks, as he considered them to unbalancing already? And ignored FBLs because, well, most people ignore them? But this should be consistent. Or, the "harder weapons" option could be broken down into sub options, e.g. for each weapon technology:
** Much more expensive (typically: add some exotic materials, 10x workshop space and 10x Engineer hours)
** Can/can't manufacture the battlescape weapons/tanks (pure alien weapons only)
** Can/can't manufacture the ammo (pure alien weapons only)
:Personally I would prefer it to be all-or-nothing but include the Fusion weapons as being more difficult to make and use. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)

* SteamSetup.bat won't run from DOSBox. It says "This needs to be run from Windows". Though, does it make any sense to run SteamSetup.bat under DOSBox (eg for a linux system with no Steam)? [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)

* It's actually quite hard to downgrade to DOSBox 0.72 in Ubuntu. Only 0.73 is offered, there is no ability to Force back to a lower package level with Synaptic Package Manager. Unix guru skilz are required to rollback to 0.72, and I guess 0.74 is not around yet, or not packaged for Ubunut APT? Is there any way to fudge around this, e.g. by providing the command line arguments in an optional text file for xcusetup.bat to parse? Having said that, even with no command line arguments, xcusetup hangs on my 0.73 DOSBox while executing SDUMP. I had to reboot in Windows to run xcusetup.bat - something that is only possible on a dual boot machine / Wubi machine. [[User:Spike|Spike]] 08:02, 7 March 2010 (EST)
** Try using a different batch interpreter like 4DOS [http://www.4dos.info] to execute xcusetup inside DosBox. I tested this throughly before under DosBox/Linux and it works well with recent 9.7 builds. I suggest running "config -set cpu core=dynamic" and "config -set cpu cycles=max" before xcusetup to speed it up (xcusetup doesn't detect DosBox when 4Dos is run, so it doesn't run these automatically unlike normal DosBox case). [[User:Cesium|Cesium]] 09:48, 7 March 2010 (EST)
** Oh, and downgrading isn't that difficult: Get a dosbox 0.72 deb, and run "dpkg -i" on it, and then do "echo dosbox hold | dpkg --set-selections" to prevent future upgrades. [[User:Cesium|Cesium]] 09:50, 7 March 2010 (EST)
** Another option is to install the dosemu package, and run xcusetup under that. EU/TFTD can be run under that, but it doesn't work as well there. (Oh, and there's no mount command there. UFO/TFTD needs to exist under ~/.dosemu/drive_c which is C:) [[User:Cesium|Cesium]] 11:42, 7 March 2010 (EST)

:Thanks Cesium I will check this out. I still think it would be good to have a solution that works for people who are not knowledgeable with the unix command line though. [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)

:: Why use Linux if you dont know how to use the console? It is a text mode OS with a separate GUI. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)

::: Well Ubuntu is a bit different, as it's supposed to be an OS for the general public, where you never need to touch text mode! Incidentally I can't find any DEB or other packages for 0.72, all that is available on the DOSBox website is the source code. They really don't seem to realise that 0.73 is buggy! So I guess I will need to '''make''' it. Or just wait for 0.74 as I think it's out soon. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)

:::: See [http://archive.ubuntu.com/ubuntu/pool/universe/d/dosbox/] for 0.72 debs. Unlike Windows, package systems in Unix land are centralized, so best location to search is typically a package server mirror or a distro mirror, not a vendor's website. [[User:Cesium|Cesium]] 17:36, 9 March 2010 (EST)

* '''cfg/ShipDefU.txt''' has the XCU values for improved Laser Cannon (35/35/35), not the original values (21/35/70). Is this correct - is this file supposed to be the original defaults? [[User:Spike|Spike]] 10:15, 7 March 2010 (EST)
:: I was unawhare that this had been changed. The weapons are not prompted for any change so they should not be changed. I'm reseting them all to defaults and looking to see if Scott had anything about them in the notes. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)

=== AutoCombat issues ===
* Day vs Night
** The Day/night algorithm breaks. For example, at any point when XCom has twice more flare-carrying soldiers than there are aliens, XCom is actually ''stronger'' in darkness than it would be in full daylight. Toward the end of a battle this is a very common situation. But fixing the algorithm is tricky. What might work is to give -10 for each Soldier in darkness, reduce from -20 to -10 for each Alien in darkness, then add back +10 for every soldier with a light source. Thus there is no way XCom can go 'net positive' from light sources.
:: If you have more units then they do you can see more of the battle field. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:::It never makes sense for XCom to be stronger at night, than during the day, for the same force ratio. But that is what happens. An example. 10 XCom soldiers with flares and 3 aliens. At night there is an extra -30 modifier for the aliens, but a +100 modifier for XCom, net +70. The same 10 soldiers against the same 3 aliens are +70 ''more'' effective in darkness than they would be in daylight. It does not make any sense. [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
** The definition of a light source should be expanded to include a Flare ''or'' an Incendiary weapon. In fact, one Incendiary-capable weapon of any type (AC/HC/HjC/GC), with appropriate Incendiary rounds carried, should be enough for the entire squad to be considered as having a light source. But this may be hard to implement without a special flag and a special pre-search for a valid Incendiary weapon, since AutoCombat normally scores by individual soldiers, not by whole squads.
:: This would take a rewrite. currently the ammo is not used by W: --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
** To be honest I would prefer that each soldier without a light source in darkness is 50% effective, each soldier with a light source (personal or squad), is 75% effective. Meanwhile how about this:

//Darkness
-10 L:-9 u:-2 // Human in Darkness

+10 L:-9 u:-2 W:-27 U:- // Human in Darkness w/Flare -OR-
+10 L:-9 u:-2 W:-4 W:-7 U:- // Human in Darkness w/In ammo and launcher HC/GC-IN -OR-
+10 L:-9 u:-2 W:-8 W:-11 U:- // Human in Darkness w/In ammo and launcher AC/HjC-IN -OR-
+10 L:-9 u:-2 W:-12 W:-15 U:- // Human in Darkness w/In ammo and launcher IN Rkt/Torp

-10 L:-9 u:4-14 // Alien in Darkness
:: Only thing I see is that this ''must'' come at the end. The U:- removes the unit from further consideration. --[[User:BladeFireLight|BladeFireLight]] 19:58, 9 March 2010 (EST)
::: Yes, to use the U: flag for this "OR" function, it must come at the end of the section for humans. That's how I have it my updated AutCombt.txt, these fragments are a bit out of context. It's not critical to have the "OR", it's just nice-to-have as it stops someone cheating by having a flare and one of each loaded incendiary launcher weapon in each hand and in their backpack, to get quadruple score. But hopefully people are unlikely to cheat at AutoCombat, there are easier ways such as the WIN flag. [[User:Spike|Spike]] 20:39, 9 March 2010 (EST)
* The Zombie is rated the same as a tank, a Chrysallid/Tentaculat or an effective Psi alien (-50). I think this is too high, as Zombies are much weaker than those units. A Zombie should be maybe -25.
: Disagree. the zombie should be slightly higher then a Chrysallid/Tentaculat as it will become one and you have to kill it twice. --[[User:BladeFireLight|BladeFireLight]] 18:11, 7 March 2010 (EST)
:: OK good point! [[User:Spike|Spike]] 20:42, 7 March 2010 (EST)
* Area effect weapons (HE, IN, Small Launcher) should have at least the same bonus as effective-on-Auto weapons (+5). This is because they can damage/kill multiple targets. (The AC/HjC should not get both bonuses however.)

//Area Weapons. ToDo: compensating bonus for aliens. should not be cumulative. check if "effective?"
+5 u:-2 W:-4 W:-6 // Human w/HE ammo and launcher HC/GC-HE
+5 u:-2 W:-8 W:-10 // Human w/HE ammo and launcher AC/HjC-HE
+10 u:-2 W:-12 W:-13 // Human w/HE ammo and launcher Sm HE Rkt/Torp
+10 u:-2 W:-12 W:-13 // Human w/HE ammo and launcher Lg HE Rkt/Torp
+10 u:-2 W:-42 W:-43 // Human w/ Stun/Shok Launcher and ammo
+25 u:-2 W:-40 W:-41 // Human w/ Blaster/DP Launcher and ammo

-10 u:4-14 W:-42 W:-43 // Alien w/ Stun/Shok Launcher and ammo
-25 u:4-14 W:-40 W:-41 // Alien w/ Blaster/DP Launcher and ammo

::Having tested the first 2 rules, the first rule (HC-HE) does not work unless you remove the ammo specifier W:-6, making it just a test for an HC. But weirdly the second rule (AC-IN) works fine with its ammo specifier in place. Odd. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)

* Pistols with the burst mode option should not count as Auto weapons (maybe they don't).
: Burst and snap are based on default stats --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
* Blaster Launchers / DPLs (with ammo) should be worth as much as a tank, e.g. +/- 50 (including the single shot effective bonus it should already get - see suggested rule above under area weapons)
* Should distinguish between tanks. Even with improved armour, a Tank/Cannon is not the same as a Fusion Hovertank. I would suggest a range of 25 for a Tank/Cannon to 75 for a Hovertank/Fusion. Maybe 40 for a Tank/Rocket, 50 for Tank/Laser, 60 for a Hovertank/Plasma?
:This does not seem to be possible with the existing ruleset as all Tanks are unit type 3
::Hmm, byte 42 of [[UNITREF.DAT]] is Rank but also Tank chassis. So this ''might'' allow distinguishing tracked tanks from hover tanks, at least. An alternative approach would be to pick some stat (that has a StatStrings statid) and set it to a different unique value for each tank type. [[User:Spike|Spike]] 18:32, 9 March 2010 (EST)
* Flying units (either side) should be worth say +/- 5
:Not possible for XCom as no distinction between Power Suit and Flying Suit. Would be possible for aliens eg:

-5 T:0- u:6-6 // Flying Alien - Ethereal
-5 T:0- u:8-8 // Flying Alien - Floater

* If the squad is carrying some Smoke or Dye that should be worth maybe +5 - +10. But since the aliens don't ever carry that, you need some balancing factor for them.

+1 u:-2 W:-20 // +1 per human with smoke grenade(s) (hopefully not +1 per grenade!)

* Effective melee weapons should be counted. This is particularly important in TFTD when ranged weapons may be ineffective, e.g. vs Lobstermen.
* Similarly if the enemy are in heavy armour and therefore a soldier/alien does not have an effective weapon, any HE Pack / Alien Grenade / Sonic Pulser should be counted for something (if it is "effective").

//Melee weapons
+5 u:-2 W:1- W:-26 // Human w/o effective ranged weapon but w/ Stun Rod
+5 u:-2 W:3-26 // Human w/ effective Stun Rod (cumulative to above)

::The second rule doesn't work at all, it looks like it counts all items of types 3-6. The "superiority" function (first value before the hyphen) does not seem to operate, probably because it is a melee weapon. [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
::: did you try W:255-26 ? not that I know if it would work. AutoCombat doesn't recognize stun rods as weapons when applying damage.--[[User:BladeFireLight|BladeFireLight]] 21:01, 9 March 2010 (EST)

//Grenades
+5 u:-2 W:1- W:-19 // Human w/o effective ranged weapon but w/ effective grenade(s)
+5 u:-2 W:1- W:-21 // Human w/o effective ranged weapon but w/ effective prox grenade(s)
+5 u:-2 W:1- W:-22 // Human w/o effective ranged weapon but w/ effective HE pack(s)
+5 u:-2 W:1- W:-44 // Human w/o effective ranged weapon but w/ effective Alien grenade(s)

-5 u:4-14 W:3-44 // -5 per Alien with effective Alien Grenade(s) (hope not -5 per grenade!)
:: Only one per unit. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)
::: Tested ok too! [[User:Spike|Spike]] 20:41, 9 March 2010 (EST)
* AutoCombat victories should award all UFO Components, not just some Navigation, Elerium and Alloys.
* Every Civilian on the map should be a penalty to XCom of maybe -5, due to the distraction effects of trying to save them / avoid killing them.

-5 u:15-16 U:- // Civilian distraction effect, no further effect

Let me know if I should try to work some of this up as AutoCombat rules. Some of it requires new coding of course, but a lot of it could probably be done with existing rules. [[User:Spike|Spike]] 13:15, 7 March 2010 (EST)
: I dont plan on any changing to the underlying code yet. Your welcome to make up a new set of rules and testing them out. --[[User:BladeFireLight|BladeFireLight]] 18:23, 7 March 2010 (EST)
:: OK added some rules above. I have not tested them yet, some of the syntax might not work. [[User:Spike|Spike]] 17:25, 9 March 2010 (EST)
::: Syntax looks good to me. Give them a test and let me know how they go.
::: Just a quick note on how AutoCombat works. First the success percent chance is calculated using the AutoCombat StatStrings, dead and unconscious units dont count. (those that bleed to death are considers alive, need to fix this). If it's below AbortThreshold it aborts. If it's 100-199 then change to 90. 200+ change to 95 (success is never a guarantee.) Aliens roll d100, if over your success chance you lose. If You win. Then average damage by each side is calculated based on Loaded weapon being carried and time units. All aliens are killed or stunned by X-Com unit chosen at random. Each Alien gets a chance to wound an X-Com unit based on Success Percentage. Randomly choose unit using random damage (max is average alien damage) Leave at least one X-Com Unit alive. --[[User:BladeFireLight|BladeFireLight]] 20:32, 9 March 2010 (EST)

==Fixed Bugs==
* standalone patches the fix the difficulty bug
::9.7 min install is the dificulty patch and changeing Copy protection questions to all 0's.
*Prompted Terrain displays the options but the prompt doesn't display until after a key press.
:: I guess Open Watcom's version of printf does not auto flush to the screen like Borland did.
*Version detection issues with obscure versions (Italian, 1.2a, etc.) causing corruption or lack of patching.
:: Cesium; XcomUtil doesn't have the offset for the copy protection for the Italian version coded. However the file you sent me is detecting as 1.3. none of the offsets will line up. The offsets Scott used to detect Italian are unique and may have been based on 1.0 or 1.2. Was that a clean unmodified copy? I need a clean one to validate all the offsets and update XcomUtil. --[[User:BladeFireLight|BladeFireLight]] 13:23, 16 February 2010 (EST)
:: I loaded it up and notice it does not ask for a language. this would imply it's based on X-Com 1.3 and not UFO 1.3. --[[User:BladeFireLight|BladeFireLight]] 13:33, 16 February 2010 (EST)
::: I didn't send you the installer since it's a mess (it requires some subst magic to work), but it looks authentic. Use the same link as before if you want to take a look at the installer. There's an Italian readme attached which points to some (now defunct) Italian sites. I didn't do any changes besides installing X-Com and then testing out XcomUtil. [[User:Cesium|Cesium]] 14:01, 16 February 2010 (EST)
:::: Italian UFO detection and offsets added, 1.2a offset's fixed.

*Various default options make the game easier, not harder (''harder'' being the intent of XComUtil, right?). These should not be defaults. (More discussion at [[Talk:Enemy_Unknown_Extended#Standard_Config_Discussions]]) E.g.
::: 9.7 only has 3 items on by default. Remove copy protection. Fix Difficulty bug and Split EXE (split EXE can be skiped but not the others). All other options are default to NO.
::: As for the intent of XcomUtil. Scott added features to
:::# Increase difficulty.
:::# Make useless items useful.
:::# Get the game Started faster.
::: I have added:
:::# Don't make unwanted changes.
:::# Fix game bugs
:::::Yes all of those are very sensible. [[User:Spike|Spike]] 19:00, 8 February 2010 (EST)
::::Latter versions of XcomUtil will turn the last two forced items to prompted. with only the Difficulty bug and the split EXE as Default=Yes. --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
**Basic tanks using advanced tank stats
**Improved High Explosive - very powerful in favour of X-Com, especially as alien spawn points and routes aren't set up to cover holes in UFO hulls.
**Gauss weapons have infinite ammo
::: 9.7 has a second option to just the increase power to closer match UFO.
**Using fighters as transports (carrying soldiers)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
**Using transports as fighters (weapon hardpoints)
::: Optional in 9.7 --[[User:BladeFireLight|BladeFireLight]] 22:34, 7 February 2010 (EST)
**Improved Heavy Laser / Heavy Gauss. OK, this should maybe be a ''recommended'' option since the unpatched weapons are nearly pointless. But, it does make the game easier.

[[User:Spike|Spike]] 20:12, 7 February 2010 (EST)

=XComUtil Wish List=
Things that are not bugs or inconsistencies in XComUtil but would be Nice To Have

== Features for 9.7 - Interface, consistency and bug fixes ==

=== Categorise Config Options ===

For each option, in the prompt, note which category of option this is, according your list above. E.g. faster start, making the game harder, making useless items useful, bug fix, variant game, etc. [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)

:Actually it might be even better to organise the options questions into sections, thematically grouped by these categories. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

:: Items are currently sorted like this.
* Windows EXE
* Game Fixes
* Game Mods
** Sound
** Craft
** Base
** Equipment
** Research
** Units
** Battlefield
** Alien Craft
** Misc
--[[User:BladeFireLight|BladeFireLight]] 19:25, 10 March 2010 (EST)

=== Improved Base Comes At Cost ===

The Improved Base is supposed to be a "faster start" option rather than a "make the game easier" option. But it does make the game easier, not least because it gives you a load of free base facility improvements. (Not to mention not having to struggle along the first month with only Small Radar and no Alien Containment) To partly avoid making the game easier, please add a sub-option that subtracts the cost of the extra facilities from your starting cash. This should be the ''full'' cost of the extra facilities, not just the difference between e.g. a Small Radar and a Large Radar.
[[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
: I dont have the offsets to the starting money ranges. so I cant do this. --[[User:BladeFireLight|BladeFireLight]] 19:13, 10 March 2010 (EST)

=== BFG Default To Unchanged ===

Is it possible when using the BattleFieldGenerator, for it to detect the actual conditions for the mission (terrain, enemy craft, and light level) and offer these as defaults? [[User:Spike|Spike]] 08:22, 13 February 2010 (EST)
:Press The esc key at the prompt. (Line 719 in Xcomutil.txt, not that I expect anyone to read the manual :) ) Enter should also work. --[[User:BladeFireLight|BladeFireLight]] 12:34, 13 February 2010 (EST)
:: RTFM eh? My biggest failing. Maybe you could add an explicit prompt "Esc or Enter = [whatever the unmodified value would be]". [[User:Spike|Spike]] 15:32, 22 February 2010 (EST)
::: From what I can see, hitting Escape during BFG makes it continue with ''all'' values reverting to the original conditions. It would be nice to be able to select some but not all original conditions. My main use of this is to turn a night mission into a day mission without the hassle of keeping the landing craft hovering around until the terminator crosses the landing site. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)
:::: You could just use the force all daylight option.
:::: After reviewing Scott's code. Esc leaves all setting as-is. Pressing enter or any other key not listed will randomly choose for you. I will see if I can change enter to leave as is. --[[User:BladeFireLight|BladeFireLight]] 11:00, 7 March 2010 (EST)

== Features for 9.8+ - New features ==

=== AutoCombat ===

==== Firepower Factors ====
You might want to consider replacing the weapon offensive weighting factors for Autocombat with some factors that are (inversely) related to the [[Weapon_Analysis#Quantitative_Analysis|% TUs Per Kill]]. I've tabulated these for each weapon (including tanks) vs each alien race. You would still need to account for Psi, light/darkness, and XCom armour. Plus you would need a similar offensive factor for the aliens' attacks. But I could probably help with that, I have the data that's directly comparable to the % TUs per Kill for XCom weapons. [[User:Spike|Spike]] 22:06, 12 February 2010 (EST)

==== AutoWithdrawal ====

One of the most tedious things you can try to do in XCom is to scavenge the battlefield and retreat to landing craft for an Abort. A great option would be an AutoWithdrawal, similar to an AutoCombat, but with an easier threshold of XCom vs Alien combat power.

Basically it would scavenge all loose equipment off the Battlescape - dropped friendly and alien items, friendly and alien corpses and wounded, all go back into the landing craft. Elerium, Alloys, and UFO Components would not be recovered, as this is (normally) impossible apart from full tactical victory. All friendly troops return to the landing craft. Friendly losses, and equipment recovered, would be proportional to the offensive factor ratios but much more favourable than for AutoCombat. E.g. as long as XCom factors were at least equal to Alien factors, they would be able to scavenge everything and recover without casualties. If the aliens were stronger than XCom, they would only recover part of the scavenged equipment, and risk partial casualties, at say one third the rate of AutoCombat. [[User:Spike|Spike]] 06:58, 7 March 2010 (EST)

: It's too easy compared to actual game IMHO. Every time a battle went FUBAR for me, it got FUBAR all the way and I was lucky if I could salvage my own team/equipment and maybe a single alien weapon/body. An AutoWithdrawal without salvage might be useful, but perhaps instead we should change AutoCombat failure mode to work better (e.g. Make some X-COM people survive a failed AutoCombat, depending on strength vs aliens). [[User:Cesium|Cesium]] 15:00, 7 March 2010 (EST)

:: Yes fair point. I was not thinking of the FUBAR situations, and you are right about how hairy those are. I was thinking of the situation where you control a certain part of the battlefield, but you either don't want to go on an endless hunt for the last few aliens, or you pretty much know you can't take on the aliens that are left (e.g. in the UFO or some other stronghold) without getting creamed. You can exercise a safe withdrawal, it's just tedious to carry out all the bodies and equipment. But it's pretty hard for an AutoCombat algorithm to detect which of those situations it is - FUBAR, boredom, or tactical withdrawal. I'll have to think about that, there may be no realistic solution at all. And there is the existing "teleport loose items back to base" command line option to XComUtil, maybe that's enough. [[User:Spike|Spike]] 16:08, 7 March 2010 (EST)

=== Tougher UFOs ===

[[Wish_List_(EU)#Tougher_UFOs|Tougher UFOs]]
As this is entirely implemented by patching data and data files it is a good candidate for XComUtil rather than [[UFO Extender]].
: That would definitely make the game harder. 9.7 is about the installer and the bug fixes. This would be a good candidate for 9.8. --[[User:BladeFireLight|BladeFireLight]] 01:38, 19 February 2010 (EST)
:: Cool! [[User:Spike|Spike]] 02:25, 19 February 2010 (EST)

=== Rebalanced Craft Weapons ===

This fits under the "making useless things usefull" category. It would be a 9.8 or later option. The idea is to make the Cannon, Stingray, Laser Cannon and Fusion Ball Launcher useful. Hopefully it breaks up the monotony of Dual Avalanches followed by Dual Plasma Beams, every game.

There is one common element in the approach, and two options. The common element is to fix the stats on the Fusion Ball Launcher. The two options are to use a stat-based approach, or a cost-based approach, to fix the other weapons.

NB This proposal is still a draft and will need tweaking, but I've got it to the point where it is worth discussing. Feedback is welcome!

''(Ultimately, the Plasma Beam still ends up being pretty much the optimum weapon in the end game. To mitigate this, it is a good idea to select the existing Alternate Energy Weapons Manufacturing option in XComUtil.)''

==== Fusion Ball Launcher ====

Increase the ammo capacity from 2 to 3. Don't mess with the damage. Job done.

See [[User:Spike#Fusion_Ball_Launcher]] and discussions linked from there.

==== Cost Based Approach ====

This uses historically realistic costs to restore game balance between different craft weapons. The stand off advantage of Avalanche missiles is now purchased at a price which is significant in terms of XCom budgets and mission yields. Stingrays and Cannons become significantly cheaper alternatives. The Laser Cannon, with similar capabilities to Stingrays but free to operate, also becomes very attractive. Mounting dual launched weapons becomes a very expensive luxury.

*Increase Avalanche missile Purchase cost to $386,000
*Increase Stingray missile Purchase cost to $125,000
*Leave Sell prices unmodified (to avoid creating a cash reservoir at the start of the game)
*Leave Launcher buy/sell prices unmodified

See [[User:Spike#Cost_Based_Rebalancing]]

==== Stat Based Approach ====

This provides a benefit trade-off to shorter range weapons, by increasing their firepower or effectiveness relative to longer range weapons.

*Increase Cannon stats to 15 Damage, 50% hit. Firepower is tripled, slightly ahead of (unmodified) Avalanches launching in Aggressive mode. Increase rearming rate to 200.
*Increase Stingray accuracy to 80%. Decrease Avalanche accuracy to 60%. Stingray now has 50% more firepower relative to Avalanche. Increase Stingray rearming rate to 2, so a full craft can be re-armed in the same time period with either weapon (instead of twice as long for Stingray).
*Increase Laser Cannon stats to 100 Damage, 50% hit. Firepower is doubled, 20% more than (unmodified) Avalanches launching in Aggressive mode, 2/3rds of Plasma Beam firepower.

To avoid advanced XCom aircraft exploiting the extra firepower of the Cannon weapons and disregarding the return fire from UFOs, this is best used alongside the Tougher UFOs option.

See [[User:Spike#Stat_Based_Rebalancing]]

=== Rebalanced Infantry Weapons ===

See [[User:Spike#Balancing_Infantry_Weapons]]

Primarily this means making the Rifle a bit stronger, and probably making the Pistol a bit weaker.

==See Also==

[[Wish List]]

= Completed Wish List Items =

==Easier Inventory Management==
Inventory management is one of the things I hate about the first two X-Coms. I was hired to be a commander, not a supply clerk! A mod which made general stores have 10000 space (like Apoc) would be nice.. [[User:Cesium|Cesium]] 21:39, 9 February 2010 (EST)
: The manager of any facility has to deal with generalities of space issues. The clerk tells you if that fancy new tank you just bought will fit. He has to put it in storage and keep track of what shelf the ammo is on. --[[User:BladeFireLight|BladeFireLight]] 22:27, 9 February 2010 (EST)
:: That's the clerk's problem and if he complains too much I'll have him peel potatoes until his hands drop. In any event, the limit doesn't make any sense:
::* General stores size is 8x8x2 (8x8x3 in TFTD) per base defence map, and should have no problem storing more than 50 items.
::: The items taking up 1 item unit are typically about the size of humanoid body. I think it's not unreasonable to have no more than 50 of those in the area that the General Stores takes up.
:::: I can't find a list on the wiki of storage space requirements for items, so I'm not sure which items take up 1 item unit. Typically the main space wasters are Heavy Plasma ammo/Blaster Bombs/Stun Bombs (late game) and/or HWPs and avalanches (early game). These either are definitely not the size of a human body (ammo/Bombs), or shouldn't be stored in stores at all (HWPs gain nothing, and might as well lay around somewhere else in base).
::* The size of a fully built X-Com base is about the size of a city block (judging by comparison of base defence to terror missions), and should easily be able to hold hundreds of items even in the starting base if it's willing to put some stuff not in the general stores.
::* The space limit makes no sense. Why do Blaster Bombs and Heavy Plasma ammo take so much space whereas in the inventory view it doesn't take any more than normal ammo? Who stores <s>mini tanks</s> HWPs in the same compartment as light weapons? And the way X-Com (probably) stores ammo and explosives is scary...
::: As you suggest, extremely powerful ammunition probably requires a lot more space for safe and secure storage in-base, versus on a tactical mission. Imagine what would happen if a Blaster Bomb exploded in a base? Or was stolen? They probably use nuclear warhead style storage facilities for those. And similarly for Avalanche warheads, alien artifacts, Elerium, etc. Segregating dangerous/explosive items from other items probably uses up a lot of overhead in the construction of the storage space - think armoured, bomb-proof lockers and bulkheads, advanced security systems, airlocks, scanners, etc. This is not just like piling stuff up in your shed! And the Commander who left Elerium or Avalanche warheads lying around in his hanger or corridors would justifiably be sacked on the spot by XCom High Command. [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Well, judging by all the explosives in the hangar during base defence and the X-COM 1.0 Elerium bug, Elerium and explosive warheads ''are'' lying around in the base... And all the equipment in the General Stores is stored in ordinary lockers according to the General Stores map ;-) More to the point, if X-COM wants to store explosives safely (judging by said warheads X-COM doesn't care too much) they need a special facility for this, not to store them in the room which also contains all the base's weapons and priceless alien artifacts.

:::: Furthermore, I expect X-COM to improvise on storage in the interest of actually winning the war. X-COM does do this and ignore the limit when manufacturing stuff in-base or getting loot from missions. All that's needed is that X-COM will improvise for transfers too. I can't imagine a quartermaster informing the commander there isn't any room for the new armour and that the troops should go without. Maybe the reason X-COM doesn't pay quartermasters each month is that they keep getting themselves lynched by enraged X-COM troops...
::* Gameplay wise, inventory micromanagement is just no fun, especially in the late game when you have all the cash you need but still has to sell stuff after each combat (which can be prolonged if you haven't sold for awhile), otherwise you can't transfer items to the base where your main team is at.
::* Maybe this entire "stores" thing is a plot by the CFN to force X-Com to share its technology with them by forcing X-Com to sell sell sell. It's not like they pay X-Com the real worth of the technology anyway. [[User:Cesium|Cesium]] 23:47, 9 February 2010 (EST)
::: I think a lot of people do find the inventory management tedious, or unrealistically low. Personally I think it's about right for large equipment (missiles, tanks, bodies), but too low for small arms and personal equipment. And yes, it only reflects using the General Stores modules, not storing stuff at random points in the base - maybe fair enough. If the right offset to patch can be found, the storage limits could easily be raised. The last few bytes of [[BASE.DAT]] could be a good place to look for this offset. BASE.DAT can store up to 9,999 units of each item per base. The total limit for items per base would need to be found by experiment, but 9,999 might work for those who want to ignore inventory. For those who feel inventory management is OK but the limits set too tight, the capacity of each General Stores could be increased from 50 to 100 - assuming we can find the offset for this to patch it. [[User:Spike|Spike]] 19:50, 10 February 2010 (EST)
::::Maybe you can try there:
.text:00439C85 66 81 C5 F4 01 add bp, 500
::::[[User:Seb76|Seb76]] 13:03, 11 February 2010 (EST)
::::: Yes that works nicely. E.g. patch '''66 81 C5 E8 03''' at that location and you get 100 space per General Stores. Thanks Seb! [[User:Spike|Spike]] 18:21, 13 February 2010 (EST)
:::::: Now if only I had the offsets or search signature so we can add that as an options --[[User:BladeFireLight|BladeFireLight]] 18:24, 13 February 2010 (EST)
::::::: UFO 1.4 dos: offset 143748. TFTD 2.1 dos: offset 178462. TFTD v1 dos: offset 176861. TFTD CE: offset 252795. UFO CE: offset 236680. (all offsets are in decimal and point to the "F4 01" value to be patched).
::::::: Patching to "E8 03" has been tested on dos versions (not on CE) and it works. The "base information" screen will display the correct value, though the values to line length scale is such that the line will max at 250. [[User:Cesium|Cesium]] 05:57, 14 February 2010 (EST)
::::::::Are the preceding bytes the same from TFTD 1 and 2x? --[[User:BladeFireLight|BladeFireLight]] 17:26, 15 February 2010 (EST)
::::::::: Yes they are. '''81 C3 F4 01''' is the add instruction. [[User:Cesium|Cesium]] 17:48, 15 February 2010 (EST)
::::::::: Sig for UFO Dos is '''81 C6 F4 01''' --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
:::::::::: Do you also have the preceding bytes for UFO? with the signatures I can create a patch file for all versions --[[User:BladeFireLight|BladeFireLight]] 18:51, 15 February 2010 (EST)
::::::::::: I am not sure I understand your question.. Judging the the two UFO versions I have available (1.3 per xcusetup and 1.4) the common preceding bytes are ''80 78 16 07 75 0C 80 78 3A 00 75 06'' (followed by the sig). You could try to use the sig alone - it exists only once in the file. [[User:Cesium|Cesium]] 19:35, 15 February 2010 (EST)
:::::::::::: Offset Locations are something I'm collecting but also the unique series of bytes to find them for the two geoscape/tactical that I dont have. (UFO Spanish, TFTD Italian) I hope to add a lot more options in the in the future. I do feel this one nerfs the storage system anything to get the game up and going faster is always a plus. --[[User:BladeFireLight|BladeFireLight]] 22:01, 15 February 2010 (EST)
::::::::::::: Well, you may want to add another General Stores to the improved starting base if you want to achieve the faster startup effect without "nerfing" storage system for rest of game (I prefer a "nerf" due to late-game reasons). Also, I suggest you add an message in Xcusetup to ask people to get in contact with you if they use an unknown/unrecognized version. [[User:Cesium|Cesium]] 14:27, 16 February 2010 (EST)
::: Inventory management is just as much a pain in the early game, where you almost always are out of space until your 2nd general stores is built. I like realistic constraints, but not tedium. Maybe upping the space per Stores from 50 units to 100 units would be a generally acceptable approach (now that Seb76 has kindly found the offset)? [[User:Spike|Spike]] 04:50, 13 February 2010 (EST)
:::: Yeah, that would be a great improvement. [[User:Cesium|Cesium]] 15:45, 13 February 2010 (EST)

:I can confirm Seb76 is correct, as ever. The 2 bytes at offsets '''0x39c88''' and '''0x39c89''' in geoscape.exe code for the capacity of each General Stores. Default value is 500 ('''F4 01''') which equates to 50 in-game internal capacity units. (Smallest item uses 0.1 in game capacity so I guess that is 1 unit in internal units). I am not sure about a signature. From what I can tell, the preceding bytes '''66 81 C5''' are unique in geoscape.exe, which seems pretty odd, so someone else should verify that. [[User:Spike|Spike]] 19:48, 13 February 2010 (EST)
:: Yes it is unique to CE. it does not exist in any DOS EXE, but "F4 01" can be found in 79 places. Trial and error could locate it. --[[User:BladeFireLight|BladeFireLight]] 20:50, 13 February 2010 (EST)