Talk:XcomUtil

XcomUtil 9.7

9.7 is available on www.bladefirelight.com

Release Notes

New in this version.

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

Removed from this versions

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

Bugs fixed

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

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

Beta Discussion

Build 435

I hope the improved randomness doesn't apply to the Aliens' d100 during AutoCombat. Otherwise, one could load-scum for success. 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. --BladeFireLight 17:41, 11 March 2010 (EST)

In the setup question for sound files: "were replace" should be "were replaced". 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"?

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. --BladeFireLight 01:15, 14 March 2010 (EST)

OK I see, that makes a lot of sense. Spike 06:52, 14 March 2010 (EDT)

---

Does the SHP flag still work, after the changes to how XCOMUTIL.CFG is assembled? I just tried it, after rerunning XCUSETUP.BAT (Dosbox 0.72 under Ubuntu). XCOMUTIL SHP produces no output. XCOMUTIL SHP:CFG WRT writes GEOSCAPE.EXE, but nothing seems to change. During XCUSETUP I see the expected "Patch applied, ship data updated from CFG" (or whatever). Spike 17:40, 16 March 2010 (EDT)

Yes it works fine. your mistyping the command. it's "xcomutil ufoexe shp:cfg wrt" Second argument must be the target folder. Line 42 and 1266 of XcommUtil.txt.

Thanks! And I thought I'd read the manual. Spike 20:31, 16 March 2010 (EDT)

Build 442

Bugs or features?

• BFG random generated a Martian landscape with its signature craters and bunkers for my crashed medium scout mission.
• BFG random generated a forest/farm map for my terror mission in Los Angeles. Nothing wrong with the enemy/civilian units though.
• Randomized small ufo's often seem to have elevators. Could/should it be set so that one level high ufo's would not get an elevator? I saw a 3x3 elevator in a large scout.

--Ras 04:43, 8 July 2010 (EDT)

• BFG will randomly choose a terrain unless you choose prompt in XcuSetup. This is how it's always been.
• Random floor plans is a complicated thing. It will chose elevator rooms defined in the rms file at random. They do look strange but it's the best Scott and I have come up with so far.

--BladeFireLight 21:07, 11 July 2010 (EDT)

Good enough. --Ras 03:42, 12 July 2010 (EDT)

Open Bugs

• There's no Italian text for the Alternate Laser Weapons option. Applying the patch seems to work, but it displays the text for the default laser weapons.

• Anyone want to translate the text into Italian? --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 File:Alien numbers mismatch.zip and File: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. --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. --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. Spike 19:21, 21 February 2010 (EST)

• See this: [1]. In that case, all Gill man (were lobster man before RPL) were reported as snakemen.. 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 --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. --BladeFireLight 18:50, 21 February 2010 (EST)

I'm not so sure about this. See 05:00 mark at [2]. The armour doesn't match the one Gill man should have (per UFOpaedia, at least). Cesium 19:34, 21 February 2010 (EST). See also 04:17 mark at [3] for reason to suspect resistances aren't always changed. It's possible he just was unlucky though... Cesium 19:53, 21 February 2010 (EST)

Actually the function is something like this

#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 );

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. --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. 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. --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. 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. --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 --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? --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. Spike 19:00, 8 February 2010 (EST)

Or maybe change these display-only values so that they reflect the 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. Spike 15:26, 22 February 2010 (EST)

• Research Help from Captured Aliens awards research help without checking first if you have Alien Containment at the base of origin. Resulting in dead aliens helping you with your enquiries! Possibly only applies to AutoCombat? Spike 21:05, 14 March 2010 (EDT)

Ideally it would not only check for containment but also have a research item for it and check on how many scientist days had been reduced since the last combat and use that as a value for how much you get form the aliens still in containment. But that could just be a pipe dream. Checking for containment for now is a good idea. --BladeFireLight 15:35, 16 March 2010 (EDT)

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

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

Fixed Bugs

• don't prevent patching windows version while running in dosbox, or vice versa

• Fixed: XcuSetup can be run independently to the OS RunXcom is used in.

• 4DOS and MS-DOS 5 dont like "-" in variable names.

• Fixed

• Enviroment space reached quickly on most DOS environments.

• Partly Fixed: Requirement has been drastically reduced to to ~1024 use of Command.com /e:xxxx still may be required

• EnvClean.bat has an error in line 172: ser -> set.

• Fixed in build 204.

• ANSI escape sequences aren't necessarily supported on a real dos environment/emulation

• Fixed: ANSI only used in DOSBox

• If all the aliens are down (some of them stunned), the last save is named "AutoCombat" and I end turn, XcomUtil may still run "AutoCombat" phase. This may have slightly different results than end of combat would have had

• Fixed: Autocombat will not run if you have already won.

• A fully loaded Hammerhead's initial deployment has three aquanauts outside the craft.

• Fixed: the unit placement for the default 12 unit craft has been added to XcomUtil.cfg

• Select terrain: doesn't appear until after I select a terrain in BFG prompting

• Fixed

• geodata/obdata.dat gets truncated with selecting any improved weapon.

• Fixed: This happens because a full backup did not complete but XcuSetup does not detect it. Backup script's changed to avoid xcopy timeout on some versions of DOS. (Backups are required by SDUMP to apply patches)

• I get this error during backup "16-bit MS-DOS Subsystem NTVDM has encountered a System Error The handle is invalid."

• Fixed: All NT based OS's now using 32bit EXE's

• You can get X-COM MIA if you abort a mission, even if everyone is in the exit. Possibly a second stage bug only? See File: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. --BladeFireLight 00:23, 24 February 2010 (EST)

• Various second stage bugs - ammo clip recovery, crashes after autocombat of first stage, etc. Mainly for TFTD, but possibly Cydonia in UFO is also affected.

• Fixed: Clip recovery no longer ran between parts of 2-3 part missions. Autocombat only crashes on two part if you are aborting the second stage and the save in slot 10 is from the first stage. Stage comparisons are now done to abort autocombat if you do this.
• Fixed: Multi-part map ammo loss.

• Removal of Small Scout map / Survey Ship map, making it impossible to do these Battlescape missions.

• Fixed: 9.7 only removes the maps if you use the BFG. I hope to have 9.8 not remove them at all. --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)? Spike 08:02, 7 March 2010 (EST)

• NOT Fixed: STEAM doesnt give access by default to the command prompt. If you know how to add that then you should know enough of DOS not to need the STEAM menu. --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? Spike 10:15, 7 March 2010 (EST)

• Fixed: I was unaware that this had been changed. The weapons are not prompted for any change so they should not be changed. I'm reseting them all to defaults and looking to see if Scott had anything about them in the notes. --BladeFireLight 18:11, 7 March 2010 (EST)

• standalone patches the fix the difficulty bug

• Partialy Fixed: 9.7 min install is the difficulty patch and changing Copy protection questions to all 0's.

• Version detection issues with obscure versions (Italian, 1.2a, etc.) causing corruption or lack of patching.

• Fixed: Added support and patching offsets.

• Various default options make the game easier, not harder (harder being the intent of XComUtil, right?). These should not be defaults. (More discussion at Talk:Enemy_Unknown_Extended#Standard_Config_Discussions) E.g.

9.7 only has 3 items on by default. Remove copy protection. Fix Difficulty bug and Split EXE (split EXE can be skipped but not the others). All other options are default to NO.

As for the intent of XcomUtil. Scott added features to

1. Increase difficulty.
2. Make useless items useful.
3. Get the game Started faster.

I have added:

1. Don't make unwanted changes.
2. Fix game bugs

Yes all of those are very sensible. 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. --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 --BladeFireLight 22:34, 7 February 2010 (EST)

• Using transports as fighters (weapon hardpoints)

Optional in 9.7 --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. Spike 20:12, 7 February 2010 (EST)

• FreeDOS breaks horribly during Setup

• This is most likely an issue with the limits of FreeDOS.
  • Actually, this seems to work well for the latest builds (tested with FreeCOM 0.84 under dosemu). Cesium 18:07, 14 March 2010 (EDT)

• EQL only works on turn 1

Fixed

• Units not on the craft during Autocombat are MIA

This has been fixed. Autocombat now processes one round of fatal wounds first. Any surviving units are then marked as in the craft and MIA score removed. --BladeFireLight 18:24, 26 March 2010 (EDT)

XComUtil Wish List

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

Features for 9.7 - Interface, consistency and bug fixes

Categorise Config Options

For each option, in the prompt, note which category of option this is, according your list above. E.g. faster start, making the game harder, making useless items useful, bug fix, variant game, etc. 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. 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

--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. Spike 08:12, 14 March 2010 (EDT)

• Dart Gun

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

Fusion weapons inconsistently exempted from Alternate Laser Tech

• Fusion weapons inconsistently exempted from the "more difficult" energy weapons manufacturing option ("alternate laser Tech"). Blaster Bombs and Blaster Launchers, Fusion hovertanks and ammo, and Fusion Balls and Fusion Ball Launchers - none of these are harder to build or use with the "alternate Tech" option. Why make laser weapons/tanks and plasma weapons/tanks harder but not Fusion weapons? It's not consistent. I wonder if Scott didn't look at these because he never used Blaster Launchers or Fusion Hovertanks, as he considered them to unbalancing already? And ignored FBLs because, well, most people ignore them? But this should be consistent. Or, the "harder weapons" option could be broken down into sub options, e.g. for each weapon technology:
  • Much more expensive (typically: add some exotic materials, 10x workshop space and 10x Engineer hours)
  • Can/can't manufacture the battlescape weapons/tanks (pure alien weapons only)
  • Can/can't manufacture the ammo (pure alien weapons only)

Personally I would prefer it to be all-or-nothing but include the Fusion weapons as being more difficult to make and use. 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. 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? Cesium 07:00, 22 February 2010 (EST)

• This is odd. Autocombat is supposed to skip over civilians when using the kill function. --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. 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:

1. 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?).
2. Deduct dead civs from current stage.
3. 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). 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. --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. 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: --BladeFireLight 18:11, 7 March 2010 (EST)

• • To be honest I would prefer that each soldier without a light source in darkness is 50% effective, each soldier with a light source (personal or squad), is 75% effective. Meanwhile how about this:

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

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

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

Only thing I see is that this must come at the end. The U:- removes the unit from further consideration. --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. 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. --BladeFireLight 18:11, 7 March 2010 (EST)

OK good point! Spike 20:42, 7 March 2010 (EST)

• Area effect weapons (HE, IN, Small Launcher) should have at least the same bonus as effective-on-Auto weapons (+5). This is because they can damage/kill multiple targets. (The AC/HjC should not get both bonuses however.)

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

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

Having tested the HC and AC rules, the first rule (HC-HE) does not work unless you remove the ammo specifier W:-6, making it just a test for an HC. But weirdly the second rule (AC-HE) works fine with its ammo specifier in place. Odd. 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. 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 --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. Spike 18:32, 9 March 2010 (EST)

This rule set might work:

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

• Flying units (either side) should be worth say +/- 5

Not possible for XCom as no statid makes a distinction between Power Suit and Flying Suit. Would be possible for aliens eg:

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

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

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

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

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

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

The second rule doesn't work at all, it looks like it counts all items of types 3-6. The "superiority" function (first value before the hyphen) does not seem to operate, probably because it is a melee weapon. 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.--BladeFireLight 21:01, 9 March 2010 (EST)

OK, if AutoCombat rates stun rods as doing no damage, the lower range of the W: function ("superiority") will likely never work. So we can't tell whether or not a Stun Rod is "effective" vs the current enemy. In general, the Stun Rod is a pretty effective weapon. So instead we generalise and just use something like this rule set:

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

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

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

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

-5   u:4-14 W:3-44		// -5 per Alien with effective Alien Grenade(s) (not -5 per grenade!)

Only one per unit. --BladeFireLight 20:32, 9 March 2010 (EST)

One per unit tested ok too! Spike 20:41, 9 March 2010 (EST)

• AutoCombat victories should award all UFO Components, not just some Navigation, Elerium and Alloys.
• Every Civilian on the map should be a penalty to XCom of maybe -5, due to the distraction effects of trying to save them / avoid killing them.

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

Let me know if I should try to work some of this up as AutoCombat rules. Some of it requires new coding of course, but a lot of it could probably be done with existing rules. 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. --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. 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. --BladeFireLight 20:32, 9 March 2010 (EST)

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

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

• It would be nice to compensate for the Equip Phase Ammo Load Bug Spike 20:57, 16 March 2010 (EDT)

Focused Research Help

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

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

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

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

Features for 9.8+ - New features

TFTD Gauss Tank Research Fix

• Have the option to make the Gauss Tank require only Gauss Cannon research - this can make it more distinct than the Sonic Displacer and maybe slightly useful for a while

• I plan on it. just not this version. --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. Spike 06:58, 7 March 2010 (EST)

I dont have the offsets to the starting money ranges. so I cant do this. --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. 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. 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?" 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.. 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. --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 mini tanks 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. 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. 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. Spike 19:50, 10 February 2010 (EST)

Maybe you can try there:

.text:00439C85 66 81 C5 F4 01                add     bp, 500

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! 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 --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. Cesium 05:57, 14 February 2010 (EST)

Are the preceding bytes the same from TFTD 1 and 2x? --BladeFireLight 17:26, 15 February 2010 (EST)

Yes they are. 81 C3 F4 01 is the add instruction. Cesium 17:48, 15 February 2010 (EST)

Sig for UFO Dos is 81 C6 F4 01 --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 --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. 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. --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. 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)? Spike 04:50, 13 February 2010 (EST)

Yeah, that would be a great improvement. 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. 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. --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 % 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. 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. 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). 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. Spike 16:08, 7 March 2010 (EST)

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. --BladeFireLight 01:38, 19 February 2010 (EST)

Cool! Spike 02:25, 19 February 2010 (EST)

Rebalanced Craft Weapons

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

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

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

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

Fusion Ball Launcher

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

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

Cost Based Approach

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

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

See User:Spike#Cost_Based_Rebalancing

Stat Based Approach

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

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

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

See User:Spike#Stat_Based_Rebalancing

Rebalanced Infantry Weapons

See User:Spike#Balancing_Infantry_Weapons

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

Advanced Laser Cannon

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

Note this isn't a "rebalancing issue" compared to the other weapons - I'm talking about (maybe) balancing for the increased cost of production and lower profit. Cesium 21:41, 16 March 2010 (EDT)

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

Rebalanced X-COM craft

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

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

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

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

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

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

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

SWP switch expansion

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

A few ideas off the top of my head:

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

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

Using XcomUtil without installation

XcomUtil needs installation in order to use it. Installation modifies some things, which the user may not want for some reason. But xcomutil.exe work well with an unmodified game. A good example is just listing things (LST or DIS) but in fact most (or even all) functions of the program do not depend on any changes made by XcomUtil installer - so in fact there is no need for installation. Despite of this, now, in order to use the program without any modification of the game, you must copy XcomUtil files, and next copy manually xcusetup.xcf from another installation to flags. An alternative method is to backup the original installation of the game, next to install XcomUtil, and next to copy back the original installation, with replacing all files.

It would be much simpler just to copy xcomutil.exe, and to have a possibility to run it without all that installing procedure. Unfortunately, as for now it is impossible as xcomutil.exe checks if the package has been installed or not. And if it does not find the flag file, it ends working.

Sherlock 17:58, 30 January 2013 (EST)

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? 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. --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]". 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. 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. --BladeFireLight 11:00, 7 March 2010 (EST)

This has been added --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. Spike 08:02, 7 March 2010 (EST)
  • Try using a different batch interpreter like 4DOS [4] 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). 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. 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:) 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. 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. --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. Spike 17:25, 9 March 2010 (EST)

See [5] 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. Cesium 17:36, 9 March 2010 (EST)

Read The Fine Manual

As otherwise you'll be trying to run a modified Interceptor tactical mission without using the required batchfile, resulting in...

===Crewed Interceptor Issues===

By default, the DOS version (and possibly others) of XcomUtil will allow you to outfit interceptors with a crew and equipment. However, if you attempt to perform a tactical mission of any kind with an interceptor, the TACTICAL.EXE portion of the game will go to a black screen. Pressing escape or enter will cause the game to return to GEOSCAPE.EXE with a mission rating of 0, as if you had never attempted the mission at all. The worst part of this, however, is that the agents and equipment that were on board the interceptor will be lost. This likely occurs for two reasons:

• The tactical portion of the mission fails because no battlescape configurations or terrain exist for the interceptor, since it was never meant to hold crew.
• Upon returning to the geoscape, it is likely that the game "realizes" that interceptors are not supposed to carry crew or equipment, and promptly destroys the passengers and equipment that it is carrying.

I think that the reason for losing the crew and equipment actually is not due to the game waking up to the fact that interceptors cannot hold them. In fact even with the game modded to allow craft to transport said soldiers and material I would be willing to bet that you will still lose them if the battlescape fails due to there being no map for the ship. The reason is because when the mission is started it places those soldiers and equipment on the terrain, but for the craft which aren't normally capable of it the game doesn't know where to place them. Thus when the mission fails none of your soldiers or equipment were actually in the game map to be retrieved, resulting in their loss. In fact it is possible that even with the craft map and modifications to the exe, you may still lose all soldiers and equipment if you don't have XcomUtil to place them on the map built for that mission.Mannon 19:01, 3 April 2011 (EDT)