Talk:XcomUtil

From UFOpaedia
Jump to navigation Jump to search

XcomUtil 9.7 Beta

I just made 9.7 Beta available on www.bladefirelight.com Most of the information about XcomUtil on the Wiki will be out of date and need to be reviewed. --BladeFireLight 18:28, 17 January 2010 (EST)

Roger that. I really haven't had time to look at the new changes but I'll see it later Hobbes 19:11, 17 January 2010 (EST)

Build 204

Well, I tried running it, and noticed a few errors in the batch setup system:
  1. 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.
  2. 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)
  3. 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.
  4. EnvClean.bat has an error in line 172: ser -> set.
    • Fixed in build 204.
  5. Note that ansi escape sequences aren't necessarily supported on a real dos environment/emulation.
    • Good point I will move that to DosBox only.
  6. 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.
  7. Thanks for continuing work on XComUtil.
    • Your welcome. I should have started on this sooner.
  8. 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...
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)
  • I uploaded build 204 last night to take care of the goto and "ser" issue, fixed the version display on the DosBox version detection is back on. --BladeFireLight 16:15, 18 January 2010 (EST)
  • 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)

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)

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

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

  • 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:
  1. "Processing" is displayed as the "Operating System".
  2. 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)
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)
  • 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)

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)

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

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)

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

Misc

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

Hobbes 07:56, 9 Nov 2005 (PST)

Difficulty Bug

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

I don't know about any patches that fix the difficulty bug. BladefireLight has made a patch that changes the craft back to their original configuration. It can be found here at the XcomUtil forums

Hobbes 18:59, 9 Nov 2005 (PST)

9.7 will now be verry limited it what It forces to be changed. The difficulty bug and the security questions are still forced. If you just want the difficulty bug fixed. with 9.7 just run XcuSetup and lean on the enter key. --BladeFireLight 19:00, 17 January 2010 (EST)

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

---MikeTheRed 20:16, 9 Nov 2005 (PST)

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

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

- NKF

Backups of .rmp files

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

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

Hobbes


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

Is there an X-COM mod editor?

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

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

Hobbes 18:18, 13 January 2007 (PST)

RMP files

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

--BladeFireLight 21:50, 15 January 2007 (PST)

end of development

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

--BladeFireLight 21:53, 15 January 2007 (PST)

Done.

Hobbes 07:28, 16 January 2007 (PST)

New development

Where do we write to discuss new development? In particular, I just found out that the EQL flag to generate an equipment list can only be done on turn 1 -- and it took me a couple of turns moving equipment around inside the craft before I had everyone at the right cargo level (no one overloaded). --Keybounce 00:31, 12 July 2007 (PDT)

You can try here at these forums XCOMUFO, most of us have accounts there as well. Pi Masta 12:09, 16 July 2007 (PDT)

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

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

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

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

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

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

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

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

Happy gaming!

- Teukros 12:26, 16 December 2007 (PST)

SDUMP

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

- Fubar

Here are some examples of it's use:

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

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

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

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

- Bomb Bloke 18:20, 10 February 2008 (PST)

Crashing

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

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

Soldiers starting outside of vehicle

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

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

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

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

The problem might have to do with the map files. Try reinstalling the map files from backups (this will not fix any saved games though). I get these problems when I'm running terrain mods. Hobbes 19:39, 14 December 2008 (CST)
Hmm, okay. As far as I know, the map files were from a fresh install, but I'm basing this on an archive I made of a fresh X-COM install a long time ago, so I don't know for certain it's clean. I did copy back the xbase* files to recreate the disjoin bug, but that should only affect the base defense missions.
I re-ran XcuSetup.bat, selected "no" for random terrain, and it seems okay now. I also didn't bother mucking with the xbase* files this time. Mind you, I did get an interesting mission where my ship spawned with the rear ramp embedded in a pyramid... :P   — Wisq 23:49, 14 December 2008 (CST)

XComutil has a very ballistic approach to the way it generates maps and populates them. For example if you use the UFO picker or the random UFO floorpan, you'll often find elerium pods lying out in the open in the same formation they were in the original map. Even with the map generation, it doesn't appear to have particular rules as to how to handle the creation some of the map blocks, like terror site roads or the fact that the transport needs to be created in a rectangular block of empty fields (though I feel the Skyranger inside the pyramids is mainly a problem with the more recent changes to the map randomizer).

It seems that it has a few glitches with how it moves the soldiers around. I found it mainly happened to me when I was using the Interceptors as transports, and often my troops would end up off the map - so I stopped using them. I believe the map manipulation side of Xcomutil was a bit on the experimental side, and hasn't had any major updates since Scott stopped working on it. -NKF 03:28, 15 December 2008 (CST)

XComUtil bugs to fix

First of all, kudos to BladeFireLight for cracking on with the updated XComUtil. Great job! Amongst all the other work you are doing, here is a list of things to consider fixing:

  • RPL bug, when you turn creatures into Gill Men, they are reported as Snakemen
  • 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)
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)
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)
  • 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)
  • 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)
  • EQL only works on turn 1 (see discussion above)
Added to my to do list. --BladeFireLight 22:34, 7 February 2010 (EST)
9.7 only has 3 items on by default. Remove copy protection. Fix Difficulty bug and Split EXE (split EXE can be skiped but not the others). All other options are default to NO.
As for the intent of XcomUtil. Scott added features to
  1. Increase difficulty.
  2. Make useless items useful.
  3. Get the game Started faster.
I have added:
  1. Don't make unwanted changes.
  2. Fix game bugs
Yes all of those are very sensible. Spike 19:00, 8 February 2010 (EST)
Latter versions of XcomUtil will turn the last two forced items to prompted. with only the Difficulty bug and the split EXE as Default=Yes. --BladeFireLight 22:34, 7 February 2010 (EST)
    • Basic tanks using advanced tank stats
    • Improved High Explosive - very powerful in favour of X-Com, especially as alien spawn points and routes aren't set up to cover holes in UFO hulls.
    • Gauss weapons have infinite ammo
9.7 has a second option to just the increase power to closer match UFO.
    • 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.
    • 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

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 peeling 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 size of a fully built X-Com base is about the size of a city block (judging by comparison of base defence to terror missions), and should easily be able to hold hundreds of items even in the starting base if it's willing to put some stuff not in the general stores.
  • The space limit makes no sense. Why do Blaster Bombs and Heavy Plasma ammo take so much space whereas in the inventory view it doesn't take any more than normal ammo? Who stores mini tanks HWPs in the same compartment as light weapons? And the way X-Com (probably) stores ammo and explosives is scary...
  • 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)

See Also

Wish List

Retrieved from "https://www.ufopaedia.org/index.php?title=Talk:XcomUtil&oldid=27339"