Talk:XcomUtil

From UFOpaedia
Jump to navigation Jump to search

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

Open Bugs

  • FreeDOS breaks horribly dering Setup
  • This is mostlikely an issue with the limits of FreeDOS.
  • There's no Italian text for the Alternate Laser Weapons option. Applying the patch seems to work, but it displays the text for the default laser weapons.
  • Anyone want to translate the text into Italian? --BladeFireLight 01:15, 14 March 2010 (EST)
  • 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)
  • 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)
  • 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. In addition to the Psi Strength. Also Firing Accuracy, energy regen rate, movement class... loads of stuff. And of course LOFTEMPS. So with current RPL not changing LOFTEMPS, changed aliens are the wrong size and shape probably. This would be visible using the LOFTEMPS map viewer I suppose. Spike 18:39, 9 March 2010 (EST)
  • I hope to overcome this but Scott's notes point to a technical limitation. --BladeFireLight 22:34, 7 February 2010 (EST)
  • Was it really intended to not have nerfed the Profitability of the Fusion Ball Launcher along with everything else? More generally, the profit nerfing could be revised to be more orderly and more systematic.
I dont really know what Scott intended as for the profiteering off of the changed items. If you want to suggest alternative values I'm open to discussion. --BladeFireLight 22:34, 7 February 2010 (EST)
A preliminary suggestion would be to make the Fusion Ball Launcher similarly difficult to manufacture as the Plasma Beam, so about ten times harder vs the unmodified game. E.g. Workshop space 6 -> 60, 400 -> 4000 Engineer hours. And perhaps require 4 Elerium and 20 Alloys, placing it midway between Laser Cannon and Plasma Beams. These changes (even without the materials) make the FBL unprofitable, like the (modified) Plasma Beam. I'm sure part of Scott's intent was to prevent "Laser Cannon Factories", but "FBL Factories" are 75% as profitable.
General reform of the profitability of manufacturing would require a lot of thought. Suffice to say I don't think any thought went into this for the original game. In reforming the economics of XCom, a basic problem is that realism is at odds with game balance. Realistically, governments would pay handsomely for almost anything XCom can produce. What would be reasonable is to get a moderate rate of return, rising more or less linear with investment (research effort), for all items. For game balance, this could be tweaked down for items that are useful in the game, or have research predecessors / successors that are useful in the game. A simpler case is to say that no item has negative profit, you can at least get 'cost price' back for it. Aircraft should arguably be in this category (since they would sell for 100s of millions which would be totally unbalancing). A rationalisation for nerfing any prices is that the money received by XCom is not the whole sale amount, but just a small commission paid by the Council of Funding Nations, which actually controls the sales and takes (in exchange for its funding) most of the profits. Spike 19:40, 8 February 2010 (EST)
FBLs are already pretty useless, and you want to nerf these further? I'd rather think of a way to make them more useful in-game, otherwise the profit should be kept (Note how it's the mostly useless craft weapons which are profitable - I suspect there was some thought into this..). In comparison, the Laser Cannon profit does get nerfed with XcomUtil, but we get a useful weapon instead. I'd suggest a modified FBL will have a very high elerium requirement, and the power of the weapon should be raised a bit to compensate. Cesium 20:04, 8 February 2010 (EST)
For example: Raise power to 240, and add another charge (almost enough to sink a battleship if a craft has two FBLs loaded), but make it cost 100 elerium to make launcher. Raise hours for Balls by factor of 10. Cesium 20:16, 8 February 2010 (EST)
Actually you're right, it makes more sense to make FBLs viable, instead of (just) nerfing the profits. Obviously high Elerium requirements will make them non-profitable. But of the 2 problems - making things useful and preventing 'factory farming' - I think making things useful is more important. I didn't realise FBLs were not tactically useful. I've never built them, only Plasma Beams. 3 ammo is reasonable, it means that 2 FBL armed aircraft have a good chance to take down a Battleship, if they can fire 9-10 out of 12 fusion balls before they are both killed. But 100 Elerium is way too much for an improved FBL that's only slightly more powerful. I think my suggestion (4 Elerium, 20 Alloys, 10x hours, 10x space) fits with the requirements of other XComUtil-modified weapons. Combined with your suggestion of 3 ammo and 240 damage, I think it would make FBLs useful again, which is one of the original goals of XComUtil.
Of course, it's possible that Scott was cleverly making FBLs useful, by making them so much cheaper (net) to manufacture than Plasma Beams. In an XComUtil modified game, you might well deploy FBLs first, and only work your way up to Plasma Beams later, because of the huge manufacturing costs of Plasma Beams. But personally I think it was an oversight. Spike 17:21, 9 February 2010 (EST)
I've never played with XcomUtil modified lasers, so if you say this fits in better that's fine with me. It's unfortunate it involves increasing space: inventory management is one of the things I hate about the first two X-Coms. I was hired to be a commander, not a supply clerk! A mod which made general stores have 10000 space (like Apoc) would be nice.. Cesium 21:39, 9 February 2010 (EST)
Actually the energy weapon mod means they uses more workshop space to build but not more inventory space to store.
However "An army marches on its stomach ", Napoleon said, by which he meant that wars are won or lost on logistics. Other famous commanders have said similar things. So a general should pay attention to logistics. One of the great things about XCOM is it's not just a tactical game, it's a combined political - strategic - operational - tactical game. Spike 04:37, 14 February 2010 (EST)
  • Zrbite lying around in odd places. Objects lying around in odd places in general - these are map modifying errors, probably only occur when customising terrain etc.
Will be part of an overhaul of the BFG --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)
  • EQL only works on turn 1 (see discussion above)
Added to my to do list. --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 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 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. --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 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. --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 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. --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.
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
  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)

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 Pistole Modification

  • Remove 3rd burst for Pistol - it's already good enough, as NKF has shown
do you have a link to NKF's comments? --BladeFireLight 22:34, 7 February 2010 (EST)
Having trouble finding his comments, maybe he'll show up here! See Rifle_vs_Pistol, also Talk:Squad_Composition_and_Tactics#Starting_Sniper_Weapon. If anything there is a case for the Pistol to be nerfed slightly (eg Damage=20, Ammo=8), or for the Rifle to be buffed. Also worth looking through Weapon Analysis for general thoughts on weapon power and balance. The weapon set in EU is actually remarkably well balanced already.
Further to this - not a bug but it's really wrong for a projectile weapon, a firearm, to have the same accuracy on Auto as on Snap fire (60). Even plasma weapons have Auto accuracy somewhat lower than Snap. If you reduce the Pistol burst mode accuracy by anything less than 2/3rds, the burst function is still useful, but more balanced. Actually even with a reduction of greater than 2/3rds, it would be useful, because of the increased damage at point blank range. Which is perhaps realistic for a burst-mode pistol. 60 Accuracy is higher than any Auto weapon in the game, for what ought to be the least accurate auto weapon. The best auto firearm is the Rifle at 35. Anything over 20 is still a bonus for the Pistol. How about 25? This still gives burst mode a 25% edge over Snap mode at long ranges, and a big improvement at close/point blank. 30 would make it more accurate than a Laser Pistol is on Auto (28), which is hard to justify. Admittedly the Pistol burst mode uses 3x (?) the TUs, so maybe some latitude can be given. Maybe go to 30 Accuracy, then, but no higher. Spike 19:49, 11 February 2010 (EST)
An interesting idea. Scott felt that this was just to make the pistol useful by allowing three snaps to be treated as one action so you dont deal with Reaction fire. The end results is the massive time units and same accuracy. If I lowered the accuracy I would have to lower the time to. I believe there is a reason the pistol doesn't have full auto in the vanilla game. You have seen a military issue full auto pistol? --BladeFireLight 21:15, 11 February 2010 (EST)
Indent reset! I can't remember what my comments were either, but it's probably has to do with the weapon anaylsis and how useful snap shots already are. 'tis a jolly good weapon. I agree that you can't just make the auto mode identical to three snaps - you've got the added bonus of uninterrupted fire for the first two shots. You need to pay this off either with reduced accuracy or increase the usage cost.
For consideration, I was actually fiddling with the weapons a few months back and was testing a 10% accuracy burst mode at 15% TU costs. I think 10 or 15 AP damage. Turned out way-way too powerful a weapon (against soft enemies) - and this was on a rookie I just picked randomly. It was probably too fast, but it still worked fairly well at 10% accuracy. 60% accuracy does feel quite high. -NKF 00:14, 12 February 2010 (EST)
Exactly. The point is that a 3-rd burst makes the Pistol more useful, even if the per-shot accuracy is lower, because you get 3 attempts to kill the target before it Reaction Fires, rather than just one. As long as the net 3-rd accuracy isn't less than a single Snap shot, the weapon has been improved. The break-even point is about 26% accuracy on auto. At this level, 3 rounds have a ~60% chance of getting at least one hit. Even if the 3-rd accuracy was lower than a single Snap shot, you would still get the advantage of multiple hits at very close range. I would strongly suggest no more than 25% accuracy for Pistol auto burst, at the same level of TUs (3x Snap right?). This will definitely still be a significant improvement for the Pistol. Probably what was not fully understood at the time Scott did the original mod, is that the Pistol is arguably already the most effective starting weapon, certainly against the initial opponents. Spike 13:19, 12 February 2010 (EST)

Fusion weapons inconsistently exempted from Alternate Laser Tech

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

AutoCombat issues

  • Day vs Night
    • The Day/night algorithm breaks. For example, at any point when XCom has more than twice as many flare-carrying soldiers than there are remaining aliens, XCom is actually stronger in darkness than it would be in full daylight. Toward the end of a battle this is a very common situation. But fixing the algorithm is tricky. What might work is to give -10 for each Soldier in darkness, reduce from -20 to -10 for each Alien in darkness, then add back +10 for every soldier with a light source. Thus there is no way XCom can go 'net positive' from light sources.
If you have more units then they do you can see more of the battle field. --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
-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. 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. 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. 
+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
+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
+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. --BladeFireLight 20:32, 9 March 2010 (EST)
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

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)

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

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)
Retrieved from "https://www.ufopaedia.org/index.php?title=Talk:XcomUtil&oldid=27787"