Talk:XcomUtil
Revision as of 01:48, 13 March 2010 by Spike (talk | contribs) (→Improved Base Comes At Cost: Details of initial money calculations. Cash value of improved base.)
XcomUtil 9.7 Beta
9.7 Beta is available on www.bladefirelight.com
Release Notes
Build 200
This is a Beta, so backup your files before using. If you have issues pleas post them to XcomUFO.com in the XcomUtil forum.
New in this version.
- Major overhall of the installer (XcuSetup) and the inclusion of 16/32bit exe's to support both DOSBox and Windows Vista/7 x64.
- New subfolders added to hold supporting files making the install c leaner
- New XcuSetup options were added to XcuSetup allowing for silent install and uninstallation.
- New XcuSetup option for debugging the install (XcuSetup debug) creating debug.txt.
- XcuSetup now can have minimal impact on the game.
- All options default to NO.
- Almost all changes are now prompted for (skyranger guns, interceptor as transport, Disjointed Base Bug, etc...).
- Items still done by default:
- Copy protection questions set to 0000000 for UFO 1.0-1.3 and X-Com 1.0
- Difficulty bug fixed in UFO 1.0-1.4 and X-Com 1.0-1.4
- Unique names for all maps in TFTD, Used for Hybrid Games
- XCOMUTIL.CFG is now pieced together and overwritten by XcuSetup (see XcomUtil.txt for how to make permanent changes).
- All game files are restored to the pre-XcomUtil state each time XcuSetup is ran. Any modifications by other utilities will have to be re-applied.
- Recovery of MIA soldiers has been removed as it had a habit of resurrecting all KIA units to.
- Vista/Win7 patch now an option for XcuSetup.
- This will fix the blank screen issue.
- Updated to support the split EXE.
- XcuSetup attempts to fix UAC issues by resetting folder permissions.
- A number of community made fixes are included and selectable with XcuSetup.
- Support for the DOS/Window STEAM Install.
- Windows EXE, just run XcuSetup from windows
- to launch Dos version from Steam Run XcomUtil/SteamSetup.bat to activate menu then lauch from steam.
- Out of the box support for UFO Extender. XcuSetup will detect it and ask if you want RunXcom to use it.
NOTE: If you use DosBox, this requires DosBox 0.72 (Does not work on 0.73)
--BladeFireLight 18:28, 17 January 2010 (EST)
Build 204
- Fix the goto and "ser" issue
- Fixed the version display on the DosBox version detection is back on.
--BladeFireLight 16:15, 18 January 2010 (EST)
Build 219
ok. Just posted Build 219
- New command line argument "nobackup" skips backup only if it has been ran.
- Fix f0ders loader path and option goto so it actually works.
- Fix prompted terrain option to create correct flag file.
- f0ders loader now available to Vista and Win7 users. (I have no idea if this will be of help)
- replace "if exist" on folders with "if exist" on file.
- Allow 0.73 with no command line args (as this is all it brakes)
- %X-COM% to %XCOM% for older OS's
- Fixed the beta message display
- Fixed version display in deader
- Fixed misleading message in SFX install scrip.
--BladeFireLight 22:57, 18 January 2010 (EST)
Build 221
- Fix issue following issue with XcomUtil and STEAM.
- only creating backups of the Windows EXE
- only applying changes to the DOS EXE's
STEAM USERS need to run "Verify Integrity of game cache" before updating to this build. --BladeFireLight 18:02, 20 January 2010 (EST)
Build 305
Some major restructuring of Environment Variables to fit within the limits of the forthcoming DosBox 0.74. Previous LastOp.bat files will no longer work. (should limit XcuSetup's Environment usage to about 980 bytes. Will no longer crash DosBox 0.73 by overrunning environment buffer) Corrected a massive error that caused corruption on x64 systems.
I recommend you uninstall the previous version of XcomUtil before installing this one. (or delete LastOp.bat)
New items:
- Backup and restore of additional folders added.
- Allow install on Unknown OS with warning.
- Re-order some option questions and adjust wording.
- Correct File location that was causing Random ship generation to hang or crash.
- Fixed Vista/Win7 Patch to run on Vista. (Thanks Dangermouse)
- Environment Vars size shrunk. This invalidates previous lastop.bat (Thanks to Peter on the DosBox Team)
- Fix issues with using space in IF statement in dosbox and Dos 5.0
- Clean up environment test variable to free up space
- Backup and Restore: Fixes time out issues on DosBox. Adds progress display.
- Set Default to split EXE.
- Allow xcusetup for Dos games in x64 OS with warning
- Switched compiler to Open Watcom for ResFix and ResINfo
- New code to detect EXE version and adjust Max Research in ResFix and ResInfo
- Resfix will no longer execute on UFO
- Switched compiler to Open Watcom xcomutil xcomutrt and sdump.
- Fixed issues with 32bit structure packing leading to wide spread file corruption
- Fixed Alien Research Help math error
--BladeFireLight 18:28, 6 February 2010 (EST)
Build 317
Don't forget to re-run XcuSetup after you extract the files. For a almost quite install use "XcuSetup lastop skip" If upgrading from pre-305 versions you need to uninstall with "XcuSetup uninstall" and run XcuSetup Fresh.
You can now use XcuSetup in Windows to configure a game you intend to play in DosBox OR run XcuSetup in DosBox and play from Windows. Even on x64 systems. XcuSetup can be slow in Dosbox this will allow for faster setup.
RunXcom now makes on-the-fly choices about x86 vs x64 XcomUtil EXE's and Steam Dos vs Windows. If you have Vista or Win7 x64 and a Steam copy you can switch between Dos/Windows Xcom by either runing from Steam or directly starting RunXcom.
A few caveats for STEAM users. Because of how XcomUtil detects the game, while XcuSetup will apply changes to both EXE's. Running XcomUtil from the command line will only effect the Dos version.
Complete List of changes.
- XcuSetup can be run from windows and RunXcom run from DosBox
- Renamed "New Laser" to Alternate Laser
- SortStats now back in XcomUtil.cfg
- Runxcom now uses x86 or x64 EXE's based on OS at time of execution
- Steam choice of Windows or DOS EXE now based on if RunXcom is started in DosBox.
- Xcomutil settings applied to both EXE's in Steam
- SteamSetup.bat displays message on success.
- Minor error fixes with 4DOS
- Better handling of unknown OS.
- New Steam Menu Options
- Run X-Com Sound Setup
- eXit to Windows
--BladeFireLight 03:21, 8 February 2010 (EST)
Build 333
Some Minor tweaks. Only major thing is I have given up on DOSBox 0.73 it's to buggy and crashes often. Although some of the bug fixes I worked out with the DOSBox dev team will not make it in until 0.75. They tell me most of them will be in 0.74 and it should not have this issue.
Luckily STEAM uses 0.72 and works as expected.
If you run another Command interpreter like 4DOS it should work.
- Random alien craft shape now works.
- Fixed Text color on BFG prompting on UFO under DOSBox.
- XCLoader.exe properly removed on uninstall and Gamefile restore
- Fixed display of Unit type on Fighter as transport prompt.
- Apply of Seb Loader from DosBox fixed.
- Commented RunXcom
- Removed Exit Point and replaced with Pauses in XcuSetup
- Updated DOSBox 0.73 error (to unstable. frequent buffer overflows setting ERRORLEVEL on program exit.)
-Blade FireLight
Build 339
This fixes the issue with 4DOS failing to do an initial backup, that lead to SDUMP being unable to apply patches, that led to empty designation files. 9.6 replaced the Hammer Head map by default. 9.7 does not but the unit placement was never updated. The 12 unit placement section has been added to fix units spawning outside the craft. (Scott's version of the Hammer Head is in the patches folder but requires manual modification of the config files to fully use. )
- Disable stderr redirection on 4DOS
- More debug and ArchFile now able to be run independently
- Add unit placement section for standard Hammerhead.
- Added Apply of Transport Hard Point.
- Fix Missing Terrain on TFTD Very Small
--BladeFireLight 21:14, 12 February 2010 (EST)
Build 340
- Fixed missing label causing exit in build 399.
--BladeFireLight 01:48, 13 February 2010 (EST)
Build 348
Fixed some obscure bugs. Win7 32x on some computers would not run 16bit code(something to to with chip-set drivers and the 16bit xcopy), so now all NT based Windows will use 32bit EXE's. Some STEAM users had issue with the windows EXE either being replace by or replacing the _patched.exe (f0ders loader) I saw this happen but was unable to repeat it. Hopefully the change of not using short file names when long ones can be will fix this issue.
- Fix BFG Prompting Display
- replace delete with del in RunXcom
- 32bit EXE used on most versions of windows.
- Skip copy short file name if can find long file name.
--BladeFireLight 00:44, 14 February 2010 (EST)
Build 350
The EXE download now uses an updated script to prompt for steamsetup (if detected) and start xcusetup. This makes it more "consumer friendly".
- New SFX Installer Script.
- Cleaned up / updated xcomutil.txt and moved to xcomutil folder
--BladeFireLight 18:49, 14 February 2010 (EST)
Build 361
By popular demand the EQL now works on any turn.
- EQL allowed any turn.
- Fix Display of Forced patches for UFO Spanish/Italian
- Fix BFG questions to avoid invalid options.
- Add Xcom UFO Italian Support
--BladeFireLight 19:28, 17 February 2010 (EST)
Build 384
Lots of bug fixes. Hybrid now working, Fixed issues with auto combat and combining clips.
- Fix Hybrid Implementation
- Auto Combat will not run on second half of two part using first parts saved data.
- Auto Combat will no longer run if combat was won.
- MIA Recovery on won combat only
- Auto equip no longer triggers on second part of 2 stage missions.
- Add skip of combine clips if between stages of 2-3 part missions.
- Lost of debug info to in XcomUtil.log
- Add Headers to XcomUtil.log section brakes.
- XcomUtil's Apply action now in debug.txt
- Update and move f0dders read me per his request.
- Fixed typo stopping Lab PSI/MC Screen from working.
- Fix Infinite loop when not splitting EXE
- Fix nonexistent %no% variable
- Limit STDERR redirection to MS OS's
--BladeFireLight 02:44, 22 February 2010 (EST)
Build 413
Fixed Hybrid and Prompted BFG on Windows EXE's. Hybrid now uses Boom Blokes Pallet conversion. (removes lighting artifacts) "XcomUtil uninstall" now removes the hybrid game maps and terrain. Updated the Vista/Win7 patch. Recommend applying if you get odd colors that only go away with a reboot or playing a video in Media Player. Created new Add-on ability to allow others to plug-in to XcuSetup and RunXcom.
- Add-on support added. see XcomUtil\XcomUtil.txt and XcomUtil\Addon\Example.txt
- Restore and Backup ran second time on Hybrid games to resolve issues with cross pollination
- Update Vista/Win7 Patch to address alt + tab color issues. (restores color pallet on next start of Goescape or Tactical. Does not stop the corrupt pallet)
- Create windows flag file to force XcomUtil to update windows EXE when playing Xcom Windows
- Better UFO Hybrid integration and uninstall of copied files.
- Bomb Bloke's Hybrid Pallet Map
- command line option for config file now searches %CWD%\, %CWD%\XcomUtil\ and %CWD%\XcomUtil\Batch\
- Hybrid path detection change to look for \maps\ATLAN00.map OR %1\maps\URBAN00.map
- Move XcomUtRt and LastOp to sub-folders older LastOp moved if it exists.
- All Flags moved to the flags folder.
- If debug.txt exists zero out file (deletion caused problems with WinTail)
- uninstall a few missed files.
- Fix debug log of config flags.
- Fix echo------ error in RunXcom.bat
--BladeFireLight 17:40, 28 February 2010 (EST)
Build 422
- Fixed unit placing where units were placed outside of sub or inside of tanks.
- Fixed Display of Starting Transport and Fighter names for TFTD
- Updated addon example.txt to streamline and clarify a few things.
- Switched to Bomb Bloke updated Color Pallet
- Units who bleed to death no longer rise from the grave. (unless they die the same turn as you kill the last alien)
- Units under mind control when the last alien dies are no longer MIA.
- Fix messed up goto in Line 8 used for addons (Was causing exit of RunXcom)
- Fix RME error
--BladeFireLight 02:33, 2 March 2010 (EST)
Build 435
Original Sound Effects from UFO were re-sampled to work with 1.4 and CE.
- Add Category to option headers.
- Improve randomness by using current time instead of game date/time in srand()
- Added Option to keep Current terrain/UFO to BFG.
- Original UFO 1.2 Sounds for Geoscape and Tactical added as an option for UFO 1.4 and CE.
- Force Split EXE on STEAM. Fixes issues with setup failing.
- Reset Laser/Gauss craft weapons stats to be default.
- Example addon now uses different flag extension to avoid deletion by XcuSetup
- fix issue with Lab Screen on DosBox always screening
Beta Disscusion
Build 219
- Well, I tried running it, and noticed a few errors in the batch setup system:
- The existence of a directory can't be tested by using "if exist". It won't work on real DOS and many DOS emulations. The suggested workaround fails sometimes (see [1] or [2]).
- I dont have access to every platform. Your help on this would be invaluable.
- It's been a long long time since I wrote batch scripts... First, I suggest creating the directories unconditionally (redirect output or clear screen if you're worried about error output). Second, either drop checking for game_1 directory existence afterwards or if you must check for it - write a dummy batchfile into the directory which only runs one command: a command which exits with a specific known errorlevel (probably sdump or other xcomutil binary would work). Then try to run said batch. Then you can test for said errorlevel - if it's there, than the directory exists. Then erase dummy batchfile.
- My solution is similar. i'm using the dum.bin If it dosent exist create the directory with >>%redir% and copy in a dum.bin. should work on any OS.
- It's been a long long time since I wrote batch scripts... First, I suggest creating the directories unconditionally (redirect output or clear screen if you're worried about error output). Second, either drop checking for game_1 directory existence afterwards or if you must check for it - write a dummy batchfile into the directory which only runs one command: a command which exits with a specific known errorlevel (probably sdump or other xcomutil binary would work). Then try to run said batch. Then you can test for said errorlevel - if it's there, than the directory exists. Then erase dummy batchfile.
- I dont have access to every platform. Your help on this would be invaluable.
- Please don't test existence of correct running environment for X-COM in the setup file (e.g. don't prevent patching windows version while running in dosbox, or vice versa). Or at least don't abort the setup, but just print out a warning. This is patronizing - it's none of Xcomutil business, and people who downloaded this probably already know how to run software. Besides, this is likely to ruin at least some possible combinations. Maybe some future bug in dosbox/Windows will make people want to run the setup batch file under cmd.exe/dosbox? Or maybe some people may even want to run XCOM CE in Wine for example, and the check keeps in the way? (Also there's a spelling error - "hoast" -> "host").
- I dont expect everyone who got the game for the first time from STEAM to know their way around the computer. If RunXcom uses 16bit EXE's setup in DosBox in Windows 7 x64 it will throw an error. I could integrate the system checks into RunXcom so It can select the right EXE's however for STEAM and similar setup with both EXE I would have to setup a menu in RunXcom to select what version to actually use if they have Steam on a 32 bit platform.
- I dont intend to support OS2 or Wine like Scott did. What OS's I can support will be based on what feedback I get and what I have the time/interest in fixing.
- Then can you add a parameter to let us override the checks without editing xcusetup? These checks are bound to fail for some OS/dosbox combination now or in the future...
- It's not that simple. The values in the syscheck are required for making decisions. like is the OS x64, is the game UFO or TFTD. does the OS have UAC. will the OS accept SHIM's. Can I find the files needed to run the commands ... --BladeFireLight 20:53, 18 January 2010 (EST)
- Then can you add a parameter to let us override the checks without editing xcusetup? These checks are bound to fail for some OS/dosbox combination now or in the future...
- 4DOS (v7.5 and v8) at least don't like X-COM environment variable name (it returns -COM when doing %X-Com%), and I suspect it may not work under MS-DOS's COMMAND.COM either. Try something like "%X_Com%" for example.
- That will be fixed soon.
- EnvClean.bat has an error in line 172: ser -> set.
- Fixed in build 204.
- Note that ansi escape sequences aren't necessarily supported on a real dos environment/emulation.
- Good point I will move that to DosBox only.
- FreeDOS breaks horribly on the setup files, but I think that's due to bugs on their end.
- I dont know what can be done about that.
- Thanks for continuing work on XComUtil.
- Your welcome. I should have started on this sooner.
- Btw, what's wrong with DosBox 0.73? It sure didn't stop XcomUtil 9.6.. Cesium 09:45, 18 January 2010 (EST)
- 0.73 had two changes. 1. the shell closes the batch file after each line and remembers where it was then reads the file again starting at the next line. (this was to alow for menus that modify themselves. 2. They made shift move %1 to %0. I'm sure you can see what that does. I do a special shift test to detect 0.73. While the basic setup would work none of the command line options would. This was fixed in there current nightly build 2 months back so it will be working in 0.74.
- Grrr. They did this for "self modifying menus" (which don't need this performance killing stupidity) but ignored my patch...
- 0.73 had two changes. 1. the shell closes the batch file after each line and remembers where it was then reads the file again starting at the next line. (this was to alow for menus that modify themselves. 2. They made shift move %1 to %0. I'm sure you can see what that does. I do a special shift test to detect 0.73. While the basic setup would work none of the command line options would. This was fixed in there current nightly build 2 months back so it will be working in 0.74.
- I have verified the new setup works if 4DOS is used under DosBox 0.73 (with some small changes outlined above. 4Dos had to be started with "4DOS /E:16384"). Now to test the game.. Cesium 15:00, 18 January 2010 (EST)
- Well, the Dart gun seems to be still useless. The change gave me an auto shot which takes 3xTU than snap shot but with same percentage...
- This the same as the UFO pistol update. all it's doing is making 3 snap shots with no chance for reaction fire. --BladeFireLight 20:53, 18 January 2010 (EST)
- Small wish: Have the option to make the Gauss Tank require only Gauss Cannon research - this can make it more distinct than the Sonic Displacer and maybe slightly useful for a while...
- I plan on it. just not this version. --BladeFireLight 20:53, 18 January 2010 (EST)
- Well, the Dart gun seems to be still useless. The change gave me an auto shot which takes 3xTU than snap shot but with same percentage...
- The existence of a directory can't be tested by using "if exist". It won't work on real DOS and many DOS emulations. The suggested workaround fails sometimes (see [1] or [2]).
- One other think I noticed (with 200 but that's probably with 204 too), is that if xcusetup is run again after a successful setup, than it restores from backup, then backups the restored files again... Not sure if this is needed. Maybe there's a scenario where it is? Cesium 17:32, 18 January 2010 (EST)
- Yes it does. on DosBox this can be painfully slow to :( The reason for this is Hybrid games or map packs being added sense the last backup. When I have the new BFG and make a C++ version of the XcomUtTE.jar that 9.6 XcuSetup had, this will be of more important. perhaps I will make a command line option to skip backup so you dont have to run it. --BladeFireLight 20:53, 18 January 2010 (EST)
- I've noticed a bug (with 200, but since no in-game changes are mentioned in the changelog, I'm guessing its unchanged): XcomUtil is set to restore previous equipment. I'm packing a few Sonic Pulsars for the first time (I think?), and XcomUtil packs a few Pulsars into one spot in the backpack.. Savegame: [3] Cesium 23:32, 18 January 2010 (EST)
- This behavior has been around since that option was added. see "Automatic Re-Equipment of Troops:" on line 1025 of XcomUtil.txt. I have not modified that section of code. It will be addressed eventually --BladeFireLight 23:39, 18 January 2010 (EST)
Build 221
- Playing further, I noticed that If all the aliens are down (some of them stunned), the last save is named "AutoCombat" and I end turn, XcomUtil may still run "AutoCombat" phase. This may have slightly different results than end of combat would have had. (Also, the score is low in AutoCombat use since all agents are regarded as KIA, but you probably already knew that). Cesium 22:57, 20 January 2010 (EST)
- Autocombat should only run on Abort, and only if: slot ten is named "autocombat" AND it's date,time and combat round match the one just aborted. By "all agents KIA" are you saying they all were killed by auto combat? --BladeFireLight 12:14, 21 January 2010 (EST)
- This is not the case. Set up XcomUtil so that it leaves messages after battle. Then get [4]. Load the game and press "End Turn" - AutoCombat will run when it shouldn't... As for all agents KIA I mean score-wise - I do get them back, but in score display I get points deducted as if they are all dead. Same for civilians at terror sites. I'm using build 200, as there's nothing in the changelogs that suggests changes to XcomUtil's behaviour in-game and I already got it installed.. [Edit: tested with 219 too - still fails] [Edit2: this turns out not to be entirely accurate: agents not in exit locations would be lost after running AutoCombat. Edit date: Cesium 19:44, 30 January 2010 (EST)]
- AutoCombat should only run then tactical exits with abort mission. if it's runing on end turn then tactical is crashing. Can you send me your debug.txt? --BladeFireLight 14:06, 21 January 2010 (EST)
- Well, there's a link to a buggy savegame above so you can verify it yourself (I'm using TFTD v2.1 DOS under DosBox 0.73 right now). I've erased debug.txt and loaded the savegame again - nothing is written to debug.txt. Also, X-COM is behaving fine (mission successful end, etc.) when this is run without XcomUtil. I suspect Tactical is just exiting normally and for some reason XcomUtil just decided to run AutoCombat. Cesium 14:18, 21 January 2010 (EST)
- The debug.txt is created by XcuSetup. it tells me what options you chose and what happend when it tried to apply them. This would give me a baseline to replicate your setup. With 0.73 you cant run "XcuSetup lastop skip" to re-create what it did the last time you ran it Can you either send me the lastop.bat or if you run XcuSetup again with the same options and send me the debug.txt. Then I can get the same configuration your having issues with. (I need to add a CRC check to the before and after conditions of the EXE's to the debug so I can tell if they have changing consistently.) --BladeFireLight 15:44, 21 January 2010 (EST)
- I can run "Xcusetup lastop skip" under DosBox 0.73 if I use a different batch interpreter like 4DOS... Here it is: File:Debug.zip Cesium 16:12, 21 January 2010 (EST).
- That is good to know. The setup should not give an error in that case, if it passes the shift then it could care less. I would think that with a diferent interprater, %COMSPEC% would be somthing other then Z:\COMMAND.COM. am I correct about that?
- Well, in this case COMSPEC isn't changed and than it works fine. If COMSPEC is changed to point to 4DOS, than:
- "Processing" is displayed as the "Operating System".
- setup fails on the "Path to Xcopy" check.
- I tried to use the 4DOS batch file debugger to see exactly where it fails, but it's too unwieldy for this. (Note that 4DOS needs to be started using /E:16384 or something similar, since default environment size is too small). Cesium 02:29, 23 January 2010 (EST)
- It should fail on an Unknown OS. If you have a sure fire way to detect 4DOS i would be happy to add it. I would treat it the same as dosbox.
- It's funny that a DOS program won't work on a real DOS but only on dosbox... It would be a lot easier to make the OS checks not abort, than to try and detect everything... Anyway, you can test for 4DOS like this: 'if NOT "%_4VER%". == "". (then 4DOS)'.
- As for the environment size I'm not surprised it's to small. I use it extensively so I check for a lot of it. I dont know how the larger command.com footprint will effect available memory on a bare mettle dos install. --BladeFireLight 23:05, 23 January 2010 (EST)
- Well, Environment requirement can be reduced, but this is likely to reduce legibility of setup batch. I doubt it's worth it. Even ancient DOS systems had 640KB.. Cesium 00:05, 24 January 2010 (EST)
- It should fail on an Unknown OS. If you have a sure fire way to detect 4DOS i would be happy to add it. I would treat it the same as dosbox.
- Well, in this case COMSPEC isn't changed and than it works fine. If COMSPEC is changed to point to 4DOS, than:
- I will look at the debug and the saved game this weekend or monday. I have to finish migrating all my code to another compiler. XcomUtil was written with Borland 2.0 in mind. I had to use 5.5 for the 32 but but it's giving me fits. So I'm trying to move all the code over to Open Watcom this weekend. It will be nice having debugger to use. --BladeFireLight 01:22, 23 January 2010 (EST)
- Took a look at why the autocombat would run when not intended. If you have the same date/time in the autocombat as the current save and press end turn with with all aliens dead it will trigger autocombat. to avoid this rename the save in slot 10 if your playing the same battle again. --BladeFireLight 17:40, 30 January 2010 (EST)
- OK, so it can run if end turn rather than abort is used (that's not a problem to get around). However, there's a bug: Even though tactical has concluded the aliens are no longer a threat, XcomUtil can still run an AutoCombat against a few "zombie" aliens (I think the uploaded save has this? If not, I probably have an archived save exhibiting this)... X-Com would win, but it might be possible to lose valuable research help from accidentally killing said aliens. I suspect that's due to some stun calculations failing somehow and concluding some stunned aliens can still fight. Cesium 19:40, 30 January 2010 (EST)
- That is good to know. The setup should not give an error in that case, if it passes the shift then it could care less. I would think that with a diferent interprater, %COMSPEC% would be somthing other then Z:\COMMAND.COM. am I correct about that?
- I can run "Xcusetup lastop skip" under DosBox 0.73 if I use a different batch interpreter like 4DOS... Here it is: File:Debug.zip Cesium 16:12, 21 January 2010 (EST).
- The debug.txt is created by XcuSetup. it tells me what options you chose and what happend when it tried to apply them. This would give me a baseline to replicate your setup. With 0.73 you cant run "XcuSetup lastop skip" to re-create what it did the last time you ran it Can you either send me the lastop.bat or if you run XcuSetup again with the same options and send me the debug.txt. Then I can get the same configuration your having issues with. (I need to add a CRC check to the before and after conditions of the EXE's to the debug so I can tell if they have changing consistently.) --BladeFireLight 15:44, 21 January 2010 (EST)
- Well, there's a link to a buggy savegame above so you can verify it yourself (I'm using TFTD v2.1 DOS under DosBox 0.73 right now). I've erased debug.txt and loaded the savegame again - nothing is written to debug.txt. Also, X-COM is behaving fine (mission successful end, etc.) when this is run without XcomUtil. I suspect Tactical is just exiting normally and for some reason XcomUtil just decided to run AutoCombat. Cesium 14:18, 21 January 2010 (EST)
- P.S. Can I get research help from captive at first stage of 2-stage missions? And Has XcomUtil's behaviour for 2/3-stage TFTD missions been improved? Well, I'm doing an Artifact site now, so I'll find out soon anyway... 9.6 used to be real buggy in T'Leth third stage transition (and I have a save game for that too) and IIRC didn't let me get captives from first stage. Never played research help till now though... Cesium 13:41, 21 January 2010 (EST)
- I have only made one change to XcomUtil.exe that that was to remove the MIA recovery. I expect the clip recovery issue will still be their between stages. This is a major frustration to me and I will address it once the installer is stable. --BladeFireLight 14:06, 21 January 2010 (EST)
- I managed to overwrite my own game saves, but eventually I did quite a few two part missions. I notice that sometimes XcomUtil can emit "Divide error" when calculating research help. This seems to happen usually (but not exclusively) when calculating the second part of a two-part... The attached savegame (File:Autocombat research bug.zip - unzip than save slot 10 at "AutoCombat" and abort) has this behaviour. Cesium 08:44, 25 January 2010 (EST)
- I played around with that game and didn't get a "divide error" with vanila 0.72 but it did lockup on me doing the research calculations aborting the second stage if I autocombated the first. I also had tactical skip the equip screen and crash. This will require some more research. --BladeFireLight 18:03, 30 January 2010 (EST)
- I managed to overwrite my own game saves, but eventually I did quite a few two part missions. I notice that sometimes XcomUtil can emit "Divide error" when calculating research help. This seems to happen usually (but not exclusively) when calculating the second part of a two-part... The attached savegame (File:Autocombat research bug.zip - unzip than save slot 10 at "AutoCombat" and abort) has this behaviour. Cesium 08:44, 25 January 2010 (EST)
Build 305
- I haven't played with this yet, but running setup I noticed the following:
- I get this warning when running XcuSetup under 4DOS: "restore.bat [485] Duplicate redirection ">>debug.txt"". It's harmless though.
- This will be fixed in the next build. --BladeFireLight 15:14, 7 February 2010 (EST)
- Redirecting the "attrib -R /S" line to nul would be nice (it outputs a lot under 4DOS, FreeDos and maybe other interpreters).
- Ditto --BladeFireLight 15:14, 7 February 2010 (EST)
- Install on unknown OS doesn't seem to work - it gives "Unable to continue!" right after asking "Shell We Continue?" (without waiting for input). I've tested this on DosBox 0.73 where COMSPEC has been changed..
- Same here. DosBox a number of things missing in the command interprater I relyed on detecting the comspec var to know it's dosbox becaus of the lack of a native find. and if I use a | it only runs the first part. I am re-writing the detection to now use the included 16bit find.com on all but x64 systems to check the ver statement. --BladeFireLight 15:14, 7 February 2010 (EST)
- Why is the sound directory backed up? Perhaps you intend to add an "UFO 1.2 sounds for 1.4" or "Playstation mp3s for UFO CE" options in the future? It seems useless for TFTD though.. Cesium 03:12, 7 February 2010 (EST)
- Yes I intend to include the sound fixes eventualy. While TFTD would not be needed Its more of a pain to skip then to backup. The Geograph folder that is Slooooow. I may limit it to just files I may replace.
- One more thing: I've tried running "command /E:512" with dosbox 0.73 and then running xcusetup. Instead of exiting with an environment space error, the setup breaks in a very odd way (dosbox is stuck and has to be terminated [edit: sometimes this requires running xcusetup more than once to trigger]). Also, the real requirement seems to be more than 980 bytes (unless the check is intentionally pessimistic?). Cesium 03:29, 7 February 2010 (EST)
- the DOSBox team is addressing this in 0.74. It was my complaints of crashing that led to us working on fixing the environment buffer overflow issue. I had to shrink my environment usage to the official size (1088) and they fixed the overflow. --BladeFireLight 15:14, 7 February 2010 (EST)
- Btw, you might be interested in [5]. The thread uses XcomUtil (9.6) multiplayer quite heavily and they probably have bug reports... Cesium 03:15, 7 February 2010 (EST)
Build 317
- Unknown OS now works: I've successfully ran xcusetup under FreeDOS in dosemu.
- DosBox 0.73 doesn't work though.. It gets stuck right after asking whether to apply the bugfixes.
- I wonder why the research fix for TFTD isn't enabled by default? I guess it will be once testing is done? Cesium 12:25, 8 February 2010 (EST)
- Minor problem with XCUSETUP of build 317. Note the missing "what" transports can carry.
-= XcomUtil 9.7 Beta (Build 317) setup =- :: Fighters / Transport :: Change the Interceptor and Firestorm to carry 's [NOTE: modifies Tactical and adds additional map, route and terrain files.] Do you want to enable Interceptor and Firestorm as Fighter Transports? (N)
- This is my first install of the new XCU and I am VERY impressed. Nice job! Spike 19:23, 11 February 2010 (EST)
- Thanks This will be fixed. --BladeFireLight 21:21, 11 February 2010 (EST)
- A fully loaded Hammerhead's initial deployment has three aquanauts outside the craft. This doesn't happen when XcomUtil isn't started (i.e. via TERROR.COM). Cesium 01:54, 12 February 2010 (EST)
- Can you give me a save that is that far along. I dont have one handy. --BladeFireLight 02:10, 12 February 2010 (EST)
- Sure. File:Hammerhead bug saves.zip. Cesium 02:34, 12 February 2010 (EST)
- File:Hbug2.zip. Maybe that would be more convenient for you. Cesium 04:32, 12 February 2010 (EST)
- Can you give me a save that is that far along. I dont have one handy. --BladeFireLight 02:10, 12 February 2010 (EST)
- I've managed to accidentally make a truncated geoscape/obdata.dat file using xcusetup. I uninstalled it, then ran "xcusetup nobackup" (it still made a backup), and chose "n" to everything besides the prompted bug fixed and improved gauss weapons. I'll try to reproduce this.
- "uninstall" removes the backup's. "nobackup" only works if it finds backup files.
- I've also noticed "improved gauss weapons" doesn't change the Heavy Gauss clip power in the entry in ufopedia (should be 80 instead of 75). Cesium 03:03, 12 February 2010 (EST)
- Works for me on Win7 and DOSBox 0.72. --BladeFireLight 15:11, 12 February 2010 (EST)
- I'm talking about the clip page, not the weapon page. TFTD displays the power on both the gauss weapon and gauss ammo pages. Cesium 16:36, 12 February 2010 (EST)
- This must be with remove clip turned on. with just a power increase the damage is not displayed on the weapon. I need to look into disabling clip research as part of removing the clip requirement. for now I can add the damage levels to the clips when removing the need for them. --BladeFireLight 16:43, 12 February 2010 (EST)
- Per description in xcusetup, Heavy Gauss is upgraded from 75 to 80 power even when "Improved Gauss Weapons" change is on, but "Remove Clip" change is off (i.e. gauss weapons still need clips), so the Heavy Gauss Clip page needs to be updated regardless of "Remove Clip" setting in xcusetup (unless you manage to disable clips altogether when its turned on). Cesium 16:58, 12 February 2010 (EST)
- UFOPedia pulls the information from obdata.dat. 4DOS has a number of issues that cascade though out XcuSetup I'm tracking them back. I will have to do some regression testing with 4DOS tonight. Seems redirection of STDERR varies from one DOS to another. --BladeFireLight 18:38, 12 February 2010 (EST)
- Ah, yes. "Real" DOS has no stderr redirection support at all. 4DOS has ">&>" extension, but NT cmd.exe uses "2>". I saw these errors, but thought they were harmless... Cesium 19:20, 12 February 2010 (EST)
- UFOPedia pulls the information from obdata.dat. 4DOS has a number of issues that cascade though out XcuSetup I'm tracking them back. I will have to do some regression testing with 4DOS tonight. Seems redirection of STDERR varies from one DOS to another. --BladeFireLight 18:38, 12 February 2010 (EST)
- Per description in xcusetup, Heavy Gauss is upgraded from 75 to 80 power even when "Improved Gauss Weapons" change is on, but "Remove Clip" change is off (i.e. gauss weapons still need clips), so the Heavy Gauss Clip page needs to be updated regardless of "Remove Clip" setting in xcusetup (unless you manage to disable clips altogether when its turned on). Cesium 16:58, 12 February 2010 (EST)
- This must be with remove clip turned on. with just a power increase the damage is not displayed on the weapon. I need to look into disabling clip research as part of removing the clip requirement. for now I can add the damage levels to the clips when removing the need for them. --BladeFireLight 16:43, 12 February 2010 (EST)
- I'm talking about the clip page, not the weapon page. TFTD displays the power on both the gauss weapon and gauss ammo pages. Cesium 16:36, 12 February 2010 (EST)
- Works for me on Win7 and DOSBox 0.72. --BladeFireLight 15:11, 12 February 2010 (EST)
- Weirdness. I'm using Aliens Help Research and I win a Laser technology every day with 50 Scientists. One day I doubled up and got Laser Rifle and Heavy Laser on the same day (a known, non-XCU bug). Got Laser Cannon in 2 days. Is this supposed to happen with the human tech when you opt for Aliens Help Research? The Alien tech becomes impossible without them. Also I am getting Battlescape crashes, or rather it just skips the Battlescape altogether and replays the results of the previous battle. It also seems to lose the equipment in the transport, revert it to what was in the transport on the previous battle. I'm using the BFG and the Seb76 loader equipment management, that could be part of the problem. Spike 22:00, 12 February 2010 (EST)
- OK I see what's going on. It is prompting me for terrain, but offering not terrain options but light level options. Then after I select a light level, it prompts me for light level, but does not wait for input and goes straight to battlescape, which fails.
0 = Jungle 1 = Farm 2 = Forest 3 = Human Base 4 = Alien Base 5 = Urban 6 = Desert 7 = Mountain 8 = Polar 9 = Mars [here I enter "5"] Select terrain: 0 = Darkness 1 = Twilight 2 = Daylight [here I enter "2"] Select light:
- Basically it seems to be reading my input one step before I am prompted for it, and possibly giving the wrong input for the wrong question. It also is getting stuck in a loop of the BFG prompt. So probably it's a simple logic glitch in the batch file. I will update to the latest build and see if can replicate it. If I can, I will attach the game save file and config files. Spike 08:32, 13 February 2010 (EST)
- I noticed this to. This is the underlying code.
printf( "\nSelect terrain: " );
if ( ESCAPE == ( i = getch() ) )
- The prompt displayed before waiting for a key press. This may be an issue with Open Watcom. --BladeFireLight 18:39, 13 February 2010 (EST)
Build 333
- One can make a truncated geodata/obdata.dat file in builds 317/333. I've run xcusetup, selected nothing but the fixes and improved gauss weapons, and pressed enter for everything else (4DOS/DosBox 0.73). The truncated file prevents the game from starting. Cesium 03:23, 12 February 2010 (EST)
- I think this may be a 4DOS issue. jpsoft.com does not look to support it any more. What version are you on on where do I get a copy? --BladeFireLight 15:08, 12 February 2010 (EST)
Build 340
-= XcomUtil 9.7 Beta (Build 340) setup =- ::Creating Backup Files:: Geoscape Backup ................... OK Tactical Backup ................... None Maps Directory Backup ............. Processing.
16-bit MS-DOS Subsystem Windows Command Processor - xcusetup NTVDM has encountered a System Error The handle is invalid. Choose Close to terminate the application.
version is
Microsoft Windows [Version 6.1.7100] Win7
last debug.txt message is
ResConfig=None
1 file(s) copied.
GeoBak=OK
Copying C:\games\xcom-all\MAPS\AVENGER.MAP
1 file(s) copied
xcsetup goes into a loop, the close option does not stop xcusetup but just loops
Spike 15:41, 13 February 2010 (EST)
- Lovely. I think I know what is going but I dont have a win7 32bit to test on. Do you have a Google Talk account? I would like to test something.
- on a side note. that is not actually a loop. it's copying groups of files at a time to avoid the timeout issue on dosbox. --BladeFireLight 16:40, 13 February 2010 (EST)
Build 361
- There's no Italian text for the New Laser Weapons option. Applying the patch seems to work, but it displays the text for the default laser weapons. Unfortunately, I don't know enough Italian to translate it myself.
- Neither do I --BladeFireLight 21:51, 17 February 2010 (EST)
- There are two places in SysCheck.bat which use "%NO%" (lines 46, 164). I don't see that set anywhere. I think you meant something like "%clErr%NO%clOff%"? It's also possible to remove "set NO=" line from EnvClean.bat.
- Thanks I will fix that --BladeFireLight 21:51, 17 February 2010 (EST)
- Apply.bat has two overt redirections to stderr (lines 830, 831). Since you're doing the stderr redirection support check several times, you may want to centralize it in Xcusetup.bat and than use something like %output%.
- This is why you used to have to do "/E:16384" and why DosBox crashed so often. I have to keep under 950 bytes of environment usage.
- I still have to do "/E:1024" etc. since 4Dos default environment size is 512 bytes. I think it's possible to save a bit more though by using a trick: instead of using %OLDPATH%, save the value of %PATH% to a batch file ("echo set PATH=%PATH >>" etc.) and then run said file after running EnvClean.bat at the end. There's more savings in this approach than just %OLDPATH%, since there are environment variables which tend to exist in DosBox before running xcusetup and can be cleared: %COMSPEC% (unused after DosBox test), %BLASTER% (iff sb emulation is on), %ULTRASND% and %ULTRADIR% (iff gus emulation is on). These can be unset at batch file start to save space and later restored by the temporary batch file. Cesium 20:24, 18 February 2010 (EST)
- All true DOS's only have 512 by default. I had thought about doing something similar with the default.bat and lastop.bat. using a series of of jumps to read it parts and then creating flag files for each setting. This would eliminate the need for most of the environment vars, but it also means another week for the overhaul. --BladeFireLight 21:07, 18 February 2010 (EST)
- I still have to do "/E:1024" etc. since 4Dos default environment size is 512 bytes. I think it's possible to save a bit more though by using a trick: instead of using %OLDPATH%, save the value of %PATH% to a batch file ("echo set PATH=%PATH >>" etc.) and then run said file after running EnvClean.bat at the end. There's more savings in this approach than just %OLDPATH%, since there are environment variables which tend to exist in DosBox before running xcusetup and can be cleared: %COMSPEC% (unused after DosBox test), %BLASTER% (iff sb emulation is on), %ULTRASND% and %ULTRADIR% (iff gus emulation is on). These can be unset at batch file start to save space and later restored by the temporary batch file. Cesium 20:24, 18 February 2010 (EST)
- This is why you used to have to do "/E:16384" and why DosBox crashed so often. I have to keep under 950 bytes of environment usage.
- Xcomutil.txt line 569: Telling the user to reboot isn't the best advice for multitasking OSs... Best to limit that advice to DOS. Cesium 21:03, 17 February 2010 (EST)
- Made sense when it was written. :) --BladeFireLight 21:51, 17 February 2010 (EST)
- I'm looking at the autocombat issue you mentioned above. AutoCombat is designed to kill every alien, no mater if they are unconscious. This has obvious issues with Alien Research. --BladeFireLight 22:42, 17 February 2010 (EST)
Build 384
- Hooray! This build is much better. I did find some stuff on initial check though:
- The number of aliens in the mission report is inconsistent with the number of live aliens captured per research help. See File:Alien numbers mismatch.zip and File:Dead alien count.zip.
- You can get X-COM MIA if you abort a mission, even if everyone is in the exit. Possibly a second stage bug only? See File:X-COM MIA.zip. Note that this only affects the report - after mission all the X-COM troops are still available.
- This happens even on vanilla TFTD with that save. Given it's TFTD it could be an issue with the mapfiles. --BladeFireLight 00:23, 24 February 2010 (EST)
- Morale is random at start of second stage after autocombat of first stage?
- Actually Morale is used as the clip size and time units as the weapon damage. Don't ask me why. It would take a major re-write of auto combat to fix this. --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:
- Count civs from first stage if there was one as dead (since IIRC XcomUtil has no memory of first stage when exiting second stage, so we can't take them into account?).
- Deduct dead civs from current stage.
- Calculate extra dead civs using force ratio to bias the RNG (I prefer merely biasing the RNG rather than precluding results, since Xcom in general has a large variance in almost every gameplay mechanic). Cesium 18:27, 22 February 2010 (EST)
- "if %xOS%. == DosBox. if %xOS%. == 4DOS. if %xOS%. == Unknown. dir *.xcf" - this is not an OR statement. This line will simply never be executed. You can use a goto to emulate if/else and to test the condition only once, e.g.:
if NOT %xOS%. == DosBox. if NOT %xOS%. == 4DOS. if NOT %xOS%. == Unknown. goto win dir ... goto next win: dir /b ... next:
Cesium 07:42, 22 February 2010 (EST)
Build 435
- I hope the improved randomness doesn't apply to the Aliens' d100 during AutoCombat. Otherwise, one could load-scum for success. 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)
Open Bugs
- Various second stage bugs - ammo clip recovery, crashes after autocombat of first stage, etc. Mainly for TFTD, but possibly Cydonia in UFO is also affected.
- RPL bug, when you turn creatures into Gill Men, they are reported as Snakemen
- Reported how? Is this consistent? The name's used are from xcomutil.cfg. --BladeFireLight 18:50, 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 [8]. 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 [9] 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
- I'm not so sure about this. See 05:00 mark at [8]. 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 [9] for reason to suspect resistances aren't always changed. It's possible he just was unlucky though... Cesium 19:53, 21 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 will look into this --BladeFireLight 22:34, 7 February 2010 (EST)
#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 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)
- I hope to overcome this but Scott's notes point to a technical limitation. --BladeFireLight 22:34, 7 February 2010 (EST)
- Removal of Small Scout map / Survey Ship map, making it impossible to do these Battlescape missions.
- 9.7 only removes the maps if you use the BFG. This will be addressed eventually. --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)
- 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)
- 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)
- 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)
- 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)
- Also the xcsetup.bat prompt for the option of less-profitable weapons manufacturing is misleadingly called "new laser weapons". This should be much more clear eg "Much more difficult to manufacture advanced weapons [except FBLs]" or similar.
- This seems to be a common complaint. I will look into better wording. --BladeFireLight 22:34, 7 February 2010 (EST)
- Actually it might be an idea to break this up into sub-options. It does a lot of things! The "new laser weapons" option requires the use of extra alien materials in order to manufacture almost all energy beam weapons (not just lasers). It also makes the human manufacture of the alien plasma beam small arms impossible (research success merely allows X-COM to use captured weapons). The manufacture of craft Plasma Beams is still possible, but is made significantly more difficult (ten times the labour and workspace requirement as well as additional materials). As Scott says this "seriously changes the economics of the game". It also significantly alters the balance of firepower in the air and (to a lesser extent) on the ground. Spike 19:40, 8 February 2010 (EST)
- This seems to be a common complaint. I will look into better wording. --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)
- 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)
- Can you be more specific? --BladeFireLight 22:34, 7 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)
- 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)
- 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)
- 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.
- do you have a link to NKF's comments? --BladeFireLight 22:34, 7 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 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)
- 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)
- 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 [10] 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)
- 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)
- 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)
AutoCombat issues
- Day vs Night
- The Day/night algorithm breaks. For example, at any point when XCom has twice more flare-carrying soldiers than there are aliens, XCom is actually stronger in darkness than it would be in full daylight. Toward the end of a battle this is a very common situation. But fixing the algorithm is tricky. What might work is to give -10 for each Soldier in darkness, reduce from -20 to -10 for each Alien in darkness, then add back +10 for every soldier with a light source. Thus there is no way XCom can go 'net positive' from light sources.
- If you have more units then they do you can see more of the battle field. --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)
- If you have more units then they do you can see more of the battle field. --BladeFireLight 18:11, 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)
- 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)
- 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)
- 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)
- Flying units (either side) should be worth say +/- 5
- Not possible for XCom as no distinction between Power Suit and Flying Suit. Would be possible for aliens eg:
-5 T:0- u:6-6 // Flying Alien - Ethereal -5 T:0- u:8-8 // Flying Alien - Floater
- If the squad is carrying some Smoke or Dye that should be worth maybe +5 - +10. But since the aliens don't ever carry that, you need some balancing factor for them.
+1 u:-2 W:-20 // +1 per human with smoke grenade(s) (hopefully not +1 per grenade!)
- Effective melee weapons should be counted. This is particularly important in TFTD when ranged weapons may be ineffective, e.g. vs Lobstermen.
- Similarly if the enemy are in heavy armour and therefore a soldier/alien does not have an effective weapon, any HE Pack / Alien Grenade / Sonic Pulser should be counted for something (if it is "effective").
//Melee weapons +5 u:-2 W:1- W:-26 // Human w/o effective ranged weapon but w/ Stun Rod +5 u:-2 W:3-26 // Human w/ effective Stun Rod (cumulative to above)
- The second rule doesn't work at all, it looks like it counts all items of types 3-6. The "superiority" function (first value before the hyphen) does not seem to operate, probably because it is a melee weapon. 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)
- 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)
//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)
- Only one per unit. --BladeFireLight 20:32, 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)
- 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)
Fixed Bugs
- standalone patches the fix the difficulty bug
- 9.7 min install is the dificulty patch and changeing Copy protection questions to all 0's.
- Prompted Terrain displays the options but the prompt doesn't display until after a key press.
- I guess Open Watcom's version of printf does not auto flush to the screen like Borland did.
- Version detection issues with obscure versions (Italian, 1.2a, etc.) causing corruption or lack of patching.
- Cesium; XcomUtil doesn't have the offset for the copy protection for the Italian version coded. However the file you sent me is detecting as 1.3. none of the offsets will line up. The offsets Scott used to detect Italian are unique and may have been based on 1.0 or 1.2. Was that a clean unmodified copy? I need a clean one to validate all the offsets and update XcomUtil. --BladeFireLight 13:23, 16 February 2010 (EST)
- I loaded it up and notice it does not ask for a language. this would imply it's based on X-Com 1.3 and not UFO 1.3. --BladeFireLight 13:33, 16 February 2010 (EST)
- I didn't send you the installer since it's a mess (it requires some subst magic to work), but it looks authentic. Use the same link as before if you want to take a look at the installer. There's an Italian readme attached which points to some (now defunct) Italian sites. I didn't do any changes besides installing X-Com and then testing out XcomUtil. Cesium 14:01, 16 February 2010 (EST)
- Italian UFO detection and offsets added, 1.2a offset's fixed.
- I didn't send you the installer since it's a mess (it requires some subst magic to work), but it looks authentic. Use the same link as before if you want to take a look at the installer. There's an Italian readme attached which points to some (now defunct) Italian sites. I didn't do any changes besides installing X-Com and then testing out XcomUtil. Cesium 14:01, 16 February 2010 (EST)
- Various default options make the game easier, not harder (harder being the intent of XComUtil, right?). These should not be defaults. (More discussion at Talk:Enemy_Unknown_Extended#Standard_Config_Discussions) E.g.
- 9.7 only has 3 items on by default. Remove copy protection. Fix Difficulty bug and Split EXE (split EXE can be skiped but not the others). All other options are default to NO.
- As for the intent of XcomUtil. Scott added features to
- Increase difficulty.
- Make useless items useful.
- Get the game Started faster.
- I have added:
- Don't make unwanted changes.
- Fix game bugs
- Yes all of those are very sensible. 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 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 leat $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)
- 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)
- 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)
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)
- 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)
- 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)
Features for 9.8+ - New features
AutoCombat
Firepower Factors
You might want to consider replacing the weapon offensive weighting factors for Autocombat with some factors that are (inversely) related to the % 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
Completed Wish List Items
Easier Inventory Management
Inventory management is one of the things I hate about the first two X-Coms. I was hired to be a commander, not a supply clerk! A mod which made general stores have 10000 space (like Apoc) would be nice.. 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 tanksHWPs 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.
- 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:
- 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)
- 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)
- 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)
- 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)
- Are the preceding bytes the same from TFTD 1 and 2x? --BladeFireLight 17:26, 15 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)
- 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)
- Seb76 13:03, 11 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)