=XcomUtil 9.7 Beta=

9.7 Beta is available on www.bladefirelight.com

==Release Notes==

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

New in this version.

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

Removed from this versions

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

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

===Build 435===

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

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

==Beta Disscusion==

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

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

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

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

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

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

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

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

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

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

=== Categorise Config Options ===

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

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

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

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

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

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

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

//Darkness
-10 L:-9 u:-2 // Human in Darkness

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

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

//Area Weapons. ToDo: compensating bonus for aliens. should not be cumulative. check if "effective?"
+5 u:-2 W:-4 W:-6 // Human w/HE ammo and launcher HC/GC-HE
+5 u:-2 W:-8 W:-10 // Human w/HE ammo and launcher AC/HjC-HE
+10 u:-2 W:-12 W:-13 // Human w/HE ammo and launcher Sm HE Rkt/Torp
+10 u:-2 W:-12 W:-13 // Human w/HE ammo and launcher Lg HE Rkt/Torp
+10 u:-2 W:-42 W:-43 // Human w/ Stun/Shok Launcher and ammo
+25 u:-2 W:-40 W:-41 // Human w/ Blaster/DP Launcher and ammo

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

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

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

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

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

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

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

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

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

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

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

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

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

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

//Grenades
+5 u:-2 W:1- W:-19 // Human w/o effective ranged weapon but w/ effective grenade(s)
+5 u:-2 W:1- W:-21 // Human w/o effective ranged weapon but w/ effective prox grenade(s)
+5 u:-2 W:1- W:-22 // Human w/o effective ranged weapon but w/ effective HE pack(s)
+5 u:-2 W:1- W:-44 // Human w/o effective ranged weapon but w/ effective Alien grenade(s)

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

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

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

== Features for 9.8+ - New features ==

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

=== Improved Base Comes At Cost ===

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

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

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

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

=== AutoCombat ===

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

==== AutoWithdrawal ====

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

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

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

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

=== Tougher UFOs ===

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

=== Rebalanced Craft Weapons ===

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

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

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

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

==== Fusion Ball Launcher ====

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

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

==== Cost Based Approach ====

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

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

See [[User:Spike#Cost_Based_Rebalancing]]

==== Stat Based Approach ====

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

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

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

See [[User:Spike#Stat_Based_Rebalancing]]

=== Rebalanced Infantry Weapons ===

See [[User:Spike#Balancing_Infantry_Weapons]]

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

==See Also==

[[Wish List]]

= Completed Wish List Items =

=== BFG Default To Unchanged ===

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

= MISC =

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

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

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

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

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

Talk:XcomUtil

2010-03-14T22:07:35Z

Cesium: Move fixed bug

=XcomUtil 9.7 Beta=

9.7 Beta is available on www.bladefirelight.com

==Release Notes==

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

New in this version.

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

Removed from this versions

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

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

===Build 435===

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

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

==Beta Disscusion==

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

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

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

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

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

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

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

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

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

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

=== Categorise Config Options ===

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

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

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

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

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

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

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

//Darkness
-10 L:-9 u:-2 // Human in Darkness

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

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

//Area Weapons. ToDo: compensating bonus for aliens. should not be cumulative. check if "effective?"
+5 u:-2 W:-4 W:-6 // Human w/HE ammo and launcher HC/GC-HE
+5 u:-2 W:-8 W:-10 // Human w/HE ammo and launcher AC/HjC-HE
+10 u:-2 W:-12 W:-13 // Human w/HE ammo and launcher Sm HE Rkt/Torp
+10 u:-2 W:-12 W:-13 // Human w/HE ammo and launcher Lg HE Rkt/Torp
+10 u:-2 W:-42 W:-43 // Human w/ Stun/Shok Launcher and ammo
+25 u:-2 W:-40 W:-41 // Human w/ Blaster/DP Launcher and ammo

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

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

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

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

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

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

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

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

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

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

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

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

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

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

//Grenades
+5 u:-2 W:1- W:-19 // Human w/o effective ranged weapon but w/ effective grenade(s)
+5 u:-2 W:1- W:-21 // Human w/o effective ranged weapon but w/ effective prox grenade(s)
+5 u:-2 W:1- W:-22 // Human w/o effective ranged weapon but w/ effective HE pack(s)
+5 u:-2 W:1- W:-44 // Human w/o effective ranged weapon but w/ effective Alien grenade(s)

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

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

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

== Features for 9.8+ - New features ==

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

=== Improved Base Comes At Cost ===

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

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

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

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

=== AutoCombat ===

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

==== AutoWithdrawal ====

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

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

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

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

=== Tougher UFOs ===

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

=== Rebalanced Craft Weapons ===

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

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

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

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

==== Fusion Ball Launcher ====

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

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

==== Cost Based Approach ====

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

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

See [[User:Spike#Cost_Based_Rebalancing]]

==== Stat Based Approach ====

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

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

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

See [[User:Spike#Stat_Based_Rebalancing]]

=== Rebalanced Infantry Weapons ===

See [[User:Spike#Balancing_Infantry_Weapons]]

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

==See Also==

[[Wish List]]

= Completed Wish List Items =

=== BFG Default To Unchanged ===

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

= MISC =

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

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

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

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

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

User talk:Spike

2010-03-14T21:21:26Z

Cesium: Realistic demand thoughts