Combo X-COM Game Folder Patch

[Civilian]

Ok, will do! No problems so far btw.

 

p.s. Some more things to maybe fix: I have been told multiple times that there are some odd translation errors in the german version of the original game, it starts with the language selection screen where it says "Deutsche" but should say "Deutsch" and the HWP cannon rounds ("SWT-Granaten") are accidentally called HWP rockets ("SWT-Raketen") just like the real HWP rockets, which is a bit confusing for beginners.

 

https://i49.tinypic.com/fm7xpe.jpg

 

https://i48.tinypic.com/2hfv0qg.jpg

 

I gonna check the French version for errors later. Mais: Mon francais est tres mauvais.

Translation: But:My french is very bad.

...is it just me or does the german Xcom look... "wrong", English feels so much better with this game

[Bomb Bloke]

The German version looks fine to me...

 

... but that's probably because I don't understand a word of it.

[Zombie]

p.s. Some more things to maybe fix: I have been told multiple times that there are some odd translation errors in the german version of the original game, it starts with the language selection screen where it says "Deutsche" but should say "Deutsch" and the HWP cannon rounds ("SWT-Granaten") are accidentally called HWP rockets ("SWT-Raketen") just like the real HWP rockets, which is a bit confusing for beginners.

Yes, you are correct about the deutsche thing. Deutsche is used in conjunction with something else to show "belonging" eg, Deutsche Bank or Deutsche Telecom. Deutsch is for something just German. It wouldn't be wrong to change it to "Die Deutsche Sprache" as you would then be referring to a language which is German. That wouldn't fit in the game though.

 

I gonna check the French version for errors later. Mais: Mon francais est tres mauvais.

Translation: But:My french is very bad.

...is it just me or does the german Xcom look... "wrong", English feels so much better with this game

The problem with German is that some words just do (or did) not exist. Some things weren't even around so no proper names were given to them - they were just created and may not be the optimum word for the situation. I wouldn't be comfortable trying to translate all the german in-game to something proper as I don't know that many words anymore. I think we need someone from Germany (preferably a Gen X or a learned Gen Y) to do the actual translating as he/she would know what word is proper for a situation. I may know just a person, but I'll need to ask him first. As for the French text, I don't have any ideas.

 

- Zombie

[Civilian]

Sigh, where are the Canadians when you need them?

[Zombie]

Ok, I've been working on updating my patch kit again. This time the focus is on alien bases (mostly).

 

Back on topic here. Have you guys ever brought more than 22 soldiers on an alien base mission? If you came in with a full load of 26 soldiers on an Avenger, 11 will spawn in the green room modules (for a total of 22) while the remaining 4 soldiers will be dumped anywhere inside the alien base. This sounds like a bug to me, no? It can be easily fixed with the addition of a few more spawn points for X-COM units though.

 

I don't usually bring that many either, but it's been around for ages and most prevalent in TFTD where you can get stuck deep into the facility. More nodes - at least to match the Avenger, would certainly fix it.

 

XComutil users may see it cropping up more often with the expanded Avenger, which I think had more slots in it. The alien base entry room files were also updated so that the units all started around the grav-lift. Can't remember if it expanded the nodes.

 

I wasn't really sure how many soldiers fit on XcomUtil's extended Avenger, so I added a bunch more nodes to the grav lift module to be safe. Whereas before you could only have 22 spawn points for X-COM units, it now stands at (admittedly a slightly bloated) 36 which should cover all possible scenarios. All the extra nodes I added are on the second level so there shouldn't be a major difference in functionality, except for perhaps a reduced chance to spawn on the first level for those two spawn points. (My calculation shows a 6.4% chance to fill the two nodes below before and a 3.7% chance now, but I don't see a need to increase the spawn probabilities of them since it's safer to be placed upstairs). Here, I took a couple screenies - old then new:

 

 

As you can see, the old UBASE_04 module is a real mess in terms of spawn points. I cleaned it up and shifted most of the nodes closer to the lift in order to accommodate the additions. By the way, I really didn't need to clean up the links between the nodes (or even include them) as those are only used for AI pathfinding and there is a linkage between the two floors which already exists, but I figured why not. It looks more polished anyway.

 

The other changes I made is to the Medium Scout, Large Scout and Supply Ship. Yes, I realize that I fixed those ships before in my patch kit, but somehow I overlooked the fact that these ships do not have 2x2 aliens and thus do not need large-reserved alien spawn points. I also changed a node in the alien base command center upper floor from a waypoint node to a spawning node for another alien/commander. Reason being, on superhuman difficulty there can be 4 leaders and 1 commander... the 4 existing leader/commander nodes are always filled with leaders first and thus the commander is placed anywhere on the map where there is room. With the change, the leaders and commander should all spawn within the command center module. This is probably what the devs intended.

 

Just to note, I haven't updated my patch kit with these changes yet - I'm still working on some minor updates and would like to wait for any feedback.

 

- Zombie

[Tycho]

Do you think you'll ever clean up the nodes in Terror? They really need a lot of attention. I expect that is why so many aliens are "hiding" on the maps.

[Bomb Bloke]

Sounds good. I hummed and harred about the large node removal, but even if a mod wants to assign larger aliens to those ships, they're probably better off spawning somewhere else on the map rather then inside a ship they can't escape from.

 

A couple of notes;

 

I've probably updated the current release of the patch kit with a few minor changes since you last played with it, though the only thing that actually comes to mind at the moment is the addition of the updated Lightning map (which was missing for whatever reason). See this thread for a few details.

 

I uploaded a fix for a TFTD RMP here somewhat recently. While there are definite problems to be found elsewhere in that game's nodes, I suspect there's more to it then that when it comes to spawning - this wiki chat has some interesting notes about it.

[Zombie]

Do you think you'll ever clean up the nodes in Terror? They really need a lot of attention. I expect that is why so many aliens are "hiding" on the maps.

 

Yes, I fully expect to work on TFTD sometime in the near future. It'll be a monumental task cleaning up all the mistakes the map programmer(s) made.

 

Sounds good. I hummed and harred about the large node removal, but even if a mod wants to assign larger aliens to those ships, they're probably better off spawning somewhere else on the map rather then inside a ship they can't escape from.

 

Actually the nodes I was referring to were outside the craft - around the perimeter. But those nodes are linked to inside the craft so I would expect modded large units to block the doorway - and that's not good.

 

I've probably updated the current release of the patch kit with a few minor changes since you last played with it, though the only thing that actually comes to mind at the moment is the addition of the updated Lightning map (which was missing for whatever reason). See this thread for a few details.

 

I recalled you posted about some changes you made with a transparent pixel in the hangar and the Lightning. Not really sure what went on with the Lightning while I was gone - what happened? Did the change to the new files system remove the Lightning fixes in the patch kit? Or was it an oversight?

 

I'm not using an old copy of my kit - I downloaded it from the site a few weeks back and am using that to make edits.

 

I uploaded a fix for a TFTD RMP here somewhat recently. While there are definite problems to be found elsewhere in that game's nodes, I suspect there's more to it then that when it comes to spawning - this wiki chat has some interesting notes about it.

 

Yep, I identified that problem a long time ago, but never got around to fixing it. I'll be sure to use that in a TFTD patch kit. I just looked at the GRUNGE12 module and think I narrowed the issue down to spawn point 11. Something is really wrong with that node (MapView crashes and complains about out of range or out of bounds). That would explain aliens spawning in "dirt" - if the node is corrupted and the pointer not defined, it's probably using the pointer address which is in memory and that could be anything.

 

Edit: turns out the "Rank" of that node was set to 9 which is undefined. My assumption is the programmers wanted to use a rank of 8 which is Misc2, or possibly a rank of 6 which is Misc1. Not sure which one is intended as there is another node in the module which is Misc1. Editing the node to Misc2 value prevents the crash so I guess it's "fixed" (haven't tested to see if this prevents aliens from spawning in "dirt" or not). Still not sure what rank Misc2 or Misc1 is though, and that's after reading the wiki too.

 

- Zombie

[Bomb Bloke]

I recalled you posted about some changes you made with a transparent pixel in the hangar and the Lightning. Not really sure what went on with the Lightning while I was gone - what happened? Did the change to the new files system remove the Lightning fixes in the patch kit? Or was it an oversight?

The updated MAP file didn't exist in either the individual Lightning fix pack nor the combo fix pack, only the MCD/PCK/TAB files were there.

 

I just looked at the GRUNGE12 module and think I narrowed the issue down to spawn point 11. Something is really wrong with that node (MapView crashes and complains about out of range or out of bounds). That would explain aliens spawning in "dirt" - if the node is corrupted and the pointer not defined, it's probably using the pointer address which is in memory and that could be anything.

Did a check myself, and I can see the unit hiding in the wall is on node 28. You'll know why that node's in a wall when you find it. Here's a tip: It's not in MapView.

[Zombie]

The updated MAP file didn't exist in either the individual Lightning fix pack nor the combo fix pack, only the MCD/PCK/TAB files were there.

 

Hmmm, yeah all my archived copies just have MCD, PCK and a TAB file for the Lightning, Must've missed the MAP file for some reason.

 

Did a check myself, and I can see the unit hiding in the wall is on node 28. You'll know why that node's in a wall when you find it. Here's a tip: It's not in MapView.

 

Can I ask how you found that a unit is on node 28 when it's not in MapView? Is one of your editors able to do that? Anyhow, yes I see what you mean with that node. It has (y,x) coordinates of (254,246) which is obviously out of bounds. And of course, the z coordinate is 1 which translates to L3 which puts it in the black "dirt". (Why the devs used such an odd numbering scheme for the z coord is beyond me, The lowest level should be 0 or 1 and work it's way up as you increase in levels. I guess they were working their way down from ground level, but it's still counter-intuitive). To add insult to injury, the node also has a spawn priority of 5 which means there is a high probability of spawning a unit there. Perfect storm it seems.

 

I looked at the maps a bit to see if node 28 was meant for a different level in the module, but it doesn't look like it is. Nothing links to it either, so it looks like it's just a garbage node as best as I can tell. Suppose I can delete it and renumber the other nodes to fix it.

 

Edit: couldn't seem to get the renumbering idea to work as MapView crashes when I try to look at the lowest level. (Deleted node 28 via MS-Edit, renumbered the links from the ex-nodes 29, 30 & 31 to 28, 29 & 30 but that doesn't seem to work as far as MapView is concerned). No worries though, I just edited the spawn priority of node 28 from 5 to 0. That'll fix it.

 

 

 

- Zombie

[Tycho]

 

Edit: couldn't seem to get the renumbering idea to work as MapView crashes when I try to look at the lowest level. (Deleted node 28 via MS-Edit, renumbered the links from the ex-nodes 29, 30 & 31 to 28, 29 & 30 but that doesn't seem to work as far as MapView is concerned). No worries though, I just edited the spawn priority of node 28 from 5 to 0. That'll fix it.

 

 

Did you try to use a hex editor to set valid variables for node 28 and then let Mapview delete the node properly?

[Bomb Bloke]

Disabling spawning on that node should be fine, but I'm a bit worried as to what might happen if that map module is loaded first/last in the module list. It might be possible for the node to get bumped out of bounds, and who knows how the game would deal with that.

 

Giving it valid locational data then using MapView to delete it should indeed deal with the re-ordering of the other nodes automatically.

 

Yes, my battlescape editor can show you all route nodes in a save if you tap D a few times (which cycles through various statistical display modes). They can still be hidden under units or terrain features due to the way the rendering engine works, so Ctrl+X/C/V can be used to cut/copy/paste the former out of the way, while Ctrl+S/D/F works for the latter. F and L toggle-fog-of-war and lighting effects respectively.

 

So given that the Hallucinoid sitting in a wall was pretty easy to find, the process involved clearing the cruft out of the way to reveal that it was sitting on node 118, and once I tracked down the location of 119 and matched that to node 29 in Grunge12, the rest was fairly easy to figure out with MapView and a hex editor.

 

However, the fastest way to search for other such nodes would have to be to inspect the RMP files directly. Dunno if there ARE any others with that particular problem, but I'll scribble up a program to perform a bulk check tomorrow maybe - have it read up all the node locations and compare them to the dimensions of the maps they're supposed to live in.

[Zombie]

Did you try to use a hex editor to set valid variables for node 28 and then let Mapview delete the node properly?

 

Giving it valid locational data then using MapView to delete it should indeed deal with the re-ordering of the other nodes automatically.

 

Disabling spawning on that node should be fine, but I'm a bit worried as to what might happen if that map module is loaded first/last in the module list. It might be possible for the node to get bumped out of bounds, and who knows how the game would deal with that.

 

Ah, thanks. Editing the node to a proper location in the module and then deleting via MapView worked. Still don't understand why brute force editing the routes file didn't.

 

I really don't think disabling spawning on the node will cause any more crashes. I mean, the node location is already basically out of bounds to begin with. And if an alien can still spawn in dirt from a garbage node, it should be able to spawn completely off the map (disabling spawning on the node should prevent that anyway). Besides. I've had aliens spawn off the map before with no crashes.

 

Here's the new fix, just in case someone needs it now (deleted the fix from my previous post).

 

Grunge Fix.zip

 

So given that the Hallucinoid sitting in a wall was pretty easy to find, the process involved clearing the cruft out of the way to reveal that it was sitting on node 118, and once I tracked down the location of 119 and matched that to node 29 in Grunge12, the rest was fairly easy to figure out with MapView and a hex editor.

 

However, the fastest way to search for other such nodes would have to be to inspect the RMP files directly. Dunno if there ARE any others with that particular problem, but I'll scribble up a program to perform a bulk check tomorrow maybe - have it read up all the node locations and compare them to the dimensions of the maps they're supposed to live in.

 

That would be grand. Identifying the problem nodes (if any more exist) would really save a lot of time as manually verifying each node in MapView against the file itself would be very annoying. If you could get it to work for EU too, that would help (don't think there are many problems in EU as I've been over those maps hundreds of times and even cataloged a few map types: X-COM base, alien ships, cydonia, but it would be great to verify everything).

 

- Zombie

[Sunflash]

Just fyi, you guys boggle my mind.

 

"Eh i'll just spend an afternoon and snap together a program to do this, no sweat".

 

afk weeping tears of jealousy.

[Zombie]

"Eh i'll just spend an afternoon and snap together a program to do this, no sweat".

 

That's classic BB for you. I have him so well trained, I don't even need to ask anymore!

 

By the way BB, if you write up a program for checking orphaned/out of bounds nodes, could you add a feature to check for rank (byte 20) as well? I've been seeing a lot of nodes with a rank of 9 in TFTD and those values are undefined which causes MapView to crash if you click on them. Of course, if it's too much bother, just forget it - I can always just click on a node in MapView to see if anything is wrong (which is what I've been doing).

 

- Zombie

[Bomb Bloke]

An evening? Not even an hour for a few dozen lines of easy comparison coding.

 

Anyway, plonk this in a game folder and run it, it'll generate a "rmpscan.txt" for you to read through. The results are rather verbose, so I won't list any samples here, but suffice to say it lists out every single RMP it finds along with any "problems" it might identify. Currently it checks for node positions exceeding map dimensions, ranks exceeding 8, and one-way patrol routes. Works on either game of course.

 

A quick check of the TFTD files suggests that rank 9 isn't all that uncommon, though it never goes higher. I suspect the game DOES have a valid use for that value, even if MapView doesn't like it.

 

rmpscan.zip

[Zombie]

Anyway, plonk this in a game folder and run it, it'll generate a "rmpscan.txt" for you to read through. The results are rather verbose, so I won't list any samples here, but suffice to say it lists out every single RMP it finds along with any "problems" it might identify. Currently it checks for node positions exceeding map dimensions, ranks exceeding 8, and one-way patrol routes. Works on either game of course.

 

Thanks a ton! Works like a charm! So far I'm fixing up the problems in EU (not too many, all things considered).

 

A quick check of the TFTD files suggests that rank 9 isn't all that uncommon, though it never goes higher. I suspect the game DOES have a valid use for that value, even if MapView doesn't like it.

 

Hmm, yeah. I wonder what type of unit is supposed to spawn on a node with a rank of 9 though? Possibly a terrorist?

 

- Zombie

[Zombie]

Ok, I looked at the following issues which BB's routes checker identified:

 

CULTA05 - Fixed. Linked node 0 to 1.

CULTA06 - Fixed. Linked node 0 to 1.

CULTA18 - Fixed. Linked node 8 to 13.

 

In the same module, node 15 links to 1, but node 1 doesn't link to 15. Didn't fix - node 1 's link fields are full. Not that big of a deal anyway as node 1 indirectly links back to 15.

 

LIGHTNIN - Invalid y&z coord's on node 0. Deleted node. Not sure which level the dev's wanted this node to go. Can't be the ground level as that level is fine. The upper levels require a flying unit to reach, but nothing links back down to the ground or to another node. Supposed to be an engineer which follows that route but the spawn priority is 0 which means the game is trying to "funnel" an engineer to the Lightning. I highly doubt this is WAI.

 

MOUNT05 - Invalid y coord of 10 on node 4. Deleted node. Looks to be a rare garbage node.

 

UBASE_11 - Node 1 patrols to 0, but 0 doesn't link back to 1. Fixed. Node 1 is in the air, but the game had any alien spawn there. I changed it to flying. Node 0 links back to 1 with one caveat: the unit must be flying.

 

UFO_000 & UFO_010 - Multiple problems across each module. Didn't fix. These are unused garbage ships.

 

UFO_150 - a node on top of each "wing" of the Terror Ship link to ones on the ground, but the ground doesn't link to the ones on the wing. Didn't fix. Not worth it as the nodes on the ground already have full link fields, and the flying links are only for pathfinding.

 

So that's that.

 

Edit 1: added these and other recent fixes to my patch kit in the files section.

 

Edit 2: just noticed that the Terror Ship is the only alien ship to have just pathfinding nodes around the outer perimeter of the ship instead of actual spawn points. I might just fix this, as it doesn't seem to be WAI.

 

- Zombie

[Zombie]

More fixes.

 

Small Scout

• Changed 2 perimeter nodes from small to any. I kept the rank of all the nodes to solider instead of Civ-Scout as nothing but soldiers can spawn from a Small Scout ship.
  

Medium Scout

• Changed my previous edit of the perimeter node from small to any.
  
• Possible to-do: shift the entire ship south and east by one tile width. This may help with regions of the ship being inaccessible due to terrain or water.
  
• Possible to-do: Add 3 more spawn points around the perimeter of the ship and link to W, E & N points on the compass rose. This should make this ship look more consistent spawn point wise.
  

Large Scout

• Changed a bunch of perimeter nodes from small to any.
  

Abductor

• Changed a perimeter node from small to any.
  

Harvester

• Changed two engineer spawn points to medics in the harvesting room and reduced their spawn priorities to 2. (There are plenty of engineer spawn points already, and I never could understand why engineers should be found in the harvesting room where the medics typically spawn. Yes, there are plenty of medic nodes already, but at least it's consistent now).
  
• Changed an engineer spawn point in the room off the engine room to a spawn priority of 2.
  
• Changed the two engineer spawn points in the engine room to have a priority of 6. (I mean, come on. Engineers should be found in the engine room at least most of the time)!
  
• Changed two navigator spawn points to soldier on the second floor. (There are plenty of navigator spawn points on the bridge already, and that's where they should be found).
  

Terror Ship

• Now has actual spawn points around the perimeter of the ship.
  
• Increased the spawn probability of an alien engineer from 2 to 3.
  
• Changed a navigator spawn point in the E small overlook room to a soldier.
  
• Changed a soldier spawn point in the bridge to navigator.
  
• Linked to the E & W middle perimeter nodes.
  

Supply Ship

• Linked to the E on the East perimeter node.
  
• To do: create another node along the W and then link to the west.
  
• Changed the spawn priority and "flag" field of an engineer to 3 in the engine room.
  

Battleship

• Changed a perimeter node from soldier to any.
  
• Changed the small outer perimeter nodes to any.
  
• Changed a spawn point on the second level from small to any.
  
• Changed the spawn priority of a navigator on the bridge room from 2 to 3.
  

The reason why I changed the outer perimeter nodes from small to any on the ships is because of continuity. Most of the ships had that layout already and I think it was intended to be that way. These fixes aren't included in my patch kit yet - I still need to add another perimeter node on the Supply Ship and link it to the west so that it's a mirror image of the other side of the ship. And then, maybe some changes to the medium scout. Other than that, the ship spawn points are looking quite good now.

 

Next up will probably be a complete overhaul of the arctic landscape. Some of you might know that there is the possibility of not being able to complete a mission on this landscape if you do not have flying suits yet as the water areas can maroon your craft (or the aliens) on an island. Quite annoying!

 

- Zombie

[Bomb Bloke]

Well you're keeping busy.

 

There were at least a couple of odd gaps on the supply ship; not sure if we ever patched those. One's pictured here (you can see and fire through the hole, and even stand directly under it and fly upwards to gain entry into the UFO), another consists of a missing pillar near the north-eastern corner of the top floor. There are probably other UFOs with similar missing pillars in places.

 

I think the goal with the polar maps was to rig things so that the watery map modules would "join up" and form continuous lakes and so on, but they never fully implemented it.

[Zombie]

There were at least a couple of odd gaps on the supply ship; not sure if we ever patched those. One's pictured here (you can see and fire through the hole, and even stand directly under it and fly upwards to gain entry into the UFO), another consists of a missing pillar near the north-eastern corner of the top floor. There are probably other UFOs with similar missing pillars in places.

 

Haven't fixed that yet. I know about it though as I used to exploit the heck out of it when running PSX Supply Ship missions. (Actually the hole is present on the other side of the ship too - that's how I normally entered). Didn't know there was a missing pillar/pillars on the Supply Ship, I'll take a look at it and the other ships as well to make sure that pillars are in the corners.

 

I think the goal with the polar maps was to rig things so that the watery map modules would "join up" and form continuous lakes and so on, but they never fully implemented it.

 

That may have been the intention, but it obviously isn't a good idea. Preventing you from finishing a quest due to landscape is wrong on so many levels. Not really sure how I'm going to fix this, but my thought is to always have a snowy perimeter around each module with a lot of water to prevent islands. I'll have to play around with it for a while to see if it'll work.

 

- Zombie

[Zombie]

Medium Scout

• Possible to-do: shift the entire ship south and east by one tile width. This may help with regions of the ship being inaccessible due to terrain or water.
  
• Possible to-do: Add 3 more spawn points around the perimeter of the ship and link to W, E & N points on the compass rose. This should make this ship look more consistent spawn point wise.
  

 

Completed both of these. Unfortunately, I think I need to shift all the ships to the east and south by one tile width. Don't know why the devs didn't try to center the ufo on the map module. The way the modules are now, tanks are unable to pass along the North and West sides of a ufo if they are on those edges of a map.

 

Unfortunately, shifting everything on the Medium Scout also creates a new issue: if the craft ends up butted up against the S or E sides of the map, you will be unable to get your tank directly up to the door. Suppose that's something we'll have to live with as the other fixes I made have a higher priority - at least you can access all sides of the ship now!

 

Supply Ship

• To do: create another perimeter node along the W and then link to the west.
  

 

Completed. Added another node and linked to the West, and also shifted some links around to make it look symmetrical.

 

- Zombie

[Zombie]

Unfortunately, shifting everything on the Medium Scout also creates a new issue: if the craft ends up butted up against the S or E sides of the map, you will be unable to get your tank directly up to the door. Suppose that's something we'll have to live with as the other fixes I made have a higher priority - at least you can access all sides of the ship now!

 

Hmmm, I just thought of a fix but don't know if this will work with just game file editing. Is there a way to increase the module dimensions in which the Medium Scout sits from 9x9 to the size of the Large Scout module (20x20)? The extra tiles would help with spacing and allow tanks to get to the door. Yeah, this isn't really Dev-intended anymore, but I'm just wondering if this is possible without .exe editing? To be more descriptive, I know I can edit the dimensions of the map file directly, but don't know if that's all that is needed with UFO's...

 

- Zombie

[Bomb Bloke]

When you start a mission, the GeoScape engine decides where the map modules go, and where the ships go. Certain map modules must be used where the craft are (for eg, a house can't be placed in the same spot, it has to be a mostly "empty" module). Once the GeoScape engine is done it saves the map to the disk, then the Tactical engine kicks in, loads that data and decides where the aliens go (and perhaps whether some UFO power supplies are going to blow up).

 

The ship dimensions are hardcoded into the GeoScape EXE along with all the other modules, not read dynamically from the map files (though the Tactical EXE does not have the dimensions hard-coded into it). This means that if you change the size of any given map module things get messed up. For example, making the medium scout 20 tiles square means it may overlap an invalid landing module (like a house or X-COM dropship) or even stick out the side of the final map.

 

Hence to get UFO:EU maps working in TFTD, I wrote up some code for my UFO/TFTD ComboMod which runs in the gap where the GeoScape engine would usually pass control to the Tactical engine. It basically chucks out whatever map the GeoScape engine built and repeats the work itself to whatever specifications I want at the time.

 

So it's either EXE editing, UFO Extender (which amounts to the same thing), or an executable like my code or XcomUtil that runs inbetween the game executables and re-writes the map data on the fly.

 

Anyway, an additional fun fact for the day: the position of ships on the map happen to be specified as an exact tile position, not a module position. Check out these bytes down the bottom here. You might like to experiment with them a little; start a new battle, then quit the game. Edit those bytes in the GeoData.dat file in the MissDat folder, then restart the game using my "_TacRun.bat" batch to see the result. I dunno if you'll spot anything useful, but it may be fun to play with.

[Zombie]

The ship dimensions are hardcoded into the GeoScape EXE along with all the other modules, not read dynamically from the map files (though the Tactical EXE does not have the dimensions hard-coded into it). This means that if you change the size of any given map module things get messed up. For example, making the medium scout 20 tiles square means it may overlap an invalid landing module (like a house or X-COM dropship) or even stick out the side of the final map.

 

Hence to get UFO:EU maps working in TFTD, I wrote up some code for my UFO/TFTD ComboMod which runs in the gap where the GeoScape engine would usually pass control to the Tactical engine. It basically chucks out whatever map the GeoScape engine built and repeats the work itself to whatever specifications I want at the time.

 

So it's either EXE editing, UFO Extender (which amounts to the same thing), or an executable like my code or XcomUtil that runs inbetween the game executables and re-writes the map data on the fly.

 

Hmmm, that's what I thought. Thanks for the clarification. Just for giggles I might just edit the map size in the .exe just to see what would happen.

 

By the way (and this is completely unrelated to the topic we were discussing), but your LOFTerrain program only works in-game, correct? By this I mean you run the program, it converts the maps, then you run the game to see the changes. This is kinda a pain when trying to diagnose problems. Is there any way to make it compatible with MapView so that I can see any issues from there without firing up the game? This would help a ton, but I don't know how much work it would be. Any ideas?

 

- Zombie