Combo X-COM Game Folder Patch

[Zombie]

Thanks, and my apologies in turn :-) You are right, I have missed 0 and 1, they should be set to Small. I think the only reason for doing this may be a situation if the aliens (i.e. Ethereals on Medium Scout) took an Xcom tank under control.

 

Nodes 2&3 cannot serve large units because there is no place for southern and eastern parts of them. As far as I know, the node is the place for the NW part of a large unit. You cannot place a tank in the node 2 because there is a UFO wall just south to it, and there is no place for SW/SE parts. For the same reason a tank cannot be placed in the node 3 - there is a wall just east to it, and no place for its NE/SE parts.

 

Tanks cannot be Mind Controlled by aliens, or induced to panic via a psionic panic attack. In fact, if an alien has a choice between MC/Panicking a soldier or a tank, it'll choose the soldier everytime (I tested this a while ago). So the points of having a large unit either spawn on those nodes or even follow them are moot. Sorry if this sounds harsh, but that's the way the game is...

 

Now you could make a very valid argument that maybe a modder decides he wants terror units to show up on Medium Scouts by editing the executable. That could happen. Even then, most maps have plenty of alien spawn points where they could go. In addition, the spawn probability of alien on the perimeter nodes are very low. And if a modder knows enough to edit the .exe, he'll probably know enough to edit the maps himself.

 

Of other changes I have made... have you noticed this bad looking pillar on the 2nd level of Terror Ship, north to the eastern navigation table? I think it has no function at all, and I have removed it. See the map file.

 

Good catch! I'll include that for sure.

 

And X-Base... When many aliens attack, there may be no nodes for some hostile units, especially when there is too few hangars in the base. This is why I have added 9 spawn nodes on Access Lift map, with lower priority than other alien-dedicated nodes. This way 9 additional aliens will be able to spawn if there is such a need.

 

It's a good intention, but a cunning player can still build a base in which you'll auto-win the base attack by forcing your own units to occupy otherwise alien spawn points. (Even with the extra nodes you added, it's still easy. Unless you can cram 40 alien spawn points into the access lift, no amount of spawn points you'll add will make it tougher). Auto-win base defense missions are probably not strictly intended by the programmers, but at this point in time there are whole base building strategies players use which relies on limiting aliens getting into the base to make the fight easier, and I'm not about to start forcing people to change without a choice. And having a high concentration of aliens in one area of the base probably isn't intended by the programmers either (Let's just lob a few blasters at the access lift... base mission over). So I could see this more of a mod than a patch.

 

I will definitely use the rest of your changes though.

 

Good point - although it is possible to point to a death tile located in an MCD loaded after the one you're editing, U_BITS is always loaded last, and you can't link backwards. Since the tables are full and new tiles can't be added, I think that about explains why they weren't linked up to death tiles to begin with.

 

Technically, I could edit the executable and force the game to load the MCD arrays differently. I'm just worried about the other MCD arrays getting broken by destroying any dependencies. Good thought I guess.

 

Is there any way of reducing the number of MCDs a map has? Or are there any unused objects we could remove to make a little room? All we need is one spot...

 

- Zombie

[Bomb Bloke]

Since you mention it, I believe that yes, it would be possible to trim the tables a little.

 

Don't get me wrong, all the tiles are used so none can be removed completely, but things could be shuffled around a bit.

 

For example, take tile 8 in U_EXT02. AFAIK it's only used in one UFO - the terror ship - but it's loaded for all of them.

 

Now, there's a limit of 106 tiles that can be loaded for use with a UFO. Only two ships are on this limit - the supply ship, and the harvestor.

 

The terror ship uses U_PODS, but the other two ships don't. So if that tile (and its death tile, 32) were moved into that MCD file, then those two other ships would only be loading 104 tiles - which means you'd have the slightest bit of wiggle room to add to U_BITS.

 

Of course, this'd mean that U_EXT02 would need to be rebuilt. I've written a program that could facilitate that, MCDAdd, but there'd still be a bit of work involved to get it right. Oh, and just about every UFO would need to have their map updated in order to work with the re-ordered MCDs, which again is something I could write a program to do (given that we're talking about changing something like half the tiles in each map).

 

So yeah, it can be done, but you'd want to work out how the new MCD layouts would be in advance. It may be enough to just move those two tiles I mentioned, but if you're thinking you may want yet more room somewhere down the track, it'd pay to get it all sorted out in one go.

 

Another thing to consider is that shifting that wall tile away means that it'd be trickier to create custom ships, and XcomUtil's UFO generator would become completely broken.

[SupSuper]

One of the things that gives us no end of trouble in developing OpenXcom is coping with the buggy data files. There's only so much we can workaround that would be better solved by just fixing the source, so we've been looking for patches like this to save us from extra work.

 

However, last we tried it, there are some bugs with this patch, like this garbled farm tileset, as well as bugs that aren't covered by it, such as this skyranger LOF bug.

 

If you could save us the trouble of worrying about broken data by fixing all the bugs and making sure the patch works fine with OpenXcom, we would happily link and support it on our website. What do you think?

[Zombie]

However, last we tried it, there are some bugs with this patch, like this garbled farm tileset, as well as bugs that aren't covered by it, such as this skyranger LOF bug.

 

The CULTA18 map shouldn't even be in the download, it's my fault as MapEdit edited and saved it when I did the routes editing but I never verified if I myself made changes to the map file. I saw a updated file in my game folder and put it in the download, not realizing that it was a broken map created by MapEdit. I will remove this soon. And I'll happily add the Skyranger LOF fix too.

 

If you could save us the trouble of worrying about broken data by fixing all the bugs and making sure the patch works fine with OpenXcom, we would happily link and support it on our website. What do you think?

 

Well, not if I see comments like this telling people to avoid my patch kit:

 

AVOID the strategycore combo patch!

it contains AT LEAST one garbled tileset, and causes numerous problems.

 

So, how many more garbled tilesets am I responsible for including (by accident), and what are the numerous problems? I will fix whatever is broken as soon as I know what is so horribly wrong with it. My feeling is that there is some over-exaggerating going on, but I could be wrong.

 

As for "making sure the patch works with OpenXcom", that rests squarely on your shoulders (or one of the other devs). I don't know anything about your project. It should work just fine (once fixed) assuming that none of your changes interfere with the files in the kit.

 

- Zombie

[AMX]

Hi Zombie,

I've asked Warboy for clarification about the "numerous problems," and here's his reply:

most of the problems it causes (for me) are related to the introduction of "new" tiles that have no equivalent in the vanilla tileset, more specifically, in the farm tileset, floor tiles 76, 77, 79 and 80, which appears in Culta17.

the problem arises when i, with vanilla data, try to load someone's bug report save with their modified data, and hit a wall, because they're incompatible, also i notice MANY of the tilesets (like the stables) we know and love have been removed for whatever reason.

the DESERT01 tileset is a "landing zone", and should be flat, not a pyramid, this caused me problems in the original as well as in openXCom.

i have NO problem with bug fixes, but removing content and adding new stuff like this under the heading of a "patch" is WRONG, you've crossed a line and wound up in "mod" territory.

i'd suggest to keep the goal of this project as FIXING rather than MODIFYING the original data.

taken from the readme:

This patch is my attempt to fix all the game folder problems which plagued UFO: Enemy Unknown/X-COM UFO Defense and the intention is to make it developer intended (not a mod).

and from the description on strategycore:

This is not meant to be a mod of the game folders but rather an update of what was intended by the original programmers.

clearly this project has strayed FAR from what it was originally intended to be.

[Warboy]

while i make no apology for my assertion that our TESTERS who are scouring for bugs should avoid using a bugged data set, because it will cause bugs (note that this was posted in a development thread), i feel i must beg your pardon on the apparent harsh tone of my earlier message, i can be quite the bugbear without at least 3 cups of coffee pounding through my system.

 

going over the patch notes... it seems like you may have had a modified set of CULTA/DESERT data from the outset, because i can't see any mention of replacing any existing tilesets. this makes me suspect XcomUtil as the source of our woes, as i'm fairly certain that had some replacement tilesets for those 2 specific map sets.

 

i may have mistaken you as the culprit, as that one garbled tileset lead me to believe all the other problems i have with the data to be your fault, <sarc>because obviously, if one thing is wrong, the whole thing is wrong.</sarc>

 

please allow me to revise my earlier statement:

 

i have no problem with bug fixes, but starting with modded data and calling it a "patch" is a misnomer, you haven't crossed a line into mod territory, you began there, most likely through no fault of your own, other than oversight.

i'd suggest that if you're intending on fixing the original data, it might help to start with the original data.

the project hasn't strayed far from it's intended path, it's on the right path, always was, it just had a false start.

 

as for compatibility with OpenXCom, if it causes a problem with OXC, it will cause the exact same problem in the original, at least as far as map generation is concerned, but don't rely on us as a testbed, because a lot of the bugs that will show up in the original won't show up in OXC.

 

anyway, all this aside, keep up the good work!

[SupSuper]

Well, not if I see comments like this telling people to avoid my patch kit:

 

Quote

AVOID the strategycore combo patch!

it contains AT LEAST one garbled tileset, and causes numerous problems.

 

So, how many more garbled tilesets am I responsible for including (by accident), and what are the numerous problems? I will fix whatever is broken as soon as I know what is so horribly wrong with it. My feeling is that there is some over-exaggerating going on, but I could be wrong.

 

As for "making sure the patch works with OpenXcom", that rests squarely on your shoulders (or one of the other devs). I don't know anything about your project. It should work just fine (once fixed) assuming that none of your changes interfere with the files in the kit.

 

- Zombie

 

Sorry about his tone, but after dealing with lots of obscure untracable bugs haunting us for weeks that end up coming from non-vanilla data, it's a bit of a touchy subject. Players don't know what causes bugs, they can only blame us, and if we can't fix it, we can just tell them to work around the problem.

 

See, OpenXcom's goal is to reproduce original X-Com faithfully. However there is no "official specification" for the data formats that it uses (aside from Ufopaedia etc), so all we can do is follow the vanilla data and hope for the best, testing throughly and working around all the weird issues it has. This works fine until people use it with all the modified data sets out there, from patches like yours, XcomUtil, etc, that make completely undocumented changes.

 

We would love to support them since they often provide a better experience than the original, and we're specially positive about yours since it's only focused on "fixing the bugs" of the original that we have to painfully work around. They should just work like normal, right? Sadly, they end up causing more problems and crashes, and without knowing exactly what the mods change, and not being able to get in touch with the authors to help us, we can't figure out what are the causes of the problems we have to "account for" and end up just having to avoid them.

 

So the point of this is to reach out to mod authors like you, and work together to make sure OpenXcom is fully compatible with all kinds of data out there, so nobody is left behind. You help us by fixing bugs in the original data, testing your mods with OpenXcom (if possible), or tell us what kind of non-vanilla changes you made to the data that could cause problems. We work to resolve any issues on our end, and point people to your mods as officially-supported. The players get to use the mods they want without any bugs or problems. Everybody wins.

[Zombie]

I'm going to quote two posts and address them both at once (hopefully).

 

most of the problems it causes (for me) are related to the introduction of "new" tiles that have no equivalent in the vanilla tileset, more specifically, in the farm tileset, floor tiles 76, 77, 79 and 80, which appears in Culta17.

the problem arises when i, with vanilla data, try to load someone's bug report save with their modified data, and hit a wall, because they're incompatible, also i notice MANY of the tilesets (like the stables) we know and love have been removed for whatever reason.

the DESERT01 tileset is a "landing zone", and should be flat, not a pyramid, this caused me problems in the original as well as in openXCom.

i have NO problem with bug fixes, but removing content and adding new stuff like this under the heading of a "patch" is WRONG, you've crossed a line and wound up in "mod" territory.

i'd suggest to keep the goal of this project as FIXING rather than MODIFYING the original data.

taken from the readme:

 

This patch is my attempt to fix all the game folder problems which plagued UFO: Enemy Unknown/X-COM UFO Defense and the intention is to make it developer intended (not a mod).

 

and from the description on strategycore:

 

This is not meant to be a mod of the game folders but rather an update of what was intended by the original programmers.

 

clearly this project has strayed FAR from what it was originally intended to be.

 

while i make no apology for my assertion that our TESTERS who are scouring for bugs should avoid using a bugged data set, because it will cause bugs (note that this was posted in a development thread), i feel i must beg your pardon on the apparent harsh tone of my earlier message, i can be quite the bugbear without at least 3 cups of coffee pounding through my system.

 

going over the patch notes... it seems like you may have had a modified set of CULTA/DESERT data from the outset, because i can't see any mention of replacing any existing tilesets. this makes me suspect XcomUtil as the source of our woes, as i'm fairly certain that had some replacement tilesets for those 2 specific map sets.

 

i may have mistaken you as the culprit, as that one garbled tileset lead me to believe all the other problems i have with the data to be your fault, because obviously, if one thing is wrong, the whole thing is wrong.

 

please allow me to revise my earlier statement:

 

i have no problem with bug fixes, but starting with modded data and calling it a "patch" is a misnomer, you haven't crossed a line into mod territory, you began there, most likely through no fault of your own, other than oversight.

i'd suggest that if you're intending on fixing the original data, it might help to start with the original data.

the project hasn't strayed far from it's intended path, it's on the right path, always was, it just had a false start.

 

as for compatibility with OpenXCom, if it causes a problem with OXC, it will cause the exact same problem in the original, at least as far as map generation is concerned, but don't rely on us as a testbed, because a lot of the bugs that will show up in the original won't show up in OXC.

 

anyway, all this aside, keep up the good work!

 

First of all, I believe that the problems you mention all stem from XcomUtil's new tilesets for farm and desert terrains. I may have used XcomUtil ages ago, but for the last 5-6 years I have used nothing but archived copies of the Collector's Edition (CE) of the game. Just to be clear, if I was supposedly supplying these modified tilesets with my patch, they would be present in the patch kit download, correct? Please follow the link in my signature, download the patch and look at the files contained within. You will find that they are not there. I just downloaded my kit and applied it to an archived copy of the game, fired up MapEdit and looked to see if there was a pyramid in DESERT01 but it's still flat as always. Same deal with CULTA17, the beloved stables are still present. No new floor tiles either.

 

I don't like to point fingers, but you better make darn sure your "vanilla" copy of the game is indeed original and not tainted by XcomUtil, as that's what my belief is - your files are borked (or your testers). If you want, I can send you the CE data files to peruse. For the health of your project, I strongly recommend you send all of your testers the original data files which would ensure that everyone is on the same page. All it takes is one bad apple to spoil the bunch. In fact, if I were a tester in your project, I wouldn't even use my patch kit. I'd base it off the original, and check if there is a patch for a suspected issue as you go along.

 

- Zombie

[Warboy]

it would seem you are correct, the problem culta/desert files aren't even IN your archive (well, apart from 18 obviously), i must have been applying it to the set of data in my GAME folder which i guess was already messed up by xcomutil, and was comparing it to the files in my WORK folder. i'm relatively sure the files in my work folder are original, they came off a physical CD, but the game folder must have come from the internets. (sometimes CDs are harder to find than torrents)

 

as for sending the game data out to our testers... that's not possible, legally or feasably. at best we can make recommendations as to what they should avoid doing. making sure everyone is on the same page is why we desperately need a "master" patch for all the quirks in the map data, and hence why we're looking to you for help in this matter, as you've already done all the legwork on it.

[Bomb Bloke]

SupSuper asked me to look into this a while ago, though I haven't been checking my emails lately... Among other things...

 

But, just for the sake of clarity to anyone reading all the above:

 

* The Combo Patch doesn't use pre-modded game files. It's clean, and those changes it DOES make are quite simple ones. OpenXcom should certainly have no trouble with it if that can handle the vanilla versions, and indeed, I doubt that it DOES have any trouble with it.

* That said, don't think for a moment that this patch is complete. It takes only a cursory glance at many of the vanilla terrain files to see holes all over the place, so you should fully expect occasional LOF/LOS issues under OpenXcom (even if it DOES handle it in a different manner to the original). TFTD is in much the same sorry state. Isolation between OpenXcom game engine issues and data file issues would be far easier if the original save game format were supported (as this'd allow players to confirm things in both environments), though I realise at this point it's not going to happen.

* I don't know of any mods that add a pyramid to EU's desert. In fact, prior to OpenXcom there was probably just Hobbes making maps (even today there are probably more people who've written modding tools for the game then there are people who've created mods). Unless, that is, someone added UFO2000 map support to OpenXcom?

* XcomUtil modifies a couple of ships and clears the walkways in base modules (to fix the base-disjoint bug). That's as far as it goes when it comes to terrain file modification.

[Tycho]

With the Extender, I've fixed the issue with smoke and fire explosions ignoring walls. The problem was that the routines were checking the smoke reduction value byte of each tile but none are set in any of the tilesets. Instead I have it reference the "blocks smoke" byte, which is set for most tiles. But for some reason, this is not true for many of the XCom Base ones, so you see smoke sprites in the dirt around a room. Another possible issue is that the Wood Farmhouse tiles don't have this byte set either, which may nor may not be as intended. I wonder if its better for Zombie to change these, if he is willing, or should I?

 

With the Extender, I've fixed the issue with smoke and fire explosions ignoring walls. The problem was that the routines were checking the smoke reduction value byte of each tile but none are set in any of the tilesets. Instead I have it reference the "blocks smoke" byte, which is set for most tiles. But for some reason, this is not true for many of the XCom Base ones, so you see smoke sprites in the dirt around a room. Another possible issue is that the Wood Farmhouse tiles don't have this byte set either, which may nor may not be as intended. I wonder if its better for Zombie to change these, if he is willing, or should I?

[Quantifier]

I recently patched xcom with the combo patch, then added my further modifications, and started a new game.

 

I think Lightning is a tiny bit overdone. The outer walls in MCD have BigWall bit set now, and also the first leg has it too. That's exactly the kind of data error in the original game that these patches aim to fix I also wonder, is there a reason why all four invisible pillars have separate entry in pck? I changed it to reuse just one.

 

Another thing broken in original game, but not fixed by patch, is Skyranger - it uses really weird LOS templates in the nose section. I use them fixed with no line of fire possible.

[Bomb Bloke]

I also wonder, is there a reason why all four invisible pillars have separate entry in pck? I changed it to reuse just one.

 

There was indeed a reason for that, though it's an obscure one! Never thought anyone would notice, let alone ask.

 

The "LOF Terrain" sprite generator in my toolkit (which is dead handy for hunting down LOFTemps errors) produces four different images for those four different MCD entries (because their LOFTemps values are completely different, unlike other tiles which share images (eg ramps), which typically only differ by their y-offset). Thus four different PCK records are required in order for that tool to work "correctly" with them.

 

Zombie implemented the bigwall thing. Apparently that's what all the other craft use? Can't remember, and I never checked to see if it was needed. Certainly, I'm having trouble remembering what problem it'd be to use them there.

 

I'd be surprised if the patch currently deals with even half of the issues in the maps. Not that surprised, but still... what it boils down to is that we were still aware of tons of problems, but ran out of interest. I've always intended to do more work on this someday, though if you or anyone else wants to submit tweaked files for the patch pack, please go right ahead. It'd be appreciated!

 

One thing that may be worth keeping in mind is OpenXcom. I've not been keeping track of its evolution, but it wouldn't surprise me they eventually decided to fix some of the map design issues by tweaking the behaviour of the game engine that processes them. Such tweaks might lead to fixes that work in the original, producing entirely different results under OXC... Though I've no idea if that matters to you.

[Zombie]

I remember changing those tiles to be Big Wall. I do know for a fact that the Avenger and Skyranger uses Big Walls for it's sides, so my guess is I was trying to make everything similar. From what I knew at the time, the Big Wall? bit was to make a true north or west wall. I probably just made everything Big Wall as I wanted the Lightning to be completely sealed up. Not sure why the leg would have Big Wall set on it, must've been an oversight or something. If someone knows anything new about the Big Wall flag, let me know.

 

I knew about the odd LOS in the Skyranger ages ago. I figured it was WAI by the devs as it's possible they wanted you to see out. Didn't realize there were any LOF issues with it though.

 

- Zombie

[Bomb Bloke]

There are two main types of walls - north and west, so named because they sit on the northern and western edges of the map co-ordinates they inhabit. Their placement in the actual map data indicates to the game that this is how they should be treated (see here).

 

But what about tiles which aren't suitable for those positions, but you want to use them as "walls" (that is to say, "movement-blockers") anyway? For example, those large dirt blocks used in base maps, or tiles that look like regular north or west walls but sit on the south or east of their tile positions. Those are what the "bigwall" flag is for.

 

Or so it's suspected. The flag doesn't actually appear to do anything important, and for all I know the name is something Daishiva just thought up while making MapView. But it seems to fit, given that those are the types of tiles it's assigned to in the vanilla MCD datasets. It may be that it was originally important, later became redundant as the MCD format had new parameters added to it, and then no one bothered to remove it. There are quite a few data flags that're in the game that don't do anything (the different TU costs for different movement types, for eg).

 

The LOF templates assigned to a given tile determine both how LOS affects it, and how LOF affects it. If you can see through something, then it's generally possible to fire through it, and vice versa. The catch is that units "fire" from a point that's a few points lower than where they "see" from - thus, being able to spot something while standing in a certain location, doesn't always mean you can shoot it from that location (... and again, vice versa).

 

Personally I suspect that the holes in the SkyRanger's window are quite intentional - the developers probably wanted you to be able to look through, and figured that no one would notice you could fire through as well.

[nimd4]

Heh, Googled it and found that there's a "Play in your browser link" @myabandonware.com/ & might as well check it out..

 

https://www.myabandonware.com/game/x-com-ufo-defense-1pl

[3371-Alpha]

I have 2 questions to ask. First, does this combo patch contain all the unofficial patches for Enemy Unknown available in the patches category? Second, is this patch set compatible with Xcomutil?

[Zombie]

First, does this combo patch contain all the unofficial patches for Enemy Unknown available in the patches category?

 

Yes, except the footstep sound effect fix as it's version specific and the CE Bugfix loader and Vista patch.

 

Second, is this patch set compatible with Xcomutil?

 

Yes, as far as I know it's compatible, except if you enable the random UFO ships and such as it'll probably overwrite my changes to those ships.

 

- Zombie

[3371-Alpha]

Yes, except the footstep sound effect fix as it's version specific and the CE Bugfix loader and Vista patch.

I think the american english text patch is also excluded.

Yes, as far as I know it's compatible, except if you enable the random UFO ships and such as it'll probably overwrite my changes to those ships.

Is there a specific order you have to install them? Because I notice xcomutil modifies some of the same files as this patch set regardless if you enable random terrain or not.

[Zombie]

I think the american english text patch is also excluded.

 

Correct. I didn't want to force the American English updates on anyone who prefers the original.

 

Is there a specific order you have to install them? Because I notice xcomutil modifies some of the same files as this patch set regardless if you enable random terrain or not.

 

Depends really on what files XcomUtil is changing. If you know which ones it messes with and why, I might be able to toss together a specific patch to address this, or at least advise in which order to install.

 

- Zombie

[3371-Alpha]

A list of files xcomutil modifies are as follows:

 

LIGHTNIN.MAP

plane.map

UBASE_00.MAP

ubase_01.map to ubase_15.map

UFO_110.MAP to UFO_170.MAP

UFO1A.MAP

xbase_00.map to xbase_20.map

avenger.rmp

LIGHTNIN.RMP

plane.rmp

UFO_110.RMP to UFO_170.RMP

UFO1A.RMP

ufo1.mcd

 

I'm not exactly sure what it does to them, just that it modifies them. Considering that xcomutil's main purpose is to fix bugs, it's quite possible it's applying it's own patches to them. Also note I'm using the older 9.6 version of xcomutil (due to the fact that the latest requires the setup process to be run in Windows and I'm using a Mac).

[NKF]

Those files are the map and route maps for the troop transports, UFOs and alien bases and X-Com base components.

 

For the X-Com transports, main changes were alterations to the spawn points so that soldiers start looking out the Skyranger 'windows' so you don't have to manually turn the soldiers yourself. For the Lightning, it rearranges the troop starting positions. The same with the Avenger. I think in the Avenger's case, it was done for better tank placement. XComutil also restores the Avenger's (non-working) rear door. It's not solid as far as I can remember, so shots will still go through it.

 

In TFTD, XComutil will replace the Hammerhead with its own wider version of the Hammerhead.

 

For the base maps, it knocks down walls to work around the base disjoint bug. The execution is a bit crude with patches of exposed sections of dirt in the walls between each of the modules, but it does the job well enough and prevent you from getting any isolated modules.

 

For alien base maps, the change I know of is rearranging the starting positions in the landing area modules. Soldiers are set to start surrounding the lift. It doesn't work well for tanks as their quarters get share amongst the spawn points. Tanks will reconstitute when moved.

 

I'm uncertain what changes are done to the Ufo map files, but I think it may be for the purpose of floorpan randomization.

 

Before Bladefirelight took over development and made these changes, older versions of Xcomutil would apply these modifications on first run of its installation program. If you did not want these changes, you have to make a copy of these files before installing XComutil, then restore them after XComutil has been set up.

 

- NKF

[3371-Alpha]

So does this mean I have to install this patch set first (assuming I want to keep some of the features)?

Before Bladefirelight took over development and made these changes, older versions of Xcomutil would apply these modifications on first run of its installation program. If you did not want these changes, you have to make a copy of these files before installing XComutil, then restore them after XComutil has been set up.

Although the older xcomutil had issues where it applied certain fixes without asking you (the base wall fix), many, such as the ufo randomization & troop starting positions in skyranger, will be asked to you first hand by the installer.

 

EDIT: according to the ufopedia xcomutil page, xcomutil does indeed contain it's own route fixes. It also contains a fix for the swapped usos in tftd. I'm not sure if it contains any others, nor if they interfere with the fixes in your mod. Also the troop starting positions in skyranger as well as a few other tweaks are actually implemented by the "runxcom.bat" file the utility creates. You can check it out here: https://www.ufopaedia.org/index.php?title=XcomUtil