Difference between revisions of "Talk:XcomUtil"
Line 69: | Line 69: | ||
:: 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? --[[User:BladeFireLight|BladeFireLight]] 12:14, 21 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? --[[User:BladeFireLight|BladeFireLight]] 12:14, 21 January 2010 (EST) | ||
− | ::* This is not the case. Set up XcomUtil so that it leaves messages after battle. Then get [http://www.ufopaedia.org/images/c/c3/Buggy_autocombat1.zip]. 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.. | + | ::* This is not the case. Set up XcomUtil so that it leaves messages after battle. Then get [http://www.ufopaedia.org/images/c/c3/Buggy_autocombat1.zip]. 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] |
::: 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? --[[User:BladeFireLight|BladeFireLight]] 14:06, 21 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? --[[User:BladeFireLight|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 [[User:Cesium|Cesium]] 14:18, 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. [[User:Cesium|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.) --[[User:BladeFireLight|BladeFireLight]] 15:44, 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.) --[[User:BladeFireLight|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: [[Image:Debug.zip]]. | ||
::* 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... [[User:Cesium|Cesium]] 13:41, 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... [[User:Cesium|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. --[[User:BladeFireLight|BladeFireLight]] 14:06, 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. --[[User:BladeFireLight|BladeFireLight]] 14:06, 21 January 2010 (EST) |
Revision as of 21:12, 21 January 2010
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:
- 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]).
- 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]
- 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.
- 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)
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.
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)
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)