UFOpaedia - User contributions [en]

Talk:XcomUtil

2010-04-19T01:06:25Z

Wisq: /* Rebalanced X-COM craft */

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

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

==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-04-19T01:03:10Z

Wisq: /* Rebalanced X-COM craft */

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

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

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

==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-04-19T01:01:25Z

Wisq: /* Rebalanced X-COM craft */

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

=== 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 Avengers), 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.

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

==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-04-19T00:58:54Z

Wisq: /* Rebalanced X-COM craft */

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

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

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 Avengers), 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.

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

==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-04-19T00:58:23Z

Wisq: /* Advanced Laser Cannon */ Added section below.

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

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

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 Avengers), 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.

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

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

Wish List (EU)

2010-04-18T21:11:55Z

Wisq: /* Assault Time Limit */

X-Com is a great game and as evidence just look to the fact this wiki exists even though the game pre-dates the internet. In all it's greatness X-Com has some elements and behaviors players wish they could change. This is a repository of those desires. Some day a fan mod may make your wish come true...

= I Wish... =
State what you want AND what X-com does normally. Sign your name if you think "Oh man! That would be great!"

== Geoscape and Strategic ==

=== Smarter Aircraft Movement Around Globe ===
I wish all craft understood the shortest distance between two points on a globe is a curved path towards the poles. Normally a craft goes in the opposite direction than it should (towards the equator). Pain in the ass when the base in the UK sends a craft to Siberia.
--[[User:Brunpal|Brunpal]]

=== Smart Interception ===

Aircraft intercepting a UFO just head straight toward the UFOs current position at all times. Unless the UFO is already on a head-on course, this results in the interceptor travelling through a closing parabolic spiral path, and often missing the UFO and ending up in a tail-chase, and then just falling further behind unless the UFO stops or reverses course. This is pretty basic stuff, fighter pilots have known how to do this better for nearly a hundred years. It is particularly important if the aircraft you are trying to intercept is moving faster than you (eg if you are flying an Interceptor).

What is needed is to plot the UFO's current course and speed (which X-Com has from radar data), and plot an intercept course. The maths for this is pretty easy (the intersection of 2 vectors) and can be implemented in a few lines of code, if we can find out where the current interception algorithm is, and patch it.

Actually the radar bearing shown on screen is only accurate to within 45 degrees. I presume that X-Com does actually know the UFO's bearing, since it can clearly track the UFO's movements. Finding where that variable is located might be different.

While we're at it, it would be nice if the UFO detection information displayed the actual bearing in degrees, rather than just the compass direction (North East, South, etc).

Even if the improved intercept algorithm only used a bearing accurate to within 45 degrees, that would still be better for remote UFOs. You might need to switch to "head straight for it" once you get to very close range. [[User:Spike|Spike]]

===Score for retaliation Battleships===

When a Battleship on retaliation attacks your base and is shot down, you get no score for it. This is completely illogical and it discourages any use of base defences. You should get normal 700 (or even 1400) points for it.
--[[User:Kyrub|Kyrub]] 14:05, 30 August 2008 (PDT)

: I'm not sure about this. Yes it's illogical, but it could also be a licence to get a huge score if you have a strong enough base. [[User:Spike|Spike]] 12:16, 3 September 2008 (PDT)

:: The impenetrable base setup would turn into a cheat. As the aliens will keep hammering the base with a battleship until one breaks through, you'll have a steady supply of points without having to really do anything. Some balancing, such as paying to rearm your defence modules, ought to be thrown in to balance things out. -[[User:NKF|NKF]] 23:13, 13 September 2008 (PDT)
:::A better fix would be to remove the retaliation flag when a battleship is destroyed. If someone can post a savegame with a never-ending flow of base attacks, I may have a look at the fix. [[User:Seb76|Seb76]] 01:05, 15 September 2008 (PDT)

=== All Aircraft Weapons Useful ===

In a balanced game, all weapons should have their uses, or at least a niche, but sadly this is not so:

The Cannon is only useful for shooting down Small Scouts, and even that is practically impossible, due to the difficulty in closing to 10km range with any UFO, particularly the fast-accelerating Small Scout.

The Stingray is not even useful for shooting down Small Scouts (destroys them 57% of the time) and the Avalanche is better in every meaningful way. It also takes twice as long to rearm, making it operationally much worse than the Avalanche.

The Laser Cannon is inferior to the Avalanche for everything. It does have a higher payload but this is hardly relevant. If attacking a UFO that you would struggle to kill with Avalanches, you are unlikely to own an aircraft that will survive long enough to inflict more damage than an Avalanche if it mounted Laser Cannon.

The Fusion Ball Launcher has a [[Talk:Craft_Armaments#Fusion_Balls_better_than_Plasma_Beams.3F¦possible niche]] in fighting Battleships when mounted on Interceptors. Even then, it is difficult and expensive to have aircraft configured to fight only one enemy.

Unfortunately, the optimum path for craft weapon development is all-Avalanche followed by all-Plasma Beam. This is a shame.

Suggestions to 'tune up' the other weapons:

*Cannon - Increase the damage to 20 or 25. So at least there is a pay-off if you manage to get in close.
*Stingray - Double the rearm rate so it can be reloaded as fast as an Avalanche launcher. Increase the ammo capacity to 9 or 12. Then up the rearm rate again (triple or quadruple) so it can still be reloaded as fast as Avalanche. Even then, it's probably not better than the Avalanche, so maybe it make it ''more'' accurate than the Avalanche instead of less. Raise Stingray to 90%, or to 80% but drop Avalanche to 65%.
*Laser Cannon - increase accuracy to 50% and damage to 100. Give it infinite ammunition.
*FBL - increase the ammo from 2 to 3. Increase damage to 250 or even 255. It's far and away the most expensive weapon to operate so it might as well pack the biggest punch.

It might be worth considering 'tune down' the Plasma Beam as well, particularly its stand-off range.
[[User:Spike|Spike]] 06:59, 14 February 2010 (EST)

=== Tougher UFOs ===

==== The Problem ====

So let me get this straight. The first hybrid airborne weapon that humans ever build, and it immediately outclasses every weapon the aliens ever built, including their Battleship weapon? After all the Aliens have only been building plasma weapons for a few million years, us humans have been doing it for ''months''!

More to the point, once you get Plasma Beams, downing UFOs is like shooting fish in a barrel. Even Battleships aren't that exciting if you show up with enough ships.

What is needed is to push up the range, damage, and rate of fire of all the UFO weapons, particularly the UFOs you will be fighting by the time you have plasma beams. At a minimum, the weapon on a Battleship should be at least as powerful as, say, 2 Plasma Beams (as found on the XCom craft it is fighting)? Instead of slightly less than half as powerful? Compared to a single Plasma Beam, only the Battleship weapon has better range. It has double the accuracy, slightly higher damage, but half the fire rate. Net 5.7% more firepower than one Plasma Beam, but no match for 2. And the Battleship weapon of course is the most powerful in the alien arsenal.

Possible tune ups for UFOs:

*Battleship - increase to 255 weapon power, improve reload rate to 12 (from 24). Now roughly equivalent to 4 Plasma Beams in total firepower (on Beginner difficulty). Increase range to 69km, so that the Battleship commences fire as soon as an XCom craft begins its attack run. Or better, increase range to 70+km, the limit of the interception window, so that the Battleship starts firing immediately the XCom craft enters air combat range. This would disrupt XCom aircrafts' ability to form up into a flight of 4, prior to commencing their attack. Overall, this would make it much harder to down Battleships. Increasing weapon range to 70+km would also make it much harder to tail a Battleship - manual control in the Geoscape would be needed to hold off outside of combat range. Really, the Battleship should not sit there like a sitting duck. Does it think XCom are friendly?
*Terror Ship - increase range to 52 (or decrease Plasma Beam range to 42), so stand-off kills are not possible with Plasma Beams?
*Actually maybe all the larger UFOs should have weapon range 69-70+km, so they behave very aggressively toward XCom craft.

NB: Strange effects occur if weapon range goes over 70km so it's probably best to leave it at 70km rather than 75km.

NB: Also, changes to rate of fire need to be looked at carefully though because Difficulty Level also reduces reload rate for UFOs. Between Beginner (Difficulty 0) and Superhuman (Difficulty 4), rate of fire (and thus firepower) for Battleships, Terror Ships and Supply Ships increases by 24/(24-4x2=16) or 50%. But if the base reload rate for these weapons was reduced to 12, the transition from Beginner to Advanced would increase firepower '''three''' times for these 3 UFOs (less so for the smaller UFOs). It is less risky to increase the weapon power. Unfortunately there are only 2 firepower variables to play with - damage and reload rate - so there are not a lot of options, especially for the Battleship which already has weapon strength 148 out of a probable maximum of 255.

:More detail on this. For Medium Scout, Large Scout and Abductor, with nominal reload rate 48gs, the rate of fire improves +20% between Beginner and Superhuman. For Harvester (32gs) it improves one third. For Large UFOs (Terror Ship, Supply Ship, Battleship - 24gs) the improvement is +50%. [[User:Spike|Spike]] 20:28, 14 February 2010 (EST)

I think we should assume that the Battleship, which is bigger than the entire XCom base, is engaging XCom craft with its secondary weapons rather than its main armament, which could probably destroy Manhattan with a glancing hit.

I would really like to see the hypothetical Mega-Battleship go up against XCom's finest - a flight of 4 Avengers armed with dual Plasma Cannon or dual Fusion Ball Launchers. With the Battleship having 70+km range, 255 weapon power, and an effective fire rate on Superhuman triple that of the PB, it would have the firepower of 11 Plasma Beams - 36% more firepower than the whole attacking XCom force combined. To be honest I think that would be carnage, not sure XCom could win. So that would be tuning the Battleship up too much. The 3-fold increase in rate of fire when on Superhuman is just too much. Maybe just max out the damage to 255 and range to 75. This gives a 72% increase in firepower, and a challenging tactical problem for XCom (forming up and approaching under fire).

The smaller UFOs can probably stay as they are. It is not until later in the game that XCom advances so that even large UFOs are easy pickings. What is the crossover point? Maybe the medium UFOs. So it might be good to reduce the reload times of the medium UFOs from 48 / 32 to 24, a good increase in firepower.

In general I think all UFOs energy weapons should have at least as good range as the XCom energy weapons, even the Medium Scout. Again, they have been using these weapons for millions of years and we only just figured out how to copy them from the aliens, how could our weapons be better than the aliens? How did our first plasma weapon out-range and out-perform all but the hugest UFO plasma beam? And on an airframe the size of a Small Scout we mount ''two'' such weapons? On the battlefield we only are able to replicate alien weapons; how is it that in the air we are able to improve on them ''masssively''?

Perhaps there should never be a stand-off advantage, except possibly with missiles -which should be less accurate with longer range. The XCom stand off advantage is really unfair because as far as I have seen the UFOs never attempt to close to effective range, even when they are getting killed. They don't break off much, either, though I think I have seen that happen on occasion.

==== Specific Proposals ====

===== No Standoff Beam Attacks =====

Increase ''all'' UFO plasma weapon ranges to at least 55km (compared to 52km for the XCom plasma weapon). Now only launched XCom weapons (Avalanche and Fusion Ball) have standoff advantage. Probably also reduce the accuracy of the Avalanche to 60% and buff Stingray accuracy to 80%, providing both weapons with a useful niche role.

===== No Standoff Attacks =====

Increase ''all'' UFO plasma weapon ranges to 66km (compared to 52km for the XCom plasma weapon). Now ''no'' XCom weapon has standoff advantage. (The benefit of a longer range weapon is simply spending less time being fired on by the UFO.)

===== Twitchy Aliens =====

Increase all UFO ranges to 69km. They will attack as soon as XCom aircraft commence any attack run.

===== Hostile Aliens =====

Increase all UFO ranges to 70km. They will attack as soon as XCom aircraft enter intercept range. UFOs now fire first, and tailing them unchallenged is impossible.

===== Improved Medium UFOs =====

Reduce (improve) the nominal reload time of Medium UFOs, Abductors and Harvesters, from 48gs and 32gs to 24gs. This increases the challenge in the early-mid game, when XCom might first be deploying advanced weapons.

===== Improved Battleships =====

Increase damage to 255. They're firing (bigger) Fusion Balls! A Battleship now has the same firepower as one XCom Craft with dual Plasma Beams (gosh wow!). It's a start, but what if we...

===== Super Battleships =====

... also reduce nominal reload time to 18gs. Giving a further one-third extra firepower on Beginner, 60% more on Superhuman.

===== Mega Battleships =====

... or for a real challenge, reduce reload time to 12gs. A further doubling of the firepower on Beginner - a further ''four'' times increase on Superhuman. Now Superhuman Battleships out-gun the biggest fleet XCom can throw at them!

[[User:Spike|Spike]] 00:25, 19 February 2010 (EST)

===Enforced Variant Games===

Various people like to play various variant games, such as No Alien Technology, or No Detection, or No Lethal Weapons - see for example Scott Jones' notes to XComUtil. It would be nice to have options on the game executable to enforce these scenarios. Self restraint is hard! [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

Some of these variant scenarios have been implemented by [[User:Seb76#Mods|Seb76]].

===Recruit Certain Alien Types===

Consider that not all aliens are loyal to their master (most TFTD alien has a device lodged to its brain), it would be interesting (or at least cool) if we could recuit such aliens to the XCOM cause. Maybe we can remove the controling devices from captive aliens after research on that species. Or convince the head of the Snakemen that it would be far more benefit to his race to help us instead of the Ethereals [[User:L-Zwei|L-Zwei]] 23:25, 12 September 2008 (PDT).

Only certain alien types should be recruitable. Ones that should NOT be include Mutons (as they are directly controlled by Ethereals), Chrysallids (unbalancing), etc. It would be nice to be able to reverse-engineer Cyberdiscs or Sectopods, or make it that a Cyberdisc must be researched to build hovertanks/etc.
[[User:MagicJuggler|MagicJuggler]] 13:32, 18 September 2008 (PDT)
: It's pretty obvious which ones should be recruitable: non-robotic terror units that are captured alive. Chryssalids should simply do melee damage instead of impregnating (as the resulting spawn would not be mind-controlled and therefore XCOM wouldn't do it). Silacoids would be pretty ineffectual, and reapers slightly less so, but both would be disposable scouts. Celatids might actually have some use (eating through hulls with acid, and arcing over walls) but are fragile. All of these would require capturing a terror alien alive after researching Psi Amp. The two robotic units should require a live alien Engineer researched as well as UFO Construction, and the materials for building one would be one corpse of the appropriate type, Alien alloys and Elerium (to repair and refuel the husk). The Sectopod should probably be nerfed somewhat, so that it isn't quite so invincible to Heavy Plasma shots - after all, it was probably a twisted and melted modern art piece by the time it finally went down). [[User:Stubbs|Stubbs]]

=== Game option: sell only researched items ===

The fact that you may sell the alien items for the best price once you get them, without any research, is illogical. Such staff would never get on the market, being top secret and potentially dangerous to the humanity.

Selling without proper research does not help the replay value of the game either: once you know the "right path" to get the best items, you simply sell anything else immediately and ignore the unnecessary research. Too easy.

Therefore I wish for this game option: unknown items are sold for 0 (including the alien corpses), the known ones for their full price. This makes the sustainable economics much harder to develop and it gives sense to the "useless" research. Last but not least, it adds a lot of depth to the gameplay: will you choose research of a new weapon you need on the field, or of a mind probe that will earn you millions in sales? --[[User:Kyrub|Kyrub]] 15:55, 6 April 2009 (EDT)

: I really like this option, it's a great idea. Makes the game harder and makes it more interesting, more varied. Gives extra value to the otherwise "useless" research paths. Good thinking! [[User:Spike|Spike]] 15:06, 24 August 2009 (EDT)

: I'd prefer that unresearched artifacts/corpses sold for a fraction of their original value (no more than 25%). It makes no sense that nobody would pay to research them for themselves. Additionally, Laser Cannon sell price needs to be nerfed. [[User:Stubbs|Stubbs]]

=== New Research Mechanics ===

The above comments spurred some ideas to make the research more realistic and the path to victory less obvious.

For flavor reasons, give research options vague names instead of exact names. This already exists in some research topics, such as "New Fighter Craft" instead of "Firestorm". So, research topics might read "Alien Hovertank Wreck" instead of "Cyberdisc Corpse", "Grey Alien Corpse" instead of "Sectoid Corpse" or "Alien Pistol" instead of "Plasma Pistol". The names would be revealed in the UFOpaedia entry, and certain items would then be renamed as per common sense.

Hide the ranks of aliens in captivity until they are researched (so you'd see Live Grey Alien #1, Live Grey Alien #2 if you had two Sectoids available for research). However, if you happened to have two Soldier ranks in containment, you'd only see one topic. The same rank/race combination would never appear again, but you might have to research several specimens of the same species to get the useful one you want. The alternative would be to have researched Mind Probe, which would tell you exactly what you had in containment (just as it does on the battlefield).

Once an alien or its corpse is researched, then all other instances of that alien or its body are renamed appropriately. For example, research a live Muton and Muton corpses become obvious, and vice versa. "Live Green Humanoid Alien" is also renamed to "Live Muton".

Finally, there should be a few more prerequisites in place to make less useful research more necessary. As someone else has mentioned, you should need a Cyberdisc Corpse to research Hovertanks. I'd also suggest that Psi Amp and Mind Shield require the research of Mind Probe (seeing as both entail scanning for minds as a logical first step), and that Flying Suits require Floater Corpse, Cyberdisc Corpse or a live Floater researched as an additional prerequisite (not Ethereals, as they fly with the power of their huge brains). [[User:Stubbs|Stubbs]]

:These are all good suggestions and make a lot of sense. An alternative explanation of the names (seen in some fan fiction) is that these names are not the real names, but are made up by XCom troops based on some limited battlefield experience of them. But revealing the "real" alien race names through Research is a fun idea. [[User:Spike|Spike]] 08:44, 1 September 2009 (EDT)

== Battlescape and Tactical ==

===Equipment Management===

All wishes are currently implemented!

===Fog of War Improvements===

I'm sure most of these would be an absolute PAIN to implement, but I figured I'd toss the ideas out here.

====Prior Recon of Battlefield====
One thing that has always irked me is X-COM has no terrain knowledge when it lands, despite having probably circled the place two or three times before landing and thus they should know at least some of the area. This would be nice, but isn't too important. Probably would be a pain to implement so X-COM would have all knowledge of external features but no knowledge of building interiors, anyways. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)

:Yes at the very least, when you splash the UFO, it could tell you (via some miracle technology such as "satellite reconnaisance") what the terrain type is of the landing zone area. Then you could adjust equipment accordingly. And adjust your uniform camouflage (if using one of the uniform mods). [[User:Spike|Spike]] 12:16, 3 September 2008 (PDT)

:: Geoscape: center on the site, then maximum zoom. Aside from having to disambiguate forest from jungle, this works fine for knowing the exact terrain you're getting into. -- [[User:Zaimoni|Zaimoni]] 10:17, 4 Sept 2008 (CDT)

:::This is already present in the game. To center the Geoscape on a specific location, right-click on the target spot. To do maximum zoom in, right click on the Zoom-In button(and the same works for Zoom-Out). Also, Jungle and Forest use the same display algorithm, but are easy to differentiate; Forest occurs NORTH of the equator, and Jungle occurs SOUTH. [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:23, 4 September 2008 (PDT)

:Returning to AQ's original suggestion, it wouldn't be too hard would it for the dropship to "radar map" the target, and then have the basic map show up on your scanner on Turn 1? [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)

====Dynamic Fog====

The Fog of War in X-COM is clumsily implemented, compared to modern expectations. Everything starts out black, but after exploring, is shown...and it's kept in the same showing, regardless of whether you actually have LoS to that area anymore. It would be nice if when you no longer had Line of Sight to a particular map area, it would be cloaked in a way so that you knew the terrain, but not the units there. Since I've sometimes spent over half an hour trying to hunt down that last alien hiding in area I'd already explored. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)

====Deactivate Object Radar====

Currently, in X-COM, any objects dropped in a given square show on your Battlescape, regardless of whether you have Line of Sight to the square or not. In regards to dropped weapons/grenades/equipment/dead soldiers/dead aliens, this doesn't make a large difference. But in the case of STUNNED aliens, a quick scan across the Battlescape can tell you whether the alien you stunned 10 turns ago is still down, or stood back up(the stunned alien object will disappear from the stack). Of course, since aliens which have revived from stun are almost always disarmed(and the ones that aren't probably should've been killed instead), the usefulness of this 'exploit' is reduced mainly to finding out that the last alien you're looking for is just wandering aimlessly and unarmed. Perhaps leave stacks showing the same until you regain LoS to that area? [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)

===Restore Game from Battlescape===

It would be nice to be able to reload a saved game directly from the Battlescape "?" screen, rather than having to go through the process of Abandoning to the Geoscape. Would you need to check it was a Battlescape save and not a Geoscape save? Maybe, maybe not. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Warm Grenades===

Currently when you set the timer on a grenade (or HE pack), the timer runs down every turn regardless of whether the grenade is worn, held, or dropped. Then, when the timer runs out, it explodes unless it is held or worn. There is no real grenade or explosive that works this way. Once the timer (fuse) starts running, they explode regardless. However for most hand grenades, the timer (fuse) doesn't start until after you throw/drop the grenade. It would be nice to have both of these real world behaviours, and lose the game's default behaviour. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

: Technically the way the game implements grenades, they don't have a timer. At least, not as such. When you set a grenade, the game just assigns it a turn to blow up on. Once the turn has passed, the game checks to see that it's on the ground and blows it up if it is, otherwise it doesn't. I believe Seb76 has already addressed this in his patches where there's an option to make grenade blow up regardless whether they are in inventory or otherwise the moment the timer is set. X-Com Apocalypse does a good job of this. The moment the grenade is so much as moved after the timer is set, it counts down. - [[User:NKF|NKF]] 23:01, 13 September 2008 (PDT)

:: To simulate an actual timer, you would need to do something like: Every turn that a primed grenade is being held by a unit during the "explode" check, increment by +1 the turn when that grenade is going to explode. [[User:Spike|Spike]] 19:10, 14 September 2008 (PDT)
:::I think I would change quantity2 ([[OBPOS.DAT]]) to a countdown instead of a turn, and use quantity3 as a flag indicating if the count has started. This flag is set any time a turn ends and the grenade has no owner. Taking it back in your hand once the timer has started won't help and the thing must be thrown... quantity2 is decreased if quantity3 is set, and the grenade blows up as usual. [[User:Seb76|Seb76]] 01:35, 15 September 2008 (PDT)

: That would be great. It would be exactly consistent with a 'spoon' type hand grenade. The timer only starts when you release the grenade, but after that it explodes at a definite time regardless of whether you pick it up or not. [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)

===Stun Grenades===

I want flashbangs.--[[User:Brunpal|Brunpal]] 22:59, 11 September 2008 (PDT)
:Instead of stunning, I'd see more effect if it would remove some TUs to units having line of sight (to be fare it should affect xcom units too). It would help against reaction fire (which is the point of flashbangs). Given that grenades detonate at the end turns, it would require a good coordination to have the grenade detonate exactly at the end of the alien turn, and just before your attack. Being able to open doors à la xcom2 would also help to throw flashbangs just before a craft assault... [[User:Seb76|Seb76]] 22:03, 12 September 2008 (PDT)
::That would be good. Hard to program, potentially extremely unbalancing, but good. I considered a "debuff" kind of ability (as you suggest) for flashbangs, vs the more obvious substitution of [[stun]] for [[Explosions|HE]] damage. In the end, I picked "I want flashbangs."--[[User:Brunpal|Brunpal]] 03:32, 13 September 2008 (PDT)
: Maybe flashbangs dont' work on Aliens - otherwise, XCom would use them, right? :) But seriously, I too would like flashbangs, and stun grenades / concussion grenades. Both of these would make the game easier, though. With flashbangs, you might have to compensate by just giving the aliens more TUs. [[User:Spike|Spike]] 13:33, 13 September 2008 (PDT)
::More options for the player is going to make it easier for any kind of game. Particularly of games like XCOM where the computer can't take advantage of the changes. However I don't believe a weak stun grenade (like 44 stun damage, comparable to AC-HE) would change the game much because the 80 item limit remains.--[[User:Brunpal|Brunpal]] 22:21, 13 September 2008 (PDT)

===Night Vision===

I '''don't''' want to add night vision equipment to the game. I assume that either (1) all XCom units already have night vision gear as standard, but it's not as good as alien night vision, and the visibility that XCom units have at night is based on their standard-issue night vision gear, or (2) night vision gear does not work on Aliens. Either they do not appear on night vision, or maybe worse - maybe the aliens can manipulate night vision equipment, causing worse than normal vision, or hallucinations, and even tricking XCom units into firing on each other. [[User:Spike|Spike]] 13:33, 13 September 2008 (PDT)

===Throwing over stuff===
'''(Moved to Talk, as this is not a bug and so does not need fixing.)'''

===Assault Time Limit===

One of the cool things about UFO Defence is there are no time limits on the scenarios. This is great as it allows for a totally different kind of tactics and much more flexibility.
It's more of a "thinking man's game" as a result. But... arguably this is not very realistic for UFO Assault missions. If the Aliens are getting creamed, they should try to make a getaway if they can (just like XCom would). A simple way to implement this would be a hard time limit (say 20 turns?) on a UFO Assault. Another way would be to base it on Alien Morale. At a certain Morale level the aliens decide to dust off. Give the player say 3 turns warning while they rev up the engines. Then if there is still a Navigator or Engineer in the Control Room alive, the ship takes off. Any XCom troops still aboard are MIA.

You might run into problems if the UFO took off but then landed again or was shot down, generating another ground mission with potentially '''more''' Aliens than were still alive at the end of the Assault. (Still, maybe they hatch some more clones if they get time to....) [[User:Spike|Spike]] 09:51, 4 September 2008 (PDT)

: It strikes me as justified they don't do that. Troops loose in the vessel could be seriously bad. It would be nice if they dusted off on the condition that their morale was low enough or 3 X-com soldiers had the door in their sights without aliens alive outside in the latter case and no X-com soldiers on board in either case. also, if the UFO has a hole in either the command or engine room, it would have to set down before leaving the atmosphere. [[User:(name here)|(name here)]]

Taking off with troops onboard would be perfectly safe (for the aliens) and justifiable if one assumes that alien ships in flight are inherently inhospitable for humans. This is easily done by saying that they undergo accelerations that humans can't withstand (splat), can't withstand for any length of time (pass out), or that they intentionally make rapid accelerations in different directions, either normally or just if they're trying to bash some intruders around. Naturally, the aliens themselves would either be immune to these (tough physique / their built-in antigrav devices?), or be in acceleration chairs, safe from all this.

Alternatively, when you get the warning that the UFO is going to take off, you've got a certain amount of time to either get everyone '''off''' the UFO, or to get everyone '''on''' it (or as many as you can). There could be a follow-up mission that takes place in "sky" terrain, where the outdoors is either impassable (the easy way) or else instantly withdraws units from combat (flying suits / parachutes). The soldiers' goals would be to either take out the aliens and presumably safely land and salvage the UFO, or take out the UFO's means of flying (power cores / navigator?). In the latter case, they might have a certain number of turns to withdraw or be caught in the crash, with possible casualties just like the aliens, mitigated to some degree by their armour and maybe where inside the UFO they are.

In the case of a crash, there could be a final mission to finish off the surviving aliens, using the X-COM soldiers that survive the crash, and no landing craft (it's still back at the old landing site). Alternatively, you could say that there '''is''' an X-COM landing craft parked outside (with all remaining members of the original landing party), since the in-flight time / distance was presumably low and the original X-COM craft quickly packed up and flew to the new landing site. — [[User:Wisq|Wisq]] 17:11, 18 April 2010 (EDT)

===Alien AI===

====Attempts to rearm====
Aliens cannot pick up items, but I wish they would. If an alien has no useful weapons in inventory they should either head for cover or head for a plasma weapon. Panicked aliens drop their weapons but never seem to pick them up when they managed to pull themselves together. It would be nice if they tried to arm themselves again. --[[User:Brunpal|Brunpal]] 13:55, 19 September 2008 (PDT)

:Even if it's too hard to make aliens head towards weapons (is it safe?, could it be used to trap them, not to mention the complexities of route finding) - it would still be good if an unarmed alien checked for usable weapons in every square it moved through, and at least picked up one loaded weapon or grenade per turn. [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)

Fixing the AI for this could be really hard. Apart from all the possible exploits by XCom, the AI is probably a really hard part of the game to reverse engineer. You could say that an unarmed alien is no threat anyway (we are only concerned about aliens without psi or built in weapons). So nothing is lost even with an exploitable method of re-arming. By exploitable I mean the XCom player can manipulate re-arming, e.g. by leaving weapons out in the open as bait for traps.

Maybe the simplest modification would be to ''not'' drop weapons when the alien panics? This does not require delving in to the AI, just intercepting the panic effects. Dont make aliens drop any weapons when they panic. It would be reasonable to return the weapon in hand to inventory, so there is a TU cost for the alien to bring the weapon back into play again.

This would not work for aliens who were stunned and wake up, or who were mind controlled by XCom and made to drop their weapons. But it would probably catch 80% of cases.

Another cheat, short of fixing the AI, is just to pick up weapons that the alien walks over. It could also pick up "spare" weapons from adjacent aliens (cheating on TUs - basically just teleporting the items to the unarmed alien). Spare alien weapons are almost invariably grenades. I have not had a lot of success in getting unarmed aliens to use grenades, so more research is needed here. Maybe only certain types of aliens use grenades, or only in certain circumstances?

Really, really cheating would be to teleport any weapon laying around the battlefield into the alien's inventory. But I think it is more fair just to say panicked aliens dont drop their equipment. [[User:Spike|Spike]] 16:13, 13 February 2010 (EST)

==== End Psi Bullying and Psi Baiting ====
When the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength?

: Not a bad idea to randomise this a bit, because while initially this tactic helps the aliens, it becomes so predictable that it can be used against them by deploying unarmed "Psi Bait" soldiers to draw off all the attacks. (Or make aliens avoid controlling/panicking soldiers who have no loaded weapons. But then folks would just give them pea shooters and wear armour.) [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)

=== 80 Item Limit on Base Defense Mission ===
: Well you get the 80 item limit on every mission, but it hurts more on a Base Defence as you have more limited ability, or sometimes no ability, to manage what goes into those 80 items. I was thinking about a couple of (theoretical) ways to fix this and I hit on a new one (new for me anyway): Why not take the 80 items from the Transport(s), first Transport then second Transport until you run out of items or hit 80. This has a few benefits:
:* Ready made interface to manage the 80-item limit, the Stores <> Craft (Equip Craft) Screen.
:* If you have no warning at all, the 80 items will probably make good tactical sense in general terms, even if they are are not totally optimised for Base Defence (no proximity mines, etc).
: I think that copying the Transport inventory into the Battlescape inventory would be relatively to implement (though what do I know?). As a simplification, you could move only the inventory in the ''first available'' Transport that is present in the Base, into the Battlescape, and not bother looking in more than one place (other Transports, Base Stores) to get up to 80. It would then be a bit of a drag if your Transports are all out on a mission when your Base gets attacked though. Or perhaps inspect the inventory of Transport 1 (wherever it is in the world), and then attempt to copy its inventory, using equipment present in the Base?
: Another way of doing it which has been mentioned elsewhere is to try to reverse the order of the items in the Stores list. This has the effect of putting the more advanced weapons first, rather than the more basic weapons. There could be all kinds of unwanted side effects of this, depending on various programming issues.
: Actually there is already a fix for the 80-item limit in XComUtil. XComUtil records a standard assign weapon set for each of your troops, and then teleports those weapons to the Battlescape from your Base Stores, regardless of the 80-item limit (but still subject to the Battlescape's 170-item limit). Not 100% sure if this works for Base Defence missions though.
:[[User:Spike|Spike]] 13:22, 24 November 2008 (CST)

=== Collision Detection Bugs ===
I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof!

=== Base Defence Systems Cause Alien Casualties ===

I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round).

: The general view is probably that Base Defence missions are a boon to XCOM already, so why make them any easier. At very least there would need to be more damage to the loot than there was to the Alien's combat effectiveness, otherwise this unbalances the game in favour of XCOM. [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)

=== Alien vs Alien ===
This one is way out there. Alien v Alien battles out with main game, just random battlescape maps. Sectoid and their terrorists against Floaters and theirs etc. One side human controlled the other computer. Choice of ships involved etc.

:I actually love this idea. It might just about be possible using XComUtil, if someone is a total XComUtil guru.

----

There was a utility to do this from Devisraad. it has long since been removed from his site, but someone may still have it. The basics was you renamed unit and it automatically replaced graphics flag to swap out the units. Didn't work on the Large Aliens but still was a fun mod --[[User:BladeFireLight|BladeFireLight]] 02:20, 6 January 2010 (EST)

=== Aircraft in Base Defence Battlescape ===

New graphics for the Interceptor and Firestorm on the battlescape. All your ships could remain in their hangers when the aliens attack your base. Don’t understand why Mythos did not do this originally.

----

Simply for one reason: the limit on the size of the battlescape. UFO maps are usually limited to 10000 tiles (50x50x4), on Bases you have 9600 (60x60x3), the last level one being dirt. You need 3 levels to display X-COM craft. [[User:Hobbes|Hobbes]] 14:28, 23 September 2008 (PDT)

----

Could you not do it but clip off the top level of the craft - leaving the ground level and 'deck' level? It would be a cool terrain area to fight in. I like the fact that in TFTD you can still see your subs during a base defence. [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)

----

It is possible to edit the map files to include the Skyranger, but you'll have to use Xcomutil to play with that terrain and I think it would never launch during base defense missions (but I'm not sure on that - never tried editing the X-COM base terrain). [[User:Hobbes|Hobbes]] 19:25, 4 December 2009 (EST)

----

This could be done by creating new "hangar" map modules, each containing one of the five possible X-COM craft. Bung the modules into [[GEODATA.DAT]] at index 0C, and you're done. The catch is you can't have all craft or the MCD array will overflow. The base terrain uses ~160 tiles as it is (out of the max of 256), while the craft use about 60 each (on average). Putting them all in would take the table above 300 entries (that is to say, the game'd crash).

'Cause XcomUtil already provides us with an Intercepter design made up of SkyRanger parts, I suppose the way to go would be to only implement those two craft. If you have any alien technology ships, they could either be left out ("they were fast enough to escape") or rendered as SkyRangers.

It should also be noted that bases are made up of two levels, not three. Luckily, all the craft are only three levels high, so cutting out the landing gear still works. - [[User:Bomb Bloke|Bomb Bloke]] 19:56, 4 December 2009 (EST)

----

Very true about the MCD limit, that's why I only mentioned the Skyranger but the Interceptor could be added as well (and would not make much sense to have your first defense mission with a nice Avenger parked on the hangar while your Interceptors are being blow to bits by Battleships). The bases are 3 levels but you can only modify two of them. The game engine automatically adds a layer of 'dirt modules' either at top or bottom. Hmmm, this just gave me an idea for the wish list... [[User:Hobbes|Hobbes]] 20:29, 4 December 2009 (EST)

----

Both alien and X-Com bases ''are'' only two levels. There must be something screwy in your game; XcomUtil maybe?

It occurs to me that removing landing gear and stuff might make it ''just'' possible to jam in the Lightning tiles as well (as the MCD requirements would also shrink slightly). That'd make it possible to add the Firestorm, too. Seems a shame to get that far then leave out the Avenger, though...

- [[User:Bomb Bloke|Bomb Bloke]] 21:30, 4 December 2009 (EST)

----

Nevermind, I completely misread your previous post. Yes, they are two levels only, could be Xcomutil that adds the 3rd level.

- [[User:Hobbes|Hobbes]] 22:30, 4 December 2009 (EST)

----
You may be able to get 3 levels in an X-Com Base but not 4. EU has a smaller amount of memory alocated. I dont know the limit but 60x60x4 will crash EU. TFTD has no problem --[[User:BladeFireLight|BladeFireLight]] 02:25, 6 January 2010 (EST)

----

I got partway through this and then decided to change my methods entirely and start from scratch. So I thought I might as well post my progress anyways, as it's already about on par with the crude TFTD implementation: You always have the same craft appear in your hanger regardless of what is (or isn't!) there.

[[Image:Skyranger In Hanger.rar]]

- [[User:Bomb Bloke|Bomb Bloke]] 05:40, 17 December 2009 (EST)

----

Hey BB, a while ago I have modded the plane terrain files so that the Skyranger appears facing east instead of south. If you want to use that one (to make it a little different) let me know. [[User:Hobbes|Hobbes]] 08:23, 17 December 2009 (EST)

----

Thanks, but don't worry about it for now: it'll make the MCD arrays larger still, so I'll consider it when I get all the other stuff done.

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

----

The completed mod is now included in my toolpack. As usual, I've only done cursory testing on it, but I'm pretty sure it's stable enough.

- [[User:Bomb Bloke|Bomb Bloke]] 06:40, 20 January 2010 (EST)

=== Fixed firing TUs ===

Something that always bugged me was how the weapons used percentages for firing TUs. It doesn't make sense that the faster a soldier got, the longer it would take to fire a weapon.
: This is because you can't fire an automatic weapon any faster than it will shoot. However, it otherwise makes minimal sense, as you point out. I suggest two alternative solutions. Firstly, that only automatic fire modes use a fixed percentage of a soldier's time units, and other modes use a fixed number of TUs. This would entail the newer soldiers spraying and your most elite taking fast, selective single shots. The alternative is that each firing mode for each weapon entails its own formula (revealed in the UFOpaedia but essentially hidden during the battlescape) along the lines of "X% of TUs + Y TUs". Snap fire would be a low % of total plus a low fixed cost, Aimed would be a low % of total with a high fixed cost, and Auto would be a high % of total with a low fixed cost. While this is somewhat complex, in-game you wouldn't have to worry, and it accounts for what can be reduced (i.e. aiming speed) and what can never be improved by a soldier (i.e. cyclic rate of fire or time for a missile to lock). [[User:Stubbs|Stubbs]]
:: These observations are very sensible. However we also need to consider the impact on game balance. If you implement this in an even-handed way, alien rates of fire will increase as they have high TUs. Or, if you fudge it so that alien rates of fire remain the same, then X-Com's advantage will increase as the game progresses. Neither of these are desirable. It would be extremely hard to implement this and still maintain game balance. [[User:Spike|Spike]] 08:41, 1 September 2009 (EDT)
:::Each turn has the exact same duration, but is divided into TUs separately for each soldier. That's a simplification that works well in a turn-based game and reflects the fact that a soldier is fast or slow. However, weapons need to be aimed and will not fire faster than normal, thus they require a fixed percentage of the turn duration. In other words, soldiers gain movement speed, but fire at the same rate. This is both desirable and logical, just not self-explanatory. Thus, I would definitely stick to how TUs consumption is solved currently. [[User:mingos|mingos]]

=== In-flight Interception ===

Yes, I know that this idea is nigh-impossible, but I was thinking, wouldn't it be awesome to infiltrate a battleship, kill the aliens inside and escape, with the geoscape being shown zooming past underneath? Also, in a similar vein to the "aliens dust off after 3 turns" idea, after killing the aliens ( or blowing up the power cores, maybe?)you would have to get as many troops as possible to the drop ship in 3 turns(in retrospect I guess that you could only do this with the Lightning because of the doors) or the ship crashes and all troops not in the dropship are missing in action. Yes, this idea is impractical and would be really hard to program, but the idea of blowing a UFO up from the inside just seems epic to me. [[User:WolfenMage|WolfenMage]]

== Miscellaneous ==

===Fix All Bugs===

Oh no [[User:Seb76#Bug Fixes|Seb76]] already did this! :) [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

= I Wished (And My Wish Came True)... =

== Geoscape and Strategic ==

=== Fuel Ready always ===
[[User:Seb76#Mods|Implemented - here]]

I wish that I could send out craft at any fuel or ammo level. Normally craft can only leave a base if fully "ready". Craft is only "ready" at 100% fuel (or 0% fuel using an exploit) but there's no logical reason why a full tank and full ammo is required. Fully repaired... that's fine. I can live with pilots refusing to fly a plane missing a wing even if it means England is lost to aliens. 15 hours to fill a tank? Retarded but I can live with that too if I can send out a craft at 20% fuel.
--[[User:Brunpal|Brunpal]]

:Actually, many modern aircraft '''do''' require the fuel tanks to be full on takeoff, and fairly empty on landing. The weight of the fuel is figured into the takeoff aerodynamics, and the tank being full prevents fuel 'sloshing' in the tanks and not actually making it to the engine. (Conversely, many aircraft need to have dispensed of much of that fuel weight before landing.) This holds for most runway-takeoff craft, but may not apply to anything with VTOL capacity; I'm unsure there.

:I do agree that non-full weapons aren't as critical, though. But from a logical standpoint, most modern aircraft should not be launched on an empty fuel tank. I also should noted that an Elerium-fueled craft with [[Known_Bugs#Elerium-fueled_Craft_Bug|50% fuel or less remaining]] will automatically return to base, regardless of distance from base. Of course, given that such craft fuel up quickly, its less of an issue there. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:05, 7 August 2008 (PDT)

:Hum, maybe you can try [[User:Seb76#Mods|this]]? [[User:Seb76|Seb76]] 13:01, 8 August 2008 (PDT)
::Thanks! But I can't try it. I've not been able to get my copy of Xcom to run properly except on a Win98 install. VC2008 requires a more modern OS. I'm sure I could ''eventually'' figure out a way to get it running, but I tried once and wasted too much time before giving up.--[[User:Brunpal|Brunpal]] 14:45, 8 August 2008 (PDT)
:AFAIK VC2008 binaries should run OK on Win98 as long as the runtime is deployed. Anyway, the loader uses CreateRemoteThread API which is not available in Win98 so don't even bother. '''However''', you can manually patch the binary if you want ;-) Data to patch (all in hexadecimal):
offset 0x41752: 2A0075 -> 18207C
:HTH. [[User:Seb76|Seb76]] 14:56, 8 August 2008 (PDT)

===Base Build Stacking===
[[User:Seb76#Base Building Stacking|Implemented - here]]

At the moment you are only allowed to build next to a finished module, and you aren't allowed to plan ahead in your base construction. It would be nice to at least be able to plan more than one phase of construction in advance. This would be pretty easy to implement. There is no need to code any new "queuing system". Just place the new module next to an existing under-construction module, but increment the build time to the normal build time + the time remaining on the under-construction module (the lowest time remaining that would make the square you are building in, a legal square to build in). As a premium for build stacking, you have to pay the costs up-front. As with normal construction, all costs are non-refundable if you change your mind. (There would probably need to be some on-screen feedback for how long the module would take to build, before you were committed to building it.) [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

See also: Discussion on [[Talk:Wish List|Talk page]].

== Battlescape and Tactical ==

=== Equipment Management ===

==== Soldiers remembers THEIR equipment ====
[[XcomUtil|Implemented - here]]

I wish soldiers remembered what equipment they LAST used and start with that gear when they land. Normally soldiers grab various gear and put lots of crap on their belt. I put most things on the shoulder slots, and keep many things spare things on the ship just in case I need them. (I only want IN rounds if it's night. Stop picking them up before I shoot you in the back!) Takes forever to sort out the gear so the weakling isn't carrying all the rockets etc.
--[[User:Brunpal|Brunpal]]

:This is already available in [[XcomUtil]]. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:07, 7 August 2008 (PDT)

====Access to Stats screens during equipment allocation====
[[User:Seb76#Equipment Screen|Mostly implemented - here]]

In Battlescape you can get to Stats screens by right clicking on one of the unit's status bars. However you can't do this in the Equipment screen. Things like Statstrings and (even more so) [[User:Seb76|Seb76]]'s modified Equipment screen with actual/max weight help. But it would be nice to be able to see exact stats. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Decrease Accuracy for targets out of sight===
[[User:Seb76#Range_Based_Accuracy|Brilliantly implemented - here]]

How come you can easily shoot on something you do not see?
I find the over-used scout-sniper tactic is a cheap exploit of the X-COM. The tactical game should describe a combat, not a cowardly shooting practice. It would turn into a nice feature, if there would be a penalty of (let us say) -20% to the accuracy of anybody who is firing on a target out of his current sight. This can greatly enhance the tactical depth of the game. (Seb around? ;-) --[[User:Kyrub|Kyrub]] 14:20, 30 August 2008 (PDT)

...discussed [http://www.ufopaedia.org/index.php?title=Talk:Wish_list here]

===Enough Smoke===
[[User:Seb76#Mods|Implemented - here]]

It would be nice to increase the current limit on smoke/fire hexes. This is due to their locations being stored in a small, fixed length array. In effect you can only get about 3-4 smoke grenades worth of smoke or fire on the map at the same time. Being able to use smoke liberally would really open up new tactics. At the moment all you can really do is cover the LZ in smoke when you exit the transport, and maybe cover one advance over open ground. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)
:I did something for that on my loader. Heavy testing is required because it is hard to be make sure smoke still works as before (testing is the hardest part actually). [[User:Seb76|Seb76]] 14:09, 18 September 2008 (PDT)

=== Alien AI ===

====Aliens better with explosions====
Partly implemented [[User:Seb76#Bug Fixes|here (waypoint bug fix)]] and [[User:Seb76#Mods|here (Blaster drift)]]. ''(Possibly move this to talk, as notwithstanding these 2 bugs, apparently the Aliens are fairly safe with lethal explosives.)''

I wish that aliens using grenades or blaster bombs or stun bombs (anything that goes boom) would use more sense. They should not want to use items that go boom when they are guaranteed to be caught in the blast radius. The alien can use grenades and blaster bombs by going out of line of sight before the explosion goes off. That may not save them if the explosion blows out the walls. At least it would be less stupid then firing a point blank blaster bomb vs taking 5 steps and setting up another waypoint. Units with morale above 100 or mind controlled should still be suicidal as normal.--[[User:Brunpal|Brunpal]] 13:55, 19 September 2008 (PDT)

: Actually, the aliens are quite careful with their explosives, they just seem to be prone to the occasional accident. They're not likely to fire off a blaster or grenade too close to them - as evident by the strategy where if you see an alien with a BB but can't shoot back, the safest place is to stand next to it. The blaster bomb vertical waypoint fix in the loader also eliminates the 'oops' moments where they plot a vertical right angle too close to themselves and there just happens to be a wall to the south. However, they do need more care with stun bombs as you often get to see an alien fire a stun bomb point blank into a HWP parked next to it. But I guess we are talking about three different weapon types here, so they may not be as careful with a standard firearm as they are with grenades and the BB. Wish the Apocalypse aliens at least had as much sense as the UFO/TFTD aliens. In that game, they're utterly psychotic with explosives and ignore nearby allies. -[[User:NKF|NKF]] 14:34, 19 September 2008 (PDT)

=== Mind Controlled then Hostile ===
If you mind control a human (civilians) in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control.
: Now fixed by the Seb76 loader [[User:Spike|Spike]] 19:13, 11 December 2009 (EST)

=== Mind Controlled then MIA ===
Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).
: I believe XComUtil fixes this MIA issue. [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)
:: XcomUtil 9.6 also restores all DOA if you win to. Not what was intended. This feature has been removed as of 9.7 until I can fix it. --[[User:BladeFireLight|BladeFireLight]] 02:27, 6 January 2010 (EST)
: Now also fixed by the Seb76 loader [[User:Spike|Spike]] 19:13, 11 December 2009 (EST)

=== Open Doors But Don't Enter/Exit ===

Open doors like they do in TFTD (I know this is mentioned above with the good stun grenades idea).
: Now fixed by the Seb76 loader [[User:Spike|Spike]] 19:13, 11 December 2009 (EST)

= Category =
The page needs to be listed in various categories, which ones I don't know. Also links on other pages to this one would aid people finding it.

: OK how about this one: [[User:Spike|Spike]] 12:21, 3 September 2008 (PDT)

[[Category:Oddities and bugs]]

Wish List (EU)

2010-04-18T21:11:20Z

Wisq: /* Assault Time Limit */ Thoughts on UFO takeoff.

X-Com is a great game and as evidence just look to the fact this wiki exists even though the game pre-dates the internet. In all it's greatness X-Com has some elements and behaviors players wish they could change. This is a repository of those desires. Some day a fan mod may make your wish come true...

= I Wish... =
State what you want AND what X-com does normally. Sign your name if you think "Oh man! That would be great!"

== Geoscape and Strategic ==

=== Smarter Aircraft Movement Around Globe ===
I wish all craft understood the shortest distance between two points on a globe is a curved path towards the poles. Normally a craft goes in the opposite direction than it should (towards the equator). Pain in the ass when the base in the UK sends a craft to Siberia.
--[[User:Brunpal|Brunpal]]

=== Smart Interception ===

Aircraft intercepting a UFO just head straight toward the UFOs current position at all times. Unless the UFO is already on a head-on course, this results in the interceptor travelling through a closing parabolic spiral path, and often missing the UFO and ending up in a tail-chase, and then just falling further behind unless the UFO stops or reverses course. This is pretty basic stuff, fighter pilots have known how to do this better for nearly a hundred years. It is particularly important if the aircraft you are trying to intercept is moving faster than you (eg if you are flying an Interceptor).

What is needed is to plot the UFO's current course and speed (which X-Com has from radar data), and plot an intercept course. The maths for this is pretty easy (the intersection of 2 vectors) and can be implemented in a few lines of code, if we can find out where the current interception algorithm is, and patch it.

Actually the radar bearing shown on screen is only accurate to within 45 degrees. I presume that X-Com does actually know the UFO's bearing, since it can clearly track the UFO's movements. Finding where that variable is located might be different.

While we're at it, it would be nice if the UFO detection information displayed the actual bearing in degrees, rather than just the compass direction (North East, South, etc).

Even if the improved intercept algorithm only used a bearing accurate to within 45 degrees, that would still be better for remote UFOs. You might need to switch to "head straight for it" once you get to very close range. [[User:Spike|Spike]]

===Score for retaliation Battleships===

When a Battleship on retaliation attacks your base and is shot down, you get no score for it. This is completely illogical and it discourages any use of base defences. You should get normal 700 (or even 1400) points for it.
--[[User:Kyrub|Kyrub]] 14:05, 30 August 2008 (PDT)

: I'm not sure about this. Yes it's illogical, but it could also be a licence to get a huge score if you have a strong enough base. [[User:Spike|Spike]] 12:16, 3 September 2008 (PDT)

:: The impenetrable base setup would turn into a cheat. As the aliens will keep hammering the base with a battleship until one breaks through, you'll have a steady supply of points without having to really do anything. Some balancing, such as paying to rearm your defence modules, ought to be thrown in to balance things out. -[[User:NKF|NKF]] 23:13, 13 September 2008 (PDT)
:::A better fix would be to remove the retaliation flag when a battleship is destroyed. If someone can post a savegame with a never-ending flow of base attacks, I may have a look at the fix. [[User:Seb76|Seb76]] 01:05, 15 September 2008 (PDT)

=== All Aircraft Weapons Useful ===

In a balanced game, all weapons should have their uses, or at least a niche, but sadly this is not so:

The Cannon is only useful for shooting down Small Scouts, and even that is practically impossible, due to the difficulty in closing to 10km range with any UFO, particularly the fast-accelerating Small Scout.

The Stingray is not even useful for shooting down Small Scouts (destroys them 57% of the time) and the Avalanche is better in every meaningful way. It also takes twice as long to rearm, making it operationally much worse than the Avalanche.

The Laser Cannon is inferior to the Avalanche for everything. It does have a higher payload but this is hardly relevant. If attacking a UFO that you would struggle to kill with Avalanches, you are unlikely to own an aircraft that will survive long enough to inflict more damage than an Avalanche if it mounted Laser Cannon.

The Fusion Ball Launcher has a [[Talk:Craft_Armaments#Fusion_Balls_better_than_Plasma_Beams.3F¦possible niche]] in fighting Battleships when mounted on Interceptors. Even then, it is difficult and expensive to have aircraft configured to fight only one enemy.

Unfortunately, the optimum path for craft weapon development is all-Avalanche followed by all-Plasma Beam. This is a shame.

Suggestions to 'tune up' the other weapons:

*Cannon - Increase the damage to 20 or 25. So at least there is a pay-off if you manage to get in close.
*Stingray - Double the rearm rate so it can be reloaded as fast as an Avalanche launcher. Increase the ammo capacity to 9 or 12. Then up the rearm rate again (triple or quadruple) so it can still be reloaded as fast as Avalanche. Even then, it's probably not better than the Avalanche, so maybe it make it ''more'' accurate than the Avalanche instead of less. Raise Stingray to 90%, or to 80% but drop Avalanche to 65%.
*Laser Cannon - increase accuracy to 50% and damage to 100. Give it infinite ammunition.
*FBL - increase the ammo from 2 to 3. Increase damage to 250 or even 255. It's far and away the most expensive weapon to operate so it might as well pack the biggest punch.

It might be worth considering 'tune down' the Plasma Beam as well, particularly its stand-off range.
[[User:Spike|Spike]] 06:59, 14 February 2010 (EST)

=== Tougher UFOs ===

==== The Problem ====

So let me get this straight. The first hybrid airborne weapon that humans ever build, and it immediately outclasses every weapon the aliens ever built, including their Battleship weapon? After all the Aliens have only been building plasma weapons for a few million years, us humans have been doing it for ''months''!

More to the point, once you get Plasma Beams, downing UFOs is like shooting fish in a barrel. Even Battleships aren't that exciting if you show up with enough ships.

What is needed is to push up the range, damage, and rate of fire of all the UFO weapons, particularly the UFOs you will be fighting by the time you have plasma beams. At a minimum, the weapon on a Battleship should be at least as powerful as, say, 2 Plasma Beams (as found on the XCom craft it is fighting)? Instead of slightly less than half as powerful? Compared to a single Plasma Beam, only the Battleship weapon has better range. It has double the accuracy, slightly higher damage, but half the fire rate. Net 5.7% more firepower than one Plasma Beam, but no match for 2. And the Battleship weapon of course is the most powerful in the alien arsenal.

Possible tune ups for UFOs:

*Battleship - increase to 255 weapon power, improve reload rate to 12 (from 24). Now roughly equivalent to 4 Plasma Beams in total firepower (on Beginner difficulty). Increase range to 69km, so that the Battleship commences fire as soon as an XCom craft begins its attack run. Or better, increase range to 70+km, the limit of the interception window, so that the Battleship starts firing immediately the XCom craft enters air combat range. This would disrupt XCom aircrafts' ability to form up into a flight of 4, prior to commencing their attack. Overall, this would make it much harder to down Battleships. Increasing weapon range to 70+km would also make it much harder to tail a Battleship - manual control in the Geoscape would be needed to hold off outside of combat range. Really, the Battleship should not sit there like a sitting duck. Does it think XCom are friendly?
*Terror Ship - increase range to 52 (or decrease Plasma Beam range to 42), so stand-off kills are not possible with Plasma Beams?
*Actually maybe all the larger UFOs should have weapon range 69-70+km, so they behave very aggressively toward XCom craft.

NB: Strange effects occur if weapon range goes over 70km so it's probably best to leave it at 70km rather than 75km.

NB: Also, changes to rate of fire need to be looked at carefully though because Difficulty Level also reduces reload rate for UFOs. Between Beginner (Difficulty 0) and Superhuman (Difficulty 4), rate of fire (and thus firepower) for Battleships, Terror Ships and Supply Ships increases by 24/(24-4x2=16) or 50%. But if the base reload rate for these weapons was reduced to 12, the transition from Beginner to Advanced would increase firepower '''three''' times for these 3 UFOs (less so for the smaller UFOs). It is less risky to increase the weapon power. Unfortunately there are only 2 firepower variables to play with - damage and reload rate - so there are not a lot of options, especially for the Battleship which already has weapon strength 148 out of a probable maximum of 255.

:More detail on this. For Medium Scout, Large Scout and Abductor, with nominal reload rate 48gs, the rate of fire improves +20% between Beginner and Superhuman. For Harvester (32gs) it improves one third. For Large UFOs (Terror Ship, Supply Ship, Battleship - 24gs) the improvement is +50%. [[User:Spike|Spike]] 20:28, 14 February 2010 (EST)

I think we should assume that the Battleship, which is bigger than the entire XCom base, is engaging XCom craft with its secondary weapons rather than its main armament, which could probably destroy Manhattan with a glancing hit.

I would really like to see the hypothetical Mega-Battleship go up against XCom's finest - a flight of 4 Avengers armed with dual Plasma Cannon or dual Fusion Ball Launchers. With the Battleship having 70+km range, 255 weapon power, and an effective fire rate on Superhuman triple that of the PB, it would have the firepower of 11 Plasma Beams - 36% more firepower than the whole attacking XCom force combined. To be honest I think that would be carnage, not sure XCom could win. So that would be tuning the Battleship up too much. The 3-fold increase in rate of fire when on Superhuman is just too much. Maybe just max out the damage to 255 and range to 75. This gives a 72% increase in firepower, and a challenging tactical problem for XCom (forming up and approaching under fire).

The smaller UFOs can probably stay as they are. It is not until later in the game that XCom advances so that even large UFOs are easy pickings. What is the crossover point? Maybe the medium UFOs. So it might be good to reduce the reload times of the medium UFOs from 48 / 32 to 24, a good increase in firepower.

In general I think all UFOs energy weapons should have at least as good range as the XCom energy weapons, even the Medium Scout. Again, they have been using these weapons for millions of years and we only just figured out how to copy them from the aliens, how could our weapons be better than the aliens? How did our first plasma weapon out-range and out-perform all but the hugest UFO plasma beam? And on an airframe the size of a Small Scout we mount ''two'' such weapons? On the battlefield we only are able to replicate alien weapons; how is it that in the air we are able to improve on them ''masssively''?

Perhaps there should never be a stand-off advantage, except possibly with missiles -which should be less accurate with longer range. The XCom stand off advantage is really unfair because as far as I have seen the UFOs never attempt to close to effective range, even when they are getting killed. They don't break off much, either, though I think I have seen that happen on occasion.

==== Specific Proposals ====

===== No Standoff Beam Attacks =====

Increase ''all'' UFO plasma weapon ranges to at least 55km (compared to 52km for the XCom plasma weapon). Now only launched XCom weapons (Avalanche and Fusion Ball) have standoff advantage. Probably also reduce the accuracy of the Avalanche to 60% and buff Stingray accuracy to 80%, providing both weapons with a useful niche role.

===== No Standoff Attacks =====

Increase ''all'' UFO plasma weapon ranges to 66km (compared to 52km for the XCom plasma weapon). Now ''no'' XCom weapon has standoff advantage. (The benefit of a longer range weapon is simply spending less time being fired on by the UFO.)

===== Twitchy Aliens =====

Increase all UFO ranges to 69km. They will attack as soon as XCom aircraft commence any attack run.

===== Hostile Aliens =====

Increase all UFO ranges to 70km. They will attack as soon as XCom aircraft enter intercept range. UFOs now fire first, and tailing them unchallenged is impossible.

===== Improved Medium UFOs =====

Reduce (improve) the nominal reload time of Medium UFOs, Abductors and Harvesters, from 48gs and 32gs to 24gs. This increases the challenge in the early-mid game, when XCom might first be deploying advanced weapons.

===== Improved Battleships =====

Increase damage to 255. They're firing (bigger) Fusion Balls! A Battleship now has the same firepower as one XCom Craft with dual Plasma Beams (gosh wow!). It's a start, but what if we...

===== Super Battleships =====

... also reduce nominal reload time to 18gs. Giving a further one-third extra firepower on Beginner, 60% more on Superhuman.

===== Mega Battleships =====

... or for a real challenge, reduce reload time to 12gs. A further doubling of the firepower on Beginner - a further ''four'' times increase on Superhuman. Now Superhuman Battleships out-gun the biggest fleet XCom can throw at them!

[[User:Spike|Spike]] 00:25, 19 February 2010 (EST)

===Enforced Variant Games===

Various people like to play various variant games, such as No Alien Technology, or No Detection, or No Lethal Weapons - see for example Scott Jones' notes to XComUtil. It would be nice to have options on the game executable to enforce these scenarios. Self restraint is hard! [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

Some of these variant scenarios have been implemented by [[User:Seb76#Mods|Seb76]].

===Recruit Certain Alien Types===

Consider that not all aliens are loyal to their master (most TFTD alien has a device lodged to its brain), it would be interesting (or at least cool) if we could recuit such aliens to the XCOM cause. Maybe we can remove the controling devices from captive aliens after research on that species. Or convince the head of the Snakemen that it would be far more benefit to his race to help us instead of the Ethereals [[User:L-Zwei|L-Zwei]] 23:25, 12 September 2008 (PDT).

Only certain alien types should be recruitable. Ones that should NOT be include Mutons (as they are directly controlled by Ethereals), Chrysallids (unbalancing), etc. It would be nice to be able to reverse-engineer Cyberdiscs or Sectopods, or make it that a Cyberdisc must be researched to build hovertanks/etc.
[[User:MagicJuggler|MagicJuggler]] 13:32, 18 September 2008 (PDT)
: It's pretty obvious which ones should be recruitable: non-robotic terror units that are captured alive. Chryssalids should simply do melee damage instead of impregnating (as the resulting spawn would not be mind-controlled and therefore XCOM wouldn't do it). Silacoids would be pretty ineffectual, and reapers slightly less so, but both would be disposable scouts. Celatids might actually have some use (eating through hulls with acid, and arcing over walls) but are fragile. All of these would require capturing a terror alien alive after researching Psi Amp. The two robotic units should require a live alien Engineer researched as well as UFO Construction, and the materials for building one would be one corpse of the appropriate type, Alien alloys and Elerium (to repair and refuel the husk). The Sectopod should probably be nerfed somewhat, so that it isn't quite so invincible to Heavy Plasma shots - after all, it was probably a twisted and melted modern art piece by the time it finally went down). [[User:Stubbs|Stubbs]]

=== Game option: sell only researched items ===

The fact that you may sell the alien items for the best price once you get them, without any research, is illogical. Such staff would never get on the market, being top secret and potentially dangerous to the humanity.

Selling without proper research does not help the replay value of the game either: once you know the "right path" to get the best items, you simply sell anything else immediately and ignore the unnecessary research. Too easy.

Therefore I wish for this game option: unknown items are sold for 0 (including the alien corpses), the known ones for their full price. This makes the sustainable economics much harder to develop and it gives sense to the "useless" research. Last but not least, it adds a lot of depth to the gameplay: will you choose research of a new weapon you need on the field, or of a mind probe that will earn you millions in sales? --[[User:Kyrub|Kyrub]] 15:55, 6 April 2009 (EDT)

: I really like this option, it's a great idea. Makes the game harder and makes it more interesting, more varied. Gives extra value to the otherwise "useless" research paths. Good thinking! [[User:Spike|Spike]] 15:06, 24 August 2009 (EDT)

: I'd prefer that unresearched artifacts/corpses sold for a fraction of their original value (no more than 25%). It makes no sense that nobody would pay to research them for themselves. Additionally, Laser Cannon sell price needs to be nerfed. [[User:Stubbs|Stubbs]]

=== New Research Mechanics ===

The above comments spurred some ideas to make the research more realistic and the path to victory less obvious.

For flavor reasons, give research options vague names instead of exact names. This already exists in some research topics, such as "New Fighter Craft" instead of "Firestorm". So, research topics might read "Alien Hovertank Wreck" instead of "Cyberdisc Corpse", "Grey Alien Corpse" instead of "Sectoid Corpse" or "Alien Pistol" instead of "Plasma Pistol". The names would be revealed in the UFOpaedia entry, and certain items would then be renamed as per common sense.

Hide the ranks of aliens in captivity until they are researched (so you'd see Live Grey Alien #1, Live Grey Alien #2 if you had two Sectoids available for research). However, if you happened to have two Soldier ranks in containment, you'd only see one topic. The same rank/race combination would never appear again, but you might have to research several specimens of the same species to get the useful one you want. The alternative would be to have researched Mind Probe, which would tell you exactly what you had in containment (just as it does on the battlefield).

Once an alien or its corpse is researched, then all other instances of that alien or its body are renamed appropriately. For example, research a live Muton and Muton corpses become obvious, and vice versa. "Live Green Humanoid Alien" is also renamed to "Live Muton".

Finally, there should be a few more prerequisites in place to make less useful research more necessary. As someone else has mentioned, you should need a Cyberdisc Corpse to research Hovertanks. I'd also suggest that Psi Amp and Mind Shield require the research of Mind Probe (seeing as both entail scanning for minds as a logical first step), and that Flying Suits require Floater Corpse, Cyberdisc Corpse or a live Floater researched as an additional prerequisite (not Ethereals, as they fly with the power of their huge brains). [[User:Stubbs|Stubbs]]

:These are all good suggestions and make a lot of sense. An alternative explanation of the names (seen in some fan fiction) is that these names are not the real names, but are made up by XCom troops based on some limited battlefield experience of them. But revealing the "real" alien race names through Research is a fun idea. [[User:Spike|Spike]] 08:44, 1 September 2009 (EDT)

== Battlescape and Tactical ==

===Equipment Management===

All wishes are currently implemented!

===Fog of War Improvements===

I'm sure most of these would be an absolute PAIN to implement, but I figured I'd toss the ideas out here.

====Prior Recon of Battlefield====
One thing that has always irked me is X-COM has no terrain knowledge when it lands, despite having probably circled the place two or three times before landing and thus they should know at least some of the area. This would be nice, but isn't too important. Probably would be a pain to implement so X-COM would have all knowledge of external features but no knowledge of building interiors, anyways. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)

:Yes at the very least, when you splash the UFO, it could tell you (via some miracle technology such as "satellite reconnaisance") what the terrain type is of the landing zone area. Then you could adjust equipment accordingly. And adjust your uniform camouflage (if using one of the uniform mods). [[User:Spike|Spike]] 12:16, 3 September 2008 (PDT)

:: Geoscape: center on the site, then maximum zoom. Aside from having to disambiguate forest from jungle, this works fine for knowing the exact terrain you're getting into. -- [[User:Zaimoni|Zaimoni]] 10:17, 4 Sept 2008 (CDT)

:::This is already present in the game. To center the Geoscape on a specific location, right-click on the target spot. To do maximum zoom in, right click on the Zoom-In button(and the same works for Zoom-Out). Also, Jungle and Forest use the same display algorithm, but are easy to differentiate; Forest occurs NORTH of the equator, and Jungle occurs SOUTH. [[User:Arrow Quivershaft|Arrow Quivershaft]] 13:23, 4 September 2008 (PDT)

:Returning to AQ's original suggestion, it wouldn't be too hard would it for the dropship to "radar map" the target, and then have the basic map show up on your scanner on Turn 1? [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)

====Dynamic Fog====

The Fog of War in X-COM is clumsily implemented, compared to modern expectations. Everything starts out black, but after exploring, is shown...and it's kept in the same showing, regardless of whether you actually have LoS to that area anymore. It would be nice if when you no longer had Line of Sight to a particular map area, it would be cloaked in a way so that you knew the terrain, but not the units there. Since I've sometimes spent over half an hour trying to hunt down that last alien hiding in area I'd already explored. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)

====Deactivate Object Radar====

Currently, in X-COM, any objects dropped in a given square show on your Battlescape, regardless of whether you have Line of Sight to the square or not. In regards to dropped weapons/grenades/equipment/dead soldiers/dead aliens, this doesn't make a large difference. But in the case of STUNNED aliens, a quick scan across the Battlescape can tell you whether the alien you stunned 10 turns ago is still down, or stood back up(the stunned alien object will disappear from the stack). Of course, since aliens which have revived from stun are almost always disarmed(and the ones that aren't probably should've been killed instead), the usefulness of this 'exploit' is reduced mainly to finding out that the last alien you're looking for is just wandering aimlessly and unarmed. Perhaps leave stacks showing the same until you regain LoS to that area? [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:38, 7 August 2008 (PDT)

===Restore Game from Battlescape===

It would be nice to be able to reload a saved game directly from the Battlescape "?" screen, rather than having to go through the process of Abandoning to the Geoscape. Would you need to check it was a Battlescape save and not a Geoscape save? Maybe, maybe not. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Warm Grenades===

Currently when you set the timer on a grenade (or HE pack), the timer runs down every turn regardless of whether the grenade is worn, held, or dropped. Then, when the timer runs out, it explodes unless it is held or worn. There is no real grenade or explosive that works this way. Once the timer (fuse) starts running, they explode regardless. However for most hand grenades, the timer (fuse) doesn't start until after you throw/drop the grenade. It would be nice to have both of these real world behaviours, and lose the game's default behaviour. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

: Technically the way the game implements grenades, they don't have a timer. At least, not as such. When you set a grenade, the game just assigns it a turn to blow up on. Once the turn has passed, the game checks to see that it's on the ground and blows it up if it is, otherwise it doesn't. I believe Seb76 has already addressed this in his patches where there's an option to make grenade blow up regardless whether they are in inventory or otherwise the moment the timer is set. X-Com Apocalypse does a good job of this. The moment the grenade is so much as moved after the timer is set, it counts down. - [[User:NKF|NKF]] 23:01, 13 September 2008 (PDT)

:: To simulate an actual timer, you would need to do something like: Every turn that a primed grenade is being held by a unit during the "explode" check, increment by +1 the turn when that grenade is going to explode. [[User:Spike|Spike]] 19:10, 14 September 2008 (PDT)
:::I think I would change quantity2 ([[OBPOS.DAT]]) to a countdown instead of a turn, and use quantity3 as a flag indicating if the count has started. This flag is set any time a turn ends and the grenade has no owner. Taking it back in your hand once the timer has started won't help and the thing must be thrown... quantity2 is decreased if quantity3 is set, and the grenade blows up as usual. [[User:Seb76|Seb76]] 01:35, 15 September 2008 (PDT)

: That would be great. It would be exactly consistent with a 'spoon' type hand grenade. The timer only starts when you release the grenade, but after that it explodes at a definite time regardless of whether you pick it up or not. [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)

===Stun Grenades===

I want flashbangs.--[[User:Brunpal|Brunpal]] 22:59, 11 September 2008 (PDT)
:Instead of stunning, I'd see more effect if it would remove some TUs to units having line of sight (to be fare it should affect xcom units too). It would help against reaction fire (which is the point of flashbangs). Given that grenades detonate at the end turns, it would require a good coordination to have the grenade detonate exactly at the end of the alien turn, and just before your attack. Being able to open doors à la xcom2 would also help to throw flashbangs just before a craft assault... [[User:Seb76|Seb76]] 22:03, 12 September 2008 (PDT)
::That would be good. Hard to program, potentially extremely unbalancing, but good. I considered a "debuff" kind of ability (as you suggest) for flashbangs, vs the more obvious substitution of [[stun]] for [[Explosions|HE]] damage. In the end, I picked "I want flashbangs."--[[User:Brunpal|Brunpal]] 03:32, 13 September 2008 (PDT)
: Maybe flashbangs dont' work on Aliens - otherwise, XCom would use them, right? :) But seriously, I too would like flashbangs, and stun grenades / concussion grenades. Both of these would make the game easier, though. With flashbangs, you might have to compensate by just giving the aliens more TUs. [[User:Spike|Spike]] 13:33, 13 September 2008 (PDT)
::More options for the player is going to make it easier for any kind of game. Particularly of games like XCOM where the computer can't take advantage of the changes. However I don't believe a weak stun grenade (like 44 stun damage, comparable to AC-HE) would change the game much because the 80 item limit remains.--[[User:Brunpal|Brunpal]] 22:21, 13 September 2008 (PDT)

===Night Vision===

I '''don't''' want to add night vision equipment to the game. I assume that either (1) all XCom units already have night vision gear as standard, but it's not as good as alien night vision, and the visibility that XCom units have at night is based on their standard-issue night vision gear, or (2) night vision gear does not work on Aliens. Either they do not appear on night vision, or maybe worse - maybe the aliens can manipulate night vision equipment, causing worse than normal vision, or hallucinations, and even tricking XCom units into firing on each other. [[User:Spike|Spike]] 13:33, 13 September 2008 (PDT)

===Throwing over stuff===
'''(Moved to Talk, as this is not a bug and so does not need fixing.)'''

===Assault Time Limit===

One of the cool things about UFO Defence is there are no time limits on the scenarios. This is great as it allows for a totally different kind of tactics and much more flexibility.
It's more of a "thinking man's game" as a result. But... arguably this is not very realistic for UFO Assault missions. If the Aliens are getting creamed, they should try to make a getaway if they can (just like XCom would). A simple way to implement this would be a hard time limit (say 20 turns?) on a UFO Assault. Another way would be to base it on Alien Morale. At a certain Morale level the aliens decide to dust off. Give the player say 3 turns warning while they rev up the engines. Then if there is still a Navigator or Engineer in the Control Room alive, the ship takes off. Any XCom troops still aboard are MIA.

You might run into problems if the UFO took off but then landed again or was shot down, generating another ground mission with potentially '''more''' Aliens than were still alive at the end of the Assault. (Still, maybe they hatch some more clones if they get time to....) [[User:Spike|Spike]] 09:51, 4 September 2008 (PDT)

: It strikes me as justified they don't do that. Troops loose in the vessel could be seriously bad. It would be nice if they dusted off on the condition that their morale was low enough or 3 X-com soldiers had the door in their sights without aliens alive outside in the latter case and no X-com soldiers on board in either case. also, if the UFO has a hole in either the command or engine room, it would have to set down before leaving the atmosphere. [[User:(name here)|(name here)]]

Taking off with troops onboard would be perfectly safe (for the aliens) and justifiable if one assumes that alien ships in flight are inherently inhospitable for humans. This is easily done by saying that they undergo accelerations that humans can't withstand (splat), can't withstand for any length of time (pass out), or that they intentionally make rapid accelerations in different directions, either normally or just if they're trying to bash some intruders around. Naturally, the aliens themselves would either be immune to these (tough physique / their built-in antigrav devices?), or be in acceleration chairs, safe from all this.

Alternatively, when you get the warning that the UFO is going to take off, you've got a certain amount of time to either get everyone '''off''' the UFO, or to get everyone '''on''' it (or as many as you can). There could be a follow-up mission that takes place in "sky" terrain, where the outdoors is either impassable (the easy way) or else instantly withdraws units from combat (flying suits / parachutes). The soldiers' goals would be to either take out the aliens and presumably safely land and salvage the UFO, or take out the UFO's means of flying (power cores / navigator?). In the latter case, they might have a certain number of turns to withdraw or be caught in the crash, with possible casualties just like the aliens, mitigated to some degree by their armour and maybe where inside the UFO they are.

In the case of a crash, there could be a final mission to finish off the surviving aliens, using the X-COM soldiers that survive the crash, and no landing craft (it's still back at the old landing site). Alternatively, you could say that there '''is''' an X-COM landing craft parked outside (with all remaining members of the original landing party), since the in-flight time / distance was presumably low and the original X-COM craft quickly packed up and flew to the new landing site. [[User:Wisq|Wisq]] 17:11, 18 April 2010 (EDT)

===Alien AI===

====Attempts to rearm====
Aliens cannot pick up items, but I wish they would. If an alien has no useful weapons in inventory they should either head for cover or head for a plasma weapon. Panicked aliens drop their weapons but never seem to pick them up when they managed to pull themselves together. It would be nice if they tried to arm themselves again. --[[User:Brunpal|Brunpal]] 13:55, 19 September 2008 (PDT)

:Even if it's too hard to make aliens head towards weapons (is it safe?, could it be used to trap them, not to mention the complexities of route finding) - it would still be good if an unarmed alien checked for usable weapons in every square it moved through, and at least picked up one loaded weapon or grenade per turn. [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)

Fixing the AI for this could be really hard. Apart from all the possible exploits by XCom, the AI is probably a really hard part of the game to reverse engineer. You could say that an unarmed alien is no threat anyway (we are only concerned about aliens without psi or built in weapons). So nothing is lost even with an exploitable method of re-arming. By exploitable I mean the XCom player can manipulate re-arming, e.g. by leaving weapons out in the open as bait for traps.

Maybe the simplest modification would be to ''not'' drop weapons when the alien panics? This does not require delving in to the AI, just intercepting the panic effects. Dont make aliens drop any weapons when they panic. It would be reasonable to return the weapon in hand to inventory, so there is a TU cost for the alien to bring the weapon back into play again.

This would not work for aliens who were stunned and wake up, or who were mind controlled by XCom and made to drop their weapons. But it would probably catch 80% of cases.

Another cheat, short of fixing the AI, is just to pick up weapons that the alien walks over. It could also pick up "spare" weapons from adjacent aliens (cheating on TUs - basically just teleporting the items to the unarmed alien). Spare alien weapons are almost invariably grenades. I have not had a lot of success in getting unarmed aliens to use grenades, so more research is needed here. Maybe only certain types of aliens use grenades, or only in certain circumstances?

Really, really cheating would be to teleport any weapon laying around the battlefield into the alien's inventory. But I think it is more fair just to say panicked aliens dont drop their equipment. [[User:Spike|Spike]] 16:13, 13 February 2010 (EST)

==== End Psi Bullying and Psi Baiting ====
When the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength?

: Not a bad idea to randomise this a bit, because while initially this tactic helps the aliens, it becomes so predictable that it can be used against them by deploying unarmed "Psi Bait" soldiers to draw off all the attacks. (Or make aliens avoid controlling/panicking soldiers who have no loaded weapons. But then folks would just give them pea shooters and wear armour.) [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)

=== 80 Item Limit on Base Defense Mission ===
: Well you get the 80 item limit on every mission, but it hurts more on a Base Defence as you have more limited ability, or sometimes no ability, to manage what goes into those 80 items. I was thinking about a couple of (theoretical) ways to fix this and I hit on a new one (new for me anyway): Why not take the 80 items from the Transport(s), first Transport then second Transport until you run out of items or hit 80. This has a few benefits:
:* Ready made interface to manage the 80-item limit, the Stores <> Craft (Equip Craft) Screen.
:* If you have no warning at all, the 80 items will probably make good tactical sense in general terms, even if they are are not totally optimised for Base Defence (no proximity mines, etc).
: I think that copying the Transport inventory into the Battlescape inventory would be relatively to implement (though what do I know?). As a simplification, you could move only the inventory in the ''first available'' Transport that is present in the Base, into the Battlescape, and not bother looking in more than one place (other Transports, Base Stores) to get up to 80. It would then be a bit of a drag if your Transports are all out on a mission when your Base gets attacked though. Or perhaps inspect the inventory of Transport 1 (wherever it is in the world), and then attempt to copy its inventory, using equipment present in the Base?
: Another way of doing it which has been mentioned elsewhere is to try to reverse the order of the items in the Stores list. This has the effect of putting the more advanced weapons first, rather than the more basic weapons. There could be all kinds of unwanted side effects of this, depending on various programming issues.
: Actually there is already a fix for the 80-item limit in XComUtil. XComUtil records a standard assign weapon set for each of your troops, and then teleports those weapons to the Battlescape from your Base Stores, regardless of the 80-item limit (but still subject to the Battlescape's 170-item limit). Not 100% sure if this works for Base Defence missions though.
:[[User:Spike|Spike]] 13:22, 24 November 2008 (CST)

=== Collision Detection Bugs ===
I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof!

=== Base Defence Systems Cause Alien Casualties ===

I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round).

: The general view is probably that Base Defence missions are a boon to XCOM already, so why make them any easier. At very least there would need to be more damage to the loot than there was to the Alien's combat effectiveness, otherwise this unbalances the game in favour of XCOM. [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)

=== Alien vs Alien ===
This one is way out there. Alien v Alien battles out with main game, just random battlescape maps. Sectoid and their terrorists against Floaters and theirs etc. One side human controlled the other computer. Choice of ships involved etc.

:I actually love this idea. It might just about be possible using XComUtil, if someone is a total XComUtil guru.

----

There was a utility to do this from Devisraad. it has long since been removed from his site, but someone may still have it. The basics was you renamed unit and it automatically replaced graphics flag to swap out the units. Didn't work on the Large Aliens but still was a fun mod --[[User:BladeFireLight|BladeFireLight]] 02:20, 6 January 2010 (EST)

=== Aircraft in Base Defence Battlescape ===

New graphics for the Interceptor and Firestorm on the battlescape. All your ships could remain in their hangers when the aliens attack your base. Don’t understand why Mythos did not do this originally.

----

Simply for one reason: the limit on the size of the battlescape. UFO maps are usually limited to 10000 tiles (50x50x4), on Bases you have 9600 (60x60x3), the last level one being dirt. You need 3 levels to display X-COM craft. [[User:Hobbes|Hobbes]] 14:28, 23 September 2008 (PDT)

----

Could you not do it but clip off the top level of the craft - leaving the ground level and 'deck' level? It would be a cool terrain area to fight in. I like the fact that in TFTD you can still see your subs during a base defence. [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)

----

It is possible to edit the map files to include the Skyranger, but you'll have to use Xcomutil to play with that terrain and I think it would never launch during base defense missions (but I'm not sure on that - never tried editing the X-COM base terrain). [[User:Hobbes|Hobbes]] 19:25, 4 December 2009 (EST)

----

This could be done by creating new "hangar" map modules, each containing one of the five possible X-COM craft. Bung the modules into [[GEODATA.DAT]] at index 0C, and you're done. The catch is you can't have all craft or the MCD array will overflow. The base terrain uses ~160 tiles as it is (out of the max of 256), while the craft use about 60 each (on average). Putting them all in would take the table above 300 entries (that is to say, the game'd crash).

'Cause XcomUtil already provides us with an Intercepter design made up of SkyRanger parts, I suppose the way to go would be to only implement those two craft. If you have any alien technology ships, they could either be left out ("they were fast enough to escape") or rendered as SkyRangers.

It should also be noted that bases are made up of two levels, not three. Luckily, all the craft are only three levels high, so cutting out the landing gear still works. - [[User:Bomb Bloke|Bomb Bloke]] 19:56, 4 December 2009 (EST)

----

Very true about the MCD limit, that's why I only mentioned the Skyranger but the Interceptor could be added as well (and would not make much sense to have your first defense mission with a nice Avenger parked on the hangar while your Interceptors are being blow to bits by Battleships). The bases are 3 levels but you can only modify two of them. The game engine automatically adds a layer of 'dirt modules' either at top or bottom. Hmmm, this just gave me an idea for the wish list... [[User:Hobbes|Hobbes]] 20:29, 4 December 2009 (EST)

----

Both alien and X-Com bases ''are'' only two levels. There must be something screwy in your game; XcomUtil maybe?

It occurs to me that removing landing gear and stuff might make it ''just'' possible to jam in the Lightning tiles as well (as the MCD requirements would also shrink slightly). That'd make it possible to add the Firestorm, too. Seems a shame to get that far then leave out the Avenger, though...

- [[User:Bomb Bloke|Bomb Bloke]] 21:30, 4 December 2009 (EST)

----

Nevermind, I completely misread your previous post. Yes, they are two levels only, could be Xcomutil that adds the 3rd level.

- [[User:Hobbes|Hobbes]] 22:30, 4 December 2009 (EST)

----
You may be able to get 3 levels in an X-Com Base but not 4. EU has a smaller amount of memory alocated. I dont know the limit but 60x60x4 will crash EU. TFTD has no problem --[[User:BladeFireLight|BladeFireLight]] 02:25, 6 January 2010 (EST)

----

I got partway through this and then decided to change my methods entirely and start from scratch. So I thought I might as well post my progress anyways, as it's already about on par with the crude TFTD implementation: You always have the same craft appear in your hanger regardless of what is (or isn't!) there.

[[Image:Skyranger In Hanger.rar]]

- [[User:Bomb Bloke|Bomb Bloke]] 05:40, 17 December 2009 (EST)

----

Hey BB, a while ago I have modded the plane terrain files so that the Skyranger appears facing east instead of south. If you want to use that one (to make it a little different) let me know. [[User:Hobbes|Hobbes]] 08:23, 17 December 2009 (EST)

----

Thanks, but don't worry about it for now: it'll make the MCD arrays larger still, so I'll consider it when I get all the other stuff done.

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

----

The completed mod is now included in my toolpack. As usual, I've only done cursory testing on it, but I'm pretty sure it's stable enough.

- [[User:Bomb Bloke|Bomb Bloke]] 06:40, 20 January 2010 (EST)

=== Fixed firing TUs ===

Something that always bugged me was how the weapons used percentages for firing TUs. It doesn't make sense that the faster a soldier got, the longer it would take to fire a weapon.
: This is because you can't fire an automatic weapon any faster than it will shoot. However, it otherwise makes minimal sense, as you point out. I suggest two alternative solutions. Firstly, that only automatic fire modes use a fixed percentage of a soldier's time units, and other modes use a fixed number of TUs. This would entail the newer soldiers spraying and your most elite taking fast, selective single shots. The alternative is that each firing mode for each weapon entails its own formula (revealed in the UFOpaedia but essentially hidden during the battlescape) along the lines of "X% of TUs + Y TUs". Snap fire would be a low % of total plus a low fixed cost, Aimed would be a low % of total with a high fixed cost, and Auto would be a high % of total with a low fixed cost. While this is somewhat complex, in-game you wouldn't have to worry, and it accounts for what can be reduced (i.e. aiming speed) and what can never be improved by a soldier (i.e. cyclic rate of fire or time for a missile to lock). [[User:Stubbs|Stubbs]]
:: These observations are very sensible. However we also need to consider the impact on game balance. If you implement this in an even-handed way, alien rates of fire will increase as they have high TUs. Or, if you fudge it so that alien rates of fire remain the same, then X-Com's advantage will increase as the game progresses. Neither of these are desirable. It would be extremely hard to implement this and still maintain game balance. [[User:Spike|Spike]] 08:41, 1 September 2009 (EDT)
:::Each turn has the exact same duration, but is divided into TUs separately for each soldier. That's a simplification that works well in a turn-based game and reflects the fact that a soldier is fast or slow. However, weapons need to be aimed and will not fire faster than normal, thus they require a fixed percentage of the turn duration. In other words, soldiers gain movement speed, but fire at the same rate. This is both desirable and logical, just not self-explanatory. Thus, I would definitely stick to how TUs consumption is solved currently. [[User:mingos|mingos]]

=== In-flight Interception ===

Yes, I know that this idea is nigh-impossible, but I was thinking, wouldn't it be awesome to infiltrate a battleship, kill the aliens inside and escape, with the geoscape being shown zooming past underneath? Also, in a similar vein to the "aliens dust off after 3 turns" idea, after killing the aliens ( or blowing up the power cores, maybe?)you would have to get as many troops as possible to the drop ship in 3 turns(in retrospect I guess that you could only do this with the Lightning because of the doors) or the ship crashes and all troops not in the dropship are missing in action. Yes, this idea is impractical and would be really hard to program, but the idea of blowing a UFO up from the inside just seems epic to me. [[User:WolfenMage|WolfenMage]]

== Miscellaneous ==

===Fix All Bugs===

Oh no [[User:Seb76#Bug Fixes|Seb76]] already did this! :) [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

= I Wished (And My Wish Came True)... =

== Geoscape and Strategic ==

=== Fuel Ready always ===
[[User:Seb76#Mods|Implemented - here]]

I wish that I could send out craft at any fuel or ammo level. Normally craft can only leave a base if fully "ready". Craft is only "ready" at 100% fuel (or 0% fuel using an exploit) but there's no logical reason why a full tank and full ammo is required. Fully repaired... that's fine. I can live with pilots refusing to fly a plane missing a wing even if it means England is lost to aliens. 15 hours to fill a tank? Retarded but I can live with that too if I can send out a craft at 20% fuel.
--[[User:Brunpal|Brunpal]]

:Actually, many modern aircraft '''do''' require the fuel tanks to be full on takeoff, and fairly empty on landing. The weight of the fuel is figured into the takeoff aerodynamics, and the tank being full prevents fuel 'sloshing' in the tanks and not actually making it to the engine. (Conversely, many aircraft need to have dispensed of much of that fuel weight before landing.) This holds for most runway-takeoff craft, but may not apply to anything with VTOL capacity; I'm unsure there.

:I do agree that non-full weapons aren't as critical, though. But from a logical standpoint, most modern aircraft should not be launched on an empty fuel tank. I also should noted that an Elerium-fueled craft with [[Known_Bugs#Elerium-fueled_Craft_Bug|50% fuel or less remaining]] will automatically return to base, regardless of distance from base. Of course, given that such craft fuel up quickly, its less of an issue there. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:05, 7 August 2008 (PDT)

:Hum, maybe you can try [[User:Seb76#Mods|this]]? [[User:Seb76|Seb76]] 13:01, 8 August 2008 (PDT)
::Thanks! But I can't try it. I've not been able to get my copy of Xcom to run properly except on a Win98 install. VC2008 requires a more modern OS. I'm sure I could ''eventually'' figure out a way to get it running, but I tried once and wasted too much time before giving up.--[[User:Brunpal|Brunpal]] 14:45, 8 August 2008 (PDT)
:AFAIK VC2008 binaries should run OK on Win98 as long as the runtime is deployed. Anyway, the loader uses CreateRemoteThread API which is not available in Win98 so don't even bother. '''However''', you can manually patch the binary if you want ;-) Data to patch (all in hexadecimal):
offset 0x41752: 2A0075 -> 18207C
:HTH. [[User:Seb76|Seb76]] 14:56, 8 August 2008 (PDT)

===Base Build Stacking===
[[User:Seb76#Base Building Stacking|Implemented - here]]

At the moment you are only allowed to build next to a finished module, and you aren't allowed to plan ahead in your base construction. It would be nice to at least be able to plan more than one phase of construction in advance. This would be pretty easy to implement. There is no need to code any new "queuing system". Just place the new module next to an existing under-construction module, but increment the build time to the normal build time + the time remaining on the under-construction module (the lowest time remaining that would make the square you are building in, a legal square to build in). As a premium for build stacking, you have to pay the costs up-front. As with normal construction, all costs are non-refundable if you change your mind. (There would probably need to be some on-screen feedback for how long the module would take to build, before you were committed to building it.) [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

See also: Discussion on [[Talk:Wish List|Talk page]].

== Battlescape and Tactical ==

=== Equipment Management ===

==== Soldiers remembers THEIR equipment ====
[[XcomUtil|Implemented - here]]

I wish soldiers remembered what equipment they LAST used and start with that gear when they land. Normally soldiers grab various gear and put lots of crap on their belt. I put most things on the shoulder slots, and keep many things spare things on the ship just in case I need them. (I only want IN rounds if it's night. Stop picking them up before I shoot you in the back!) Takes forever to sort out the gear so the weakling isn't carrying all the rockets etc.
--[[User:Brunpal|Brunpal]]

:This is already available in [[XcomUtil]]. [[User:Arrow Quivershaft|Arrow Quivershaft]] 22:07, 7 August 2008 (PDT)

====Access to Stats screens during equipment allocation====
[[User:Seb76#Equipment Screen|Mostly implemented - here]]

In Battlescape you can get to Stats screens by right clicking on one of the unit's status bars. However you can't do this in the Equipment screen. Things like Statstrings and (even more so) [[User:Seb76|Seb76]]'s modified Equipment screen with actual/max weight help. But it would be nice to be able to see exact stats. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)

===Decrease Accuracy for targets out of sight===
[[User:Seb76#Range_Based_Accuracy|Brilliantly implemented - here]]

How come you can easily shoot on something you do not see?
I find the over-used scout-sniper tactic is a cheap exploit of the X-COM. The tactical game should describe a combat, not a cowardly shooting practice. It would turn into a nice feature, if there would be a penalty of (let us say) -20% to the accuracy of anybody who is firing on a target out of his current sight. This can greatly enhance the tactical depth of the game. (Seb around? ;-) --[[User:Kyrub|Kyrub]] 14:20, 30 August 2008 (PDT)

...discussed [http://www.ufopaedia.org/index.php?title=Talk:Wish_list here]

===Enough Smoke===
[[User:Seb76#Mods|Implemented - here]]

It would be nice to increase the current limit on smoke/fire hexes. This is due to their locations being stored in a small, fixed length array. In effect you can only get about 3-4 smoke grenades worth of smoke or fire on the map at the same time. Being able to use smoke liberally would really open up new tactics. At the moment all you can really do is cover the LZ in smoke when you exit the transport, and maybe cover one advance over open ground. [[User:Spike|Spike]] 12:06, 3 September 2008 (PDT)
:I did something for that on my loader. Heavy testing is required because it is hard to be make sure smoke still works as before (testing is the hardest part actually). [[User:Seb76|Seb76]] 14:09, 18 September 2008 (PDT)

=== Alien AI ===

====Aliens better with explosions====
Partly implemented [[User:Seb76#Bug Fixes|here (waypoint bug fix)]] and [[User:Seb76#Mods|here (Blaster drift)]]. ''(Possibly move this to talk, as notwithstanding these 2 bugs, apparently the Aliens are fairly safe with lethal explosives.)''

I wish that aliens using grenades or blaster bombs or stun bombs (anything that goes boom) would use more sense. They should not want to use items that go boom when they are guaranteed to be caught in the blast radius. The alien can use grenades and blaster bombs by going out of line of sight before the explosion goes off. That may not save them if the explosion blows out the walls. At least it would be less stupid then firing a point blank blaster bomb vs taking 5 steps and setting up another waypoint. Units with morale above 100 or mind controlled should still be suicidal as normal.--[[User:Brunpal|Brunpal]] 13:55, 19 September 2008 (PDT)

: Actually, the aliens are quite careful with their explosives, they just seem to be prone to the occasional accident. They're not likely to fire off a blaster or grenade too close to them - as evident by the strategy where if you see an alien with a BB but can't shoot back, the safest place is to stand next to it. The blaster bomb vertical waypoint fix in the loader also eliminates the 'oops' moments where they plot a vertical right angle too close to themselves and there just happens to be a wall to the south. However, they do need more care with stun bombs as you often get to see an alien fire a stun bomb point blank into a HWP parked next to it. But I guess we are talking about three different weapon types here, so they may not be as careful with a standard firearm as they are with grenades and the BB. Wish the Apocalypse aliens at least had as much sense as the UFO/TFTD aliens. In that game, they're utterly psychotic with explosives and ignore nearby allies. -[[User:NKF|NKF]] 14:34, 19 September 2008 (PDT)

=== Mind Controlled then Hostile ===
If you mind control a human (civilians) in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control.
: Now fixed by the Seb76 loader [[User:Spike|Spike]] 19:13, 11 December 2009 (EST)

=== Mind Controlled then MIA ===
Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).
: I believe XComUtil fixes this MIA issue. [[User:Spike|Spike]] 12:22, 24 November 2008 (CST)
:: XcomUtil 9.6 also restores all DOA if you win to. Not what was intended. This feature has been removed as of 9.7 until I can fix it. --[[User:BladeFireLight|BladeFireLight]] 02:27, 6 January 2010 (EST)
: Now also fixed by the Seb76 loader [[User:Spike|Spike]] 19:13, 11 December 2009 (EST)

=== Open Doors But Don't Enter/Exit ===

Open doors like they do in TFTD (I know this is mentioned above with the good stun grenades idea).
: Now fixed by the Seb76 loader [[User:Spike|Spike]] 19:13, 11 December 2009 (EST)

= Category =
The page needs to be listed in various categories, which ones I don't know. Also links on other pages to this one would aid people finding it.

: OK how about this one: [[User:Spike|Spike]] 12:21, 3 September 2008 (PDT)

[[Category:Oddities and bugs]]

Terror Mission

2010-04-08T23:23:34Z

Wisq: /* UFOs with Terror Missions */

Large numbers of aliens have landed in a major city! The population panics! There are special large "[[Terror Units|Terror Unit]]s" we haven't seen before!

Funnily enough, these seem to be more of a trap for your squad than a political move by the aliens... Oh well, into the breach once more...

==Briefing==
Mission will be successful when all enemy units have been eliminated or neutralised. You must attempt to save the lives of any [[civilian]]s in the area by neutralising the alien menace.

==A Debriefing==
An excerpt from a soldier's journal who shall remain nameless:

'-- it's very strange. The aliens don't appear to want to kill the poor citizens they're terrorising. At least not at first. They won't hesitate in the least and will immediately open fire on the civilians the very moment our dropship lands in the area and lowers its access ramp . If we ignore the terror alert for a few hours, they'll kill the townsfolk anyway.

They appear to know when one of our ships is en route to the site, and will patiently wait for us to arrive. I wonder if we have any moles in the organisation, or if the aliens just have awfully powerful scanners? They just know. I guess that's all there is to say about it.

Sgt. Mikhail Okabe says it all boils down to psychological warfare. They want to break our morale by making us watch helplessly as they slaughter the people we're sworn to protect. If we arrived and all the civilians were dead, we'd probably not think twice about it, or at least not as much if we were to watch them being murdered before our very eyes, or having to listen to their tormented screams. Or maybe it is to hamper our firepower, similiar to a hostage situation? Just the other week, Captain Jason Smith spotted a cyberdisk... several feet away from 2 civilians! Though it pained him to do so, he had no choice but to give the order to fire the Rocket Launchers at it, killing cyberdisk and civilians together. I have known some officers try to save/spare civilian lives, and cause the death of their entire squads. In the end, we are at war with the aliens, and in every war, there is collateral damage.

The aliens also seem to do something to the civilians before we arrive. At every terror site I've been to, the locals always appeared to be in a rather addle minded state, and walked about as if they're in a dream. They'll merrily walk through a hail of flying lead just to let the aliens get a better shot at them, and yet they won't seek shelter in nearby buildings or the relative safety of our dropship.

The third time they attacked Novosibirsk, I remember trying to protect an old woman from one of those furry bipedal aliens that was chasing after her. Instead of getting behind me for protection, she stared at me with a vacant smile, turned around and walked towards the alien and... That happened only a week ago, but every time I try to rest, my sleep is plagued with the same nightmare. If this keeps up, the base commander's going to need to find a new firearms instructor, and I'm going to be sporting a new jacket with very long sleeves.

But I think that's not the worst of it. If we knock out any civilians during the battle with our shock sticks, they just change. I don't really know how to describe it, except that they become someone.. no something else. . I've a feeling these people, who are in a very weakened mental state, are holding onto their minds for their dear lives. Any interference on our part just causes them to lose concentration and are thus defenceless against whatever it is that enters their heads and practically kicks them out so that it can then make itself at home.

These posessed civilians are harmless when awake, but we are still required to deal with them somehow. No matter how we decide to do that, our Damage Control specialists jump in and 'vanish' any of the affected persons. It's a very hush-hush matter. Even the inspection team from the UN who come around to assess the damage aren't made aware of the posessed civilians, so we are not credited or discredited for this little mistake of ours.

After the aliens have been dealt with, the rest of the civilians seem to recover after a few hours, and have no recollection of what had just happened to them. This is rather convenient and saves having to lug all the brainwashing equipment out there. But one does have to wonder how Damage Control is going to explain the big crater where the old gas station should be, or what's up with that inside-out vege-mart. "

-- [[User:NKF]] pasted by [[User:JellyfishGreen|JellyfishGreen]] 13:18, 25 Apr 2005 (BST)

==Alien Deployment==
<table {{StdCenterTable}}>
<tr {{StdDescTable_Heading}}><th align="left">Rank</th>
<th>Beg./Exp.</th>
<th>Vet./Gen.</th>
<th>Super.</th></tr>
<tr><td align="left">Soldiers</td><td>4-5</td><td>5-6</td><td>6-7</td></tr>
<tr><td align="left">Navigators</td><td>1</td><td>1</td><td>2</td></tr>
<tr><td align="left">Medics</td><td>1-2</td><td>1-2</td><td>1-2</td></tr>
<tr><td align="left">Engineers</td><td>1</td><td>1</td><td>2</td></tr>
<tr><td align="left">Leaders</td><td>1</td><td>1</td><td>1</td></tr>
<tr><td align="left">Commanders</td><td>0</td><td>0</td><td>0</td></tr>
<tr><td align="left">Terrorists</td><td>2-6</td><td>4-8</td><td>6-10</td></tr>
<tr><th>Totals</th><td>10-16</td><td>13-19</td><td>18-24</td></tr>
</table><br />

==Civilian Deployment==
The number of civilians spawning during a Terror Mission is between 0-16. Generally, expect between 8 and 16 civilians to still be alive when you arrive. However, if the aliens have wiped them all out, they'll still happily combat your squad.

==Tips & Tricks==
* The Terror UFO isn't anywhere to be found during a terror mission.
* [[Urban Terrain]] (city/suburb).
* In a terror site - worry about your soldiers first. Civilians later. Very important. This is a game, so you can choose to be a bit heartless. (It's called collateral damage)
* The gas pumps are explosive!
* All buildings in the cityscape are very weak. Light gunfire can destroy fences and walls.
*To save a few more civilians than usual, try limiting HE rounds.
* TIME is NOT on your side. If you want a half-decent score, expand quickly and secure. The quicker you kill aliens or get them to panic, the more civilians you'll save overall.
*The aliens will have grenades and heavy plasma, but they never bring blaster bombs along on terror missions. I suppose they don't want to end it that quickly.
* Bring lots of heavy rockets and high-explosive. First people off the transport should create a "free fire" zone around the craft with them. You aren't penalized for property damage, so level the place.
* You can get a rough idea for how many civilians are left by gauging the length of the alien turn (Civilians move after aliens.) The other way to determine is to save your game, abort the mission, check the debriefing tally of killed civilians, and then reload. Some may view the latter method as cheating.

==UFOs with Terror Missions==
The city-raiding terror mission mentioned above occurs only when a [[Terror ship|Terror Ship]] is sent on an Alien Terror mission and lands on a city.

But before this happens the aliens will send a [[Small Scout|Small]]/[[Medium Scout|Medium]]/[[Large Scout|Large Scout]] which will show on a [[Hyper-wave Decoder]] as on a Terror Mission.
The ship will land randomly, in some non-urban area, and behave much like you would expect to see on a an [[Alien Missions#Alien_Research|Alien Research]] or [[Alien Missions#Alien_Abduction|Alien Abduction]] mission. Unlike a city raid, these scout terror missions will not include [[Terror Units]].

If this scout is shot down by X-COM craft and/or assaulted on the ground, chances are that the following Terror Ship will not be able to target any city when it arrives at its target region. It will then wander around for some hours on the area before finally departing back to its hidden base. To know if a Terror Ship will attack a city, watch for its flight pattern: if it immediately heads towards a city after arriving at a region, then it will perform a Terror Mission.

While the city-raiding missions cannot be ignored because of the drop in X-Com's funding and esteem that it would cause, they can be largely avoided by shooting down the scouts. Another alternative, perhaps more risky, is to try to shoot the Terror Ship before it lands. However, both might risk some sort of [[Alien Retaliation]].

==See Also==
*[[Terror Units]]<br />
*[[Alien Terror]]<br />
*[[Urban Terrain]]<br />

{{Mission Types Navbar}}
[[Category:Missions]]
[[Category: Tactics]]
[[Category: Fiction]]

Medium Scout

2008-12-16T22:41:39Z

Wisq: /* Recoverable Components */

==General Information==
A medium sized scout vessel that poses little threat to earth forces. Normally appears before larger vessels during missions.

==Statistics==
<table {{StdCenterTable}}>
<tr {{StdDescTable_Heading}}><th align="left">Statistic</th>
<th>Value</th></tr>
<tr><td align="left">Size</td><td>Small</td></tr>
<tr><td align="left">Max Speed(km)</td><td>2,400</td></tr>
<tr><td align="left">Weapon Power</td><td>20</tr>
<tr><td align="left">Weapon Range(km)</td><td>15</td></tr>
<tr><td align="left">Weapon Range(range units)</td><td>120</td></tr>
<tr><td align="left">Damage Capacity</td><td>200</td></tr>
<tr><td align="left">UFO Downed points</td><td>75</td></tr>
<tr><td align="left">UFO Destroyed points</td><td>150</td></tr>
</table><br />

==Additional Information==
This ship isn't a big threat. [[Avalanche]] missiles will put it down, usually.

Ship carries ONE [[UFO Power Source|power source]], and two [[UFO Navigation|Navigations]].

This is a one-level ship, octagon-shaped, with no interior walls and the power source in the center of the craft.

Several aliens will be inside the ship and a few outside during missions. Sometimes the aliens can hide behind the power source so be sure to check the corners after breaching the doors!

If you're unlucky, and the power source was destroyed during the crash, there'll be a nice big hole in the ship during [[UFO Crash Recovery|recovery]]. The location of the hole varies. Feel free to toss big explosives into the hole as there will be no [[Elerium-115|elerium]] to recover anyway. This might, however, destroy the equipment that was carried by those aliens killed in the crash.

==Notes==
*If there's no other way to enter aside from the hatch, your best bet may be to set up a firing line outside-- the sort used in [[Reaction Training]]-- and wait them out. The aliens will usually start coming out soon after turn 20. Anyone trying to charge through that hatch will probably run into at least 2, usually more, aliens on the inside waiting to shoot anyone who comes through.

==Recoverable Components==
<table {{StdCenterTable}}>
<tr {{StdDescTable_Heading}}><th align="left">Item</th>
<th>Sell Price</th>
<th>Quantity</th>
<th>Value</th></tr>
<tr><td align="left">UFO Power Source</td><td>$250,000</td><td>1</td><td>$250,000</td></tr>
<tr><td align="left">UFO Navigation</td><td>$80,000</td><td>2</td><td>$160,000</td></tr>
<tr><td align="left">Alien Food</td><td>$5,000</td><td>0</td><td>$0</td></tr>
<tr><td align="left">Alien Surgery</td><td>$38,000</td><td>0</td><td>$0</td></tr>
<tr><td align="left">Alien Entertainment</td><td>$20,000</td><td>0</td><td>$0</td></tr>
<tr><td align="left">Examination Room</td><td>$9,000</td><td>0</td><td>$0</td></tr>
<tr><td align="left">Alien Alloys</td><td>$6,500</td><td>11</td><td>$71,500</td></tr>
<tr><td align="left">Elerium-115</td><td>$5,000</td><td>50</td><td>$250,000</td></tr>
<tr><th colspan="3">Totals</th><td>$731,500</td></tr>
</table><br />
Also see [[UFO Recovery Values#Medium Scout|UFO Recovery Values]].

==Alien Deployment==

<table width="100%" cellpadding="5"><tr>
<td><table {{StdCenterTable}}>
<caption><b>Sectoids/Floaters</b></caption>
<tr {{StdDescTable_Heading}}><th align="left">Rank</th>
<th>Beg./Exp.</th>
<th>Vet./Gen.</th>
<th>Super.</th></tr>
<tr><td align="left">Soldiers</td><td>2-4</td><td>3-5</td><td>4-6</td></tr>
<tr><td align="left">Navigators</td><td>1-2</td><td>1-2*</td><td>2-3</td></tr>
<tr><td align="left">Medics</td><td>0</td><td>0</td><td>0</td></tr>
<tr><td align="left">Engineers</td><td>0</td><td>0</td><td>0</td></tr>
<tr><td align="left">Leaders</td><td>0</td><td>0</td><td>0</td></tr>
<tr><td align="left">Commanders</td><td>0</td><td>0</td><td>0</td></tr>
<tr><td align="left">Terrorists</td><td>0</td><td>0</td><td>0</td></tr>
<tr><th>Totals</th><td>3-6</td><td>4-7</td><td>6-9</td></tr>
</table></td>
<td><table {{StdCenterTable}}>
<caption><b>Snakemen</b></caption>
<tr {{StdDescTable_Heading}}><th align="left">Rank</th>
<th>Beg./Exp.</th>
<th>Vet./Gen.</th>
<th>Super.</th></tr>
<tr><td align="left">Soldiers</td><td>2-4</td><td>3-5</td><td>4-6</td></tr>
<tr><td align="left">Navigators</td><td>1-2</td><td>1-2*</td><td>2-3</td></tr>
<tr><td align="left">Medics</td><td>-</td><td>-</td><td>-</td></tr>
<tr><td align="left">Engineers</td><td>0</td><td>0</td><td>0</td></tr>
<tr><td align="left">Leaders</td><td>0</td><td>0</td><td>0</td></tr>
<tr><td align="left">Commanders</td><td>0</td><td>0</td><td>0</td></tr>
<tr><td align="left">Terrorists</td><td>0</td><td>0</td><td>0</td></tr>
<tr><th>Totals</th><td>3-6</td><td>4-7</td><td>6-9</td></tr>
</table></td>
<td><table {{StdCenterTable}}>
<caption><b>Mutons</b></caption>
<tr {{StdDescTable_Heading}}><th align="left">Rank</th>
<th>Beg./Exp.</th>
<th>Vet./Gen.</th>
<th>Super.</th></tr>
<tr><td align="left">Soldiers</td><td>2-4</td><td>3-5</td><td>4-6</td></tr>
<tr><td align="left">Navigators</td><td>1-2</td><td>1-2*</td><td>2-3</td></tr>
<tr><td align="left">Medics</td><td>-</td><td>-</td><td>-</td></tr>
<tr><td align="left">Engineers</td><td>0</td><td>0</td><td>0</td></tr>
<tr><td align="left">Leaders</td><td>-</td><td>-</td><td>-</td></tr>
<tr><td align="left">Commanders</td><td>-</td><td>-</td><td>-</td></tr>
<tr><td align="left">Terrorists</td><td>0</td><td>0</td><td>0</td></tr>
<tr><th>Totals</th><td>3-6</td><td>4-7</td><td>6-9</td></tr>
</table></td>
<td><table {{StdCenterTable}}>
<caption><b>Ethereals</b></caption>
<tr {{StdDescTable_Heading}}><th align="left">Rank</th>
<th>Beg./Exp.</th>
<th>Vet./Gen.</th>
<th>Super.</th></tr>
<tr><td align="left">Soldiers</td><td>2-4</td><td>3-5</td><td>4-6</td></tr>
<tr><td align="left">Navigators</td><td>-</td><td>-</td><td>-</td></tr>
<tr><td align="left">Medics</td><td>-</td><td>-</td><td>-</td></tr>
<tr><td align="left">Engineers</td><td>-</td><td>-</td><td>-</td></tr>
<tr><td align="left">Leaders</td><td>1-2</td><td>1-2*</td><td>2-3</td></tr>
<tr><td align="left">Commanders</td><td>0</td><td>0</td><td>0</td></tr>
<tr><td align="left">Terrorists</td><td>0</td><td>0</td><td>0</td></tr>
<tr><th>Totals</th><td>3-6</td><td>4-7</td><td>6-9</td></tr>
</table></td>
</tr></table>
<nowiki>*</nowiki> Needs testing to determine actual number.

==Floor Plan==
[[Image:MediumScout.gif]]

==Terrain Maps==
<gallery>
Image:UFO_110MAP-L1.JPG|Level 0
Image:UFO_110MAP.JPG|Level 1
</gallery>

==See Also==
[[Small Scout]]<br>
[[Large Scout]]<br>
[[Abductor]]<br>
[[Harvester]]<br>
[[Supply Ship]]<br>
[[Terror Ship]]<br>
[[Battleship]]

[[Category: UFO (UFO Defense)]]

Talk:XcomUtil

2008-12-15T05:49:11Z

Wisq: /* Soldiers starting outside of vehicle */

=Misc=
There's still a lot more stuff that could be added here. Also, I've never used some of the flags mentioned, especially those concerning Geoscape/Game executable. More info from those who have used them would be nice.

[[User:Hobbes|Hobbes]] 07:56, 9 Nov 2005 (PST)

=Difficulty Bug=

are there any standalone patches the fix the difficulty bug, or does one just copy over the geoscape.exe file to a new Xcom folder once its patched by using XcomUtil 9becuase of no other alternatives... as you can see, I'm not a fan of it).

I don't know about any patches that fix the difficulty bug. BladefireLight has made a patch that changes the craft back to their original configuration. It can be found [http://www.xcomufo.com/forums/index.php?showtopic=8656 here at the XcomUtil forums]

[[User:Hobbes|Hobbes]] 18:59, 9 Nov 2005 (PST)

----

The difficulty bug is only found in XCOM 1.0, and is fixed with the XCOM 1.4 patch, isn't it?

---[[User:MikeTheRed|MikeTheRed]] 20:16, 9 Nov 2005 (PST)

Unfortunately, no. For the PC, the difficutly bug is only officially fixed in the Windows port - or as I like to call it, 1.4ce.

P. S, it also pays to look at the header whenever posting anything onto the wiki to see if your cookies have let you down and your automatic login setting has been unchecked. This avoids your handle from turning into a mere user IP.

- [[User:NKF|NKF]]

=Backups of .rmp files=
Hey, I wrote up a thingo about the patched geoscape.exe. I'm not sure about the edited Xcom base tiles though, i guess the backups would be called XBASE##.XCU, and the edited, corrected tiles would be XBASE##.MAP. I'm not sure on this because there are *.RMP files within the MAPS folder. Has anyone played around with cutting and pasting things and found out which ones to move to a new fresh install of the game? Thx [[User:EsTeR|EsTeR]]

----

The RMP files are the files used by the AI and I don't think XcomUtil changes those, so the backup .xcu files are the older .map files.

[[User:Hobbes|Hobbes]]

[[User:EsTeR|EsTeR]]: Ok, i'll look into it. Just always thought that RMP go in the routes folder, and maps in maps folder. Yet, there seems to be both types in the maps folder. I guess i'll have a play when i swap puters to fire up Xcom1.

=Is there an X-COM mod editor?=

Is there something out there that lets people do their own mods to the game, such as changing/adding/removing weapons, technology trees, graphics, etc?

----

There's at least one editor that allow to change the weapons: http://www.jennana.com/projects/xcomed.php.
As for the graphics/maps the only way to do it is manually.

[[User:Hobbes|Hobbes]] 18:18, 13 January 2007 (PST)

=RMP files=

Xcomutil does modify the rmp files when generating ship layouts. it just backs up all of them by default.

--[[User:BladeFireLight|BladeFireLight]] 21:50, 15 January 2007 (PST)

=end of development=

Should we note that Scott has oficialy stated he will no longer be deloping xcomutil?

--[[User:BladeFireLight|BladeFireLight]] 21:53, 15 January 2007 (PST)

Done.

[[User:Hobbes|Hobbes]] 07:28, 16 January 2007 (PST)

=New development=
Where do we write to discuss new development? In particular, I just found out that the EQL flag to generate an equipment list can only be done on turn 1 -- and it took me a couple of turns moving equipment around inside the craft before I had everyone at the right cargo level (no one overloaded).
--[[User:Keybounce|Keybounce]] 00:31, 12 July 2007 (PDT)
:: You can try here at these forums [http://www.xcomufo.com/forums/index.php?showforum=79| XCOMUFO], most of us have accounts there as well. [[User:Pi Masta|Pi Masta]] 12:09, 16 July 2007 (PDT)

=Re-setting the ships to the default stats (dead simple)=

Concerning the "But I don't want some features" section - this is a very strange and roundabout way to do this. Just edit the XComUtil.cfg! Scott T. Jones's comments give enough information for anyone to figure it out (even me!)

Perhaps the following text (or something like it) could be added to the actual page:

Opening XComUtil.cfg with any text editor, from lines 548 through 580 you will find the default stats and weapons for all X-Com ships in UFO (and in TFTD as well).

Note that these are the DEFAULT stats. So for example, the Skyranger class assault transport has no weapons hardpoint, and the Interceptor (a high performance plasma-stealth V/STOL MiG interceptor prototype with pulse-detonation engines, perhaps?) can of course NOT carry any troops, equipment or HWPs!!!!

Skipping over the section titled Default Ship Terrain, we come down to the ship and weapon stats that the game actually uses i.e. from lines 615 through 630, you find the UFO stats

and you can see that the Skyranger has a hardpoint, and the Interceptor (absurdly) has a transport capacity similar to a Mi-24.

To fix this, simply edit these numbers. I use the default values, which are given in lines 548 through 580. Then you just re-run XcuSetup.bat.

Happy gaming!

- [[User:Teukros|Teukros]] 12:26, 16 December 2007 (PST)

=SDUMP=

Hey does anyone know where to get some more complete instructions for SDUMP? particularly the syntax of the PATCH ans MERGE features. Scott's page has a bad link to the documentation, and no examples of the above and the "sdump ???" is kinda cryptic and lacks examples. I am trying to patch missdat\uniref.dat with new aliens (appending new records).

- [[User:Fubar|Fubar]]

-------

Here are some examples of it's use:

http://members.aol.com/stjones/xcomutil/xcomhack.html

Though, yeah, they don't cover what you're after. I haven't actually played with it (I either use a hex editor or tools I've slapped together myself).

It would appear the patching feature would be handy if you wished to apply the exact same patch many times (without writing your own software to do so), but for a once off I'd simply find a hex editor that lets you copy and paste values right in.

Keep in mind each UNIREF record needs one or more respective UNIPOS records.

- [[User:Bomb Bloke|Bomb Bloke]] 18:20, 10 February 2008 (PST)

=Crashing=
Whenever I try to start combat using the .bat file it told me to use to run the game, it doesn't start combat, just returns me to the desktop with cmd.exe up.--[[User:Locke|Locke]] 16:34, 26 September 2008 (PDT)

Select the cmd.exe window, and press control-C. The batch file will continue to the combat screen (or back to the geoscape screen if you get this problem after combat). It's a known issue with XcomUtil. [[User:Spike|Spike]] 16:42, 26 September 2008 (PDT)

=Soldiers starting outside of vehicle=

I was having trouble whereby each mission, some troops (sometimes more than half my force) would spawn far away from the landing vehicle, in mid-air. I run Avengers with a load of 10 soldiers, 4 tanks. The tanks always spawn properly.

I suspect this is related to the 'random terrain' feature. It looks like XcomUtil picks new terrain and puts the Avenger in a random place, and tries to move all the troops to match (and makes them face out the windows), but sometimes it 'misses' some soldiers. They're left where the Avenger presumably used to be, all facing forwards, all elevated off the ground. (Thankfully, they have flying suits, and don't hurt themselves when I move them.)

I've disabled random terrain, and now (a few battles later) I think they always all spawn in the vehicle, though some of them are facing forwards rather than out the windows. So it seems XcomUtil is still 'missing' some of them, but the effects are a lot less wacky.

Just a heads-up re: this feature. Spawning outside the vehicle makes it impossible to abort mission without taking losses, unless you can have them make a mad dash back to the lander.   — [[User:Wisq|Wisq]] 18:05, 14 December 2008 (CST)

:The problem might have to do with the map files. Try reinstalling the map files from backups (this will not fix any saved games though). I get these problems when I'm running terrain mods. [[User:Hobbes|Hobbes]] 19:39, 14 December 2008 (CST)

::Hmm, okay. As far as I know, the map files were from a fresh install, but I'm basing this on an archive I made of a fresh X-COM install a long time ago, so I don't know for certain it's clean. I did copy back the xbase* files to recreate the disjoin bug, but that should only affect the base defense missions.

::I re-ran XcuSetup.bat, selected "no" for random terrain, and it seems okay now. I also didn't bother mucking with the xbase* files this time. Mind you, I did get an interesting mission where my ship spawned with the rear ramp embedded in a pyramid... :P   — [[User:Wisq|Wisq]] 23:49, 14 December 2008 (CST)

Talk:XcomUtil

2008-12-15T00:05:12Z

Wisq: