Maurice76

I've made a bunch of new images with the various coordinates, over the weekend. Now to find some time to merge the various layers and post them. When I do, I'll also remove all images posted so far, as to avoid confusion.

I think there's some confusion, lol. I think you guys are addressing an issue I was yet unaware of. Interesting in its own right, of course, but I guess what you are talking about is the information contained in the WORLD.DAT file. That one contains the vertices of all the polygons that make up the various seas, which probably has the overlapping polygon structures that you guys are talking about. What I was talking about was about the .gif on the UfoPaedia, with all the seas on it. I copied that one to obtain the landmasses and simply colored all seas white. After clearing out (most of) the sea textures, I turned the image into a 2-color image (black/white only), so the remains of the sea textures that I forgot to wipe out turned up black, like land masses, in the resulting image. I overlooked one such accidental "sea-turned-landmass area" between the AntArctic and Africa . The removal of the sea textures lowered contrast, so when I then drew all the waypoint areas on it, they would stand out more. Some of those waypoint areas are overlapping with one another (a number even completely), so when you draw each with partial transparency, they tend to show up in a sort of composite color. Like many green (sub-index 1), yellow (sub-index 2) and magenta (sub-index 4) areas in the polar regions are stacked, the result shows as if it's a pink area instead, masking the three base colors. But I will try and see if I can examine the WORLD.DAT file in closer detail. Create a map of that one, too, should not be too hard. Coming time is going to be busy though, so no promises; won't have much time tonight or coming weekend. Coming monday, Heroes 7 also goes live, which will likely gobble up a lot of my free time as well . Edit: I am not sure I am following you here. When I check the links you provided, I see (for TFTD) the Sea charts and Region charts, already showing the overlapping areas. If you compare the images I provided, you can clearly identify the light grey blocks in each with the Sea chart image. Or do you mean to also show the images with Regions superimposed on them? Edit 2: I just noticed that my Arctic maps are missing one strip, the one numbered 30 on the UfoPaedia. That's odd, since I am simply reading out the table with all the defined areas and 30 should be in that list. Also, the Sea of Japan is missing out on area 21. Will need to debug my code to see why it misses them. Edit 3: I found out ... my code assumes that the Y-coordinate of the bottom right corner of each area is below the Y-coordinate of the top left corner of the area. For those two particular areas, that's not the case. I will need to update my code to consider that exception as well. Not difficult, at least, but means I will need to generate the affected maps again.

You can see it where areas are overlapping eachother, or crossing the border between a landmass and the sea; partial transparency is noticable there as well as a slightly visible edge around all areas. The black stripe I meant was a left-over from wiping out the sea textures . In my effort to get the areas placed correctly, I didn't identify those stripes as left-over sea textures, until this afternoon. I've cleaned them out of the second set of images. But I also just noticed a glaring mistake on my part. The Sea overlay areas are colored lighter than in the originals. Only after I saw that did I remember that I changed the color index to somewhat darker in my graphics program, after having generated them with my code for the initial set of maps. I forgot to change that when I generated the new set this evening.

Ahh, now I get you . I don't have an account on the UfoPaedia, nor did I ever work with updating a Wiki, so I am a bit clueless on that part as well. By the way, I think the images I linked are actually a shrunk format, from when I uploaded it. If so desired (by whomever wishes to put the images on the site), I can also supply the original images I made (2880x1440 format). Below is an update that I've been working on. It includes transparency on all areas. One thing that I did notice was that some areas (especially in the two polar regions) are exactly overlapping. With transparency for each, the eventual color is hard to break apart into the original colors that formed it. Would you say the images below are better? Note that I also wiped away a black stripe near the AntArctic, just below Africa, which I missed when cleaning out the oceans . Notice the pink in the two images of the arctic regions. They are a composite of green, magenta and yellow.

Ah, nice to know . Oh, in case I am totally off on what I state, feel free to tell me I'm being stupid and what the data really represents . Alaska is easy enough to add to the table, although it does require some patching of the GeoScape.exe file. I'll dig up what's needed for that (replacing the Euro-Syndicate entry that's listed with the USA). New Mexico can be added easily enough by setting the Infiltration chance to something higher than 00 in the ACTS.DAT file. Patch can be made into the GeoScape.exe file to make it persistent, otherwise it has to be added at the start of each new game, when the game generates the file. Fixing up the fact that secondary nations in the Infiltration list don't get hit is something that probably can't be fixed in the GeoScape.exe file, as it does require some coding. But in OpenXCom, it's probably possible by keeping an eye on the corresponding column of the ACTS.DAT file: once the entry gets set to zero for a specific ZONAL.DAT index, it just once needs to be set back to what it was. They're up for grabs . Just one thing to point out, I do plan to update the maps a bit. Yesterday I spent a better part of the day writing some code in Excel to punch the waypoint table into a BMP format, with color index based on sub-index, which was actually the hardest part. With that one done, generating the actual image was relatively trivial. I obtained the world map from a .gif on the UfoPedia, the one with all the seas on it (I actually couldn't find a base map without them, although I think I should be able to extract one from the WORLD.DAT file ). After making all the seas white, I decided to use dark(er) colors for the waypoints. Only near the end did I make the seas darkgrey (and I am kinda pleased with how that map turned out to be). Looking at the maps now, I wonder if I shouldn't use brighter colors for the waypoints. In any case, I do plan to make more maps, zoomed in on each region, with the blocks actually having transparency, so they can be distinguished from one another. With the code I wrote it's relatively trivial to generate layers for each sub-index, which can then be merged in a graphics tool. The only map that looks "finished" is the one with the Terror Sites (although I am pondering adding the names of the sites ).

Actually, I did already . Near the top I wrote this: Thanks for the link, though. Will be interesting to dive some deeper into Shipping Lane and Artefact Site locations, as I haven't pinpointed those references yet. Hobbes, did you read also my posts about the USO Mission control and the ZONAL.DAT file and ACTS.DAT file? I've made some observations there too with regards to the sub-indices of the waypoint markers and how the game uses them in the corresponding control tables. Edit: Lol, seems I am confirming a lot of what you've found for UFO but then for TFTD . I admit that I haven't done any exploration of UFO (yet), so I was pretty much completely focussed on TFTD while uncovering the information in the posts I've made. I guess most of it is pretty much identical to UFO, though.

That's interesting information! I have to admit that I didn't check to see if the game actually directly referenced those specific areas, as I assumed they were simply left-overs from when they designed the various spawnpoints and waypoints (including Terror Sites). I'll check and see if I can find direct pointers to them in the code. With the information you provided, it's clearly a bug that the two Arctic "Terror regions" are actually in the AntArctic. Luckily, it's not hard to fix, just need to alter the Y-coordinate to occur near the Arctic instead of the other way around.

As detailed in one of my other posts, I discovered a huge spawn table within the executable of the game. I've decided to go ahead and actually plot everything on the world map. Below is the fruit of that labor. Each of the 12 ZONAL.DAT entries has their own subset of waypoints and spawnpoints and the images below all hold the waypoints and spawnpoints associated with them. For completeness sake, I've also drawn the Sea they're matched to (based on the Alien Infiltration subroutine). Before I post the images, I will first provide the color legend as well as a disclaimer. The colors that I've used on the image distinguish between the various sub-indices that exist, of which there are 6 in total. Dark red is sub-index 0. Green is sub-index 1. Yellow is sub-index 2. Blue is sub-index 3 and represents the Terror Site locations. Magenta is sub-index 4 and represents the possible locations for Alien Colonies. Teal is sub-index 5 and represents Alien USO entry and exit points. Black represents landmass, dark grey represents the seas. Lighter grey shaded areas represent ZONAL.DAT indices corresponding to the displayed spawn nodes. Note that USO's travel to waypoints of other sub-indices as well, depending on their mission parameters. Disclaimer 1: some of the spawn areas are overlapping eachother, in which case higher sub-indices are covering over lower sub-indices. Disclaimer 2: I omitted maps for North America, Eurasia and Africa, as they contain no spawn points whatsoever. ZONAL.DAT index 0: The North Atlantic ZONAL.DAT index 1: South Atlantic ZONAL.DAT index 2: North Pacific ZONAL.DAT index 3: South Pacific ZONAL.DAT index 4: the Mediterranean ZONAL.DAT index 5: South China Sea ZONAL.DAT index 6: the Indian Ocean ZONAL.DAT index 7: the Sea of Japan ZONAL.DAT index 8: the North Sea (note some waypoints are way down south here, of sub-index types 0 and 1) ZONAL.DAT index 9: the Caribbean ZONAL,DAT index 10: the AntArctic (note the two large blue blocks; they are sub-index type 3, i.e. Terror Site locations. However, no Terror missions are carried out in the AntArctic) ZONAL.DAT index 11: the Arctic (also has two large blue blocks, like the AntArctic. These aren't used either) Something that is rather hard to see is the Terror Sites, since they are only 1 pixel in size. I've highlighted them in the map below, where green circles denote Island Terror Mission sites, and red circles denote Port Terror Mission sites. Note the four blue Terror Site blocks that aren't used ingame. There is actually 1 Terror Site within one such block. I've kept the blocks as they are, although they serve no purpose by themselves. Also, it may be interesting to have the possible locations of all Alien Colonies. I've assembled them together in the map below. Note that there are a fair amount of possible locations that are on top of a landmass. Finally, the USO's can only spawn in very few locations. The below map highlights all these spawnpoints. Note that most of them occur outside the actual Sea in which they carry out their missions (see the individual ZONAL.DAT maps above).

Ah, I see. It could of course be possible that they used 2-month blocks in UFO, but that they changed that scheme in TFTD? In any case, the values were correct, only the timers were a bit off . Good to know that my digging has yielded some useful information on that aspect .

The UfoPedia site lists the Race Type spawn table per set of 2 months (here), with percentages and race types changing over time. I've managed to track down that file within the GeoScape.exe file, but I find something different. Not only is the table not accessed in blocks of 2 months, but I am also not seeing specific indices for the Ship Terror missions. As such, the information in the listed table on the UfoPedia site may be correct, but I can't confirm or deny it at this moment. (Update: I've found the Ship Terror reference. When it spawns a Ship Terror site, it will populate it with the row in the fourth table, that corresponds to the Alien Surface Attacks. This is a hard link). Within the GeoScape.exe file, the table starts at address 74A08h and is composed of 35 entries of 10 bytes each. This is split up across 5 distinct sub-tables, each with 7 rows, 1 row per mission type. The subroutine that handles the pointer into the correct table makes a determination based on ingame month. For month 0, it uses the first one. For month 1 and 2, it uses the second one. For month 3, 4 and 5 it points to the third one, while for month 6, 7 and 8 it points to the fourth. For all other months, it points to the fifth. I also assume that month 0 is january 2040, contrary to information that it represents december 2039, since the game starts at january 1st, 2040, at noon. The game has a lot of data tables that point to month 0, which would essentially be redundant if that would be december 2039 instead. Anyway, derived from the game itself: Month: 0 (january) Alien Race Type: AQUA GILL LOBS TASO M-TA M-LO Alien Probe Mission 70% 30% 0% 0% 0% 0% Alien Interdiction 50% 50% 0% 0% 0% 0% Alien Resource Raid 60% 40% 0% 0% 0% 0% Alien Infiltration 60% 40% 0% 0% 0% 0% Alien Colony Expansion 30% 70% 0% 0% 0% 0% Alien Surface Attacks 0% 100% 0% 0% 0% 0% Floating Base Attack 60% 40% 0% 0% 0% 0% Month 1 & 2 (february & march) Alien Race Type: AQUA GILL LOBS TASO M-TA M-LO Alien Probe Mission 60% 30% 10% 0% 0% 0% Alien Interdiction 50% 50% 0% 0% 0% 0% Alien Resource Raid 40% 60% 0% 0% 0% 0% Alien Infiltration 50% 30% 20% 0% 0% 0% Alien Colony Expansion 40% 40% 20% 0% 0% 0% Alien Surface Attacks 20% 80% 0% 0% 0% 0% Floating Base Attack 30% 40% 30% 0% 0% 0% Month 3, 4 & 5 (april, may & june) Alien Race Type: AQUA GILL LOBS TASO M-TA M-LO Alien Probe Mission 30% 40% 30% 0% 0% 0% Alien Interdiction 30% 50% 20% 0% 0% 0% Alien Resource Raid 50% 50% 0% 0% 0% 0% Alien Infiltration 20% 50% 30% 0% 0% 0% Alien Colony Expansion 10% 30% 60% 0% 0% 0% Alien Surface Attacks 20% 30% 50% 0% 0% 0% Floating Base Attack 20% 60% 20% 0% 0% 0% Month 6, 7 & 8 (july, august & september) Alien Race Type: AQUA GILL LOBS TASO M-TA M-LO Alien Probe Mission 20% 10% 40% 30% 0% 0% Alien Interdiction 10% 0% 40% 50% 0% 0% Alien Resource Raid 30% 0% 0% 70% 0% 0% Alien Infiltration 10% 30% 20% 40% 0% 0% Alien Colony Expansion 10% 40% 30% 20% 0% 0% Alien Surface Attacks 10% 30% 20% 20% 20% 0% Floating Base Attack 20% 30% 30% 20% 0% 0% Month 9+ (october and beyond) Alien Race Type: AQUA GILL LOBS TASO M-TA M-LO Alien Probe Mission 20% 20% 20% 40% 0% 0% Alien Interdiction 30% 0% 30% 40% 0% 0% Alien Resource Raid 50% 0% 0% 50% 0% 0% Alien Infiltration 20% 20% 50% 10% 0% 0% Alien Colony Expansion 10% 20% 60% 10% 0% 0% Alien Surface Attacks 20% 20% 20% 10% 30% 0% Floating Base Attack 10% 10% 60% 20% 0% 0% The note on the UfoPedia site about specific sites holds: Artefact Sites Stage 1 and Stage 2 are of the Mixed Tasoth type, just as Alien Colony Stage 1 missions. Alien Colony Stage 2 are based on Lobster Man (not the Mixed one). T'Leth Stage 1 is Aquatoid, Stage 2 is Mixed Lobster Man, as is Stage 3.

As written in the previous post, there is a Spawn Table, which takes the ZONAL.DAT index as well as a sub-index based on movement behaviour to define a specific spawnspot. This spawn table is rather huge: the ZONAL.DAT index has 12 different values and the sub-index has another 6, making for 72 rows. Each row has 10 entries of 8 bytes each, making each row 80 bytes. The total size is therefore 72 x 80 = 5760 bytes in size. Given that massive size, I can't and will not post the full data table here, but I will describe the contents and how the game uses it. First of all, in my GeoScape.exe version, the start address is 66A0Ch, the final address is 6808Bh. When the game references the Spawn Table, it takes the ZONAL.DAT index as well as the sub-index to find the proper row in the Spawn Table. Then it will randomly determine a number from 0 to 9 to find the proper entry on that row. Each entry holds coordinate information for a Spawn Point and if the first two bytes contain the value 255, the spawnpoint is not used. In that case, the game will redetermine the random number and keep at it until it has found a valid spawnpoint. As said, each entry has 8 bytes, which have the following meaning: Byte [0, 1]: X-coordinate of the spawnpoint on the worldmap Byte [2, 3]: Y-coordinate of the spawnpoint on the worldmap Byte [4, 5]: Maximum X-offset relative to the X-coordinate Byte [6, 7]: Maximum Y-offset relative to the Y-coordinate The maximum X-offset value is used as maximum value in a random number generation. The outcome is added to the specified X-coordinate to get the actual X-coordinate of the object to spawn. The same applies for the Y-offset value. Using the maximum X-offset and maximum Y-offset essentially forms a small box for each Spawn point, in which an object can be spawned. It would be an interesting exercise to map each of them on a Sea and Region, drawing them on the world map just like the image was made for the Seas and Regions on the UfoPedia site (see an above post for the link). Note that the coordinates are as used in the ingame worldmap: X runs from 0 to 2880 eastwards, where 0 and 2880 are the Greenwich longitude positions. Y runs from 0 to 720 for the southern hemisphere, with 720 being the South Pole. Similar, it runs from 0 to -720 for the northern hemisphere, with -720 defining the position of the North Pole. Besides being used by the Movement Behaviour table to find Waypoints, some of the sub-indices have another purpose, too. Sub-index 4 is used to generate locations for Alien Colonies. Sub-index 3 is used to define Port Terror sites and Island Terror sites. Since they are fixed on the world map, their X-offset and Y-offset values are all 0, which means sub-index 3 values are all precise coordinates. There are 51 of those out of the 100 possible ones for sub-index 3, the other 49 are invalid coordinates (value 255 for the first 2 bytes). The game actually uses an overlay to find whether the coordinates of sub-index 3 represent a Port Terror site or an Island Terror site. This overlay starts at address 681E0h and is 102 bytes in size, 2 bytes per Terror Site. The second byte is a padding byte in each case. 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 0 1 0 1 0 1 0 1 0 1 0 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 1 0 1 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 Omitting those for readability, the byte string can be ordered per ZONAL.DAT index as follows (with the ZONAL.DAT and NUM SITES numbers added by me for readability, they are not part of the overlay byte string): ZONAL NUM TERROR MISSION INDEX SITES TYPE 0 6 1 0 1 0 0 0 1 7 0 0 0 1 1 1 1 2 5 0 1 0 1 0 3 8 0 1 1 1 1 1 0 1 4 5 1 0 0 0 0 5 5 0 0 0 0 0 6 5 0 1 1 1 1 7 3 0 0 0 8 4 0 1 0 0 9 3 0 0 0 The column NUM SITES equals the number of Spawn points at sub-index 3 for the corresponding ZONAL.DAT entry. Once the game has determined which of the Spawn points it is going to use for the Terror Mission, it will look up the matching value in the overlay. If this value is 0, it will generate a Port Terror Site at the designated coordinates. If the value is 1, it will generate an Island Terror Site instead. I have not found references to this table to spawn Ship Terror missions or Artefact Terror missions, but those of course must exist, seeing as they're spawned on the world map too.

While the Mission Flow control table detailed in the previous post handles the general spawning order, it doesn't say anything about where to spawn the USO's and where they have to move to perform their missions. As written in that post, each Mission Stage has a pointer into the Movement Behaviour table, which details the behaviour of the various USO's, based on the missions they perform. To keep track of what a given USO is doing, this is also stored within the CRAFT.DAT file of the corresponding USO, at the bytes 0x58-0x59 and 0x5A-0x5B. The values of those bytes are currently said to be of "Unknown use." according to the CRAFT.DAT entry on the UfoPedia site, but they are used to keep track of the progress within the Movement Behaviour table. Bytes 0x5A-0x5B hold the index into the Movement Behaviour table, while bytes 0x58-0x59 hold the number of Waypoints that the USO has passed since the mission started (where the spawnpoint of the USO is considered to be Waypoint 0). The Movement Behaviour table itself has 10 rows of 52 bytes each. The buildup of each row is according to this: [0, 1]: Maximum number of Waypoints for this Movement Behaviour type (only has values of 2, 5 and 8); [2 .. 17]: Per waypoint, each two bytes contain a sub-index into a (huge) Spawnpoint table (of which the ZONAL.DAT reference is the main index). This Spawnpoint table is detailed in the next post in build-up only, as it's too large to post completely in a forum post. A value of 255 here means the Waypoint is not used.; [18 .. 33]: Per waypoint, each two bytes contain the depth at which the USO is moving between the waypoint it just left behind and the one it's heading towards; [34 .. 49]: Per waypoint, each two bytes contain the velocity percentage at which the USO performs that movement, relatively to its maximum velocity; [50, 51]: A timer. UfoPedia lists this as the decay timer for USO wrecks as well as maximum time spent moving between waypoints, but I don't think this can be correct. It would make decay times for identical USO's depend on the Mission Stage they were performing at the time. Furthermore, the timer on Fleet Supply Cruisers is only some 13 hours, which would mean those USO's would vanish in just over half a day of being downed. As timers for Terror Missions that spawned based on them as well as Touchdown timers before USO's take off again, these values make much more sense. The first waypoint index in the tables below is where the USO is spawned. Each time it reaches the next waypoint on its movement, it will adopt the values listed at that particular waypoint to travel to the next. Once it reaches the final waypoint, it will vanish again from the map. Note that except for the final Waypoint in the list, a depth of 0 means that the USO is touched down (green cross on the world map). In table form (note that the Waypoint counter is implicit, as it is derived from the position in the table): Movement Behaviour type 0 Start address: 66804h Maximum Waypoints of this type: 5 Expiration timer: 3000 (in ticks of 5 seconds, so roughly ~21 hours) Waypoint counter: 01 02 03 04 05 06 07 08 Spawnpoint Index: 5 0 0 0 0 0 1 0 5 0 255 255 255 255 255 255 USO Depth: 4 0 3 0 1 0 1 0 2 0 0 0 0 0 0 0 USO speed %: 100 0 74 0 28 0 47 0 100 0 0 0 0 0 0 0 How to read this table: First, a USO is spawned at a point defined by the corresponding ZONAL.DAT index of the mission it is part of, as well as the sub-index of waypoint 01. As it is spawned, it is set to a depth of 4 ("Very Deep"). Note that for the first 3 months ingame, there is an override which sets this to a value of 3 ("Deep"). The speed is set to 100% of its maximum velocity. A destination waypoint is created for the USO, this one with a sub-index of 0, but with the same ZONAL.DAT main index. Once the USO reaches this destination waypoint, it will move up in depth to a depth of 3 ("Deep") and change its velocity to only 74% of its maximum velocity. The next destination waypoint is defined, once again with a sub-index of 0. Once the USO reaches it, it will move up to a depth of 1 ("Shallow") and drop its speed to 28% of its maximum. Its destination is a waypoint with a sub-index of 1. At that next waypoint, it picks up in speed, increasing to 47% of maximum and it gets a destination waypoint with a sub-index of 5. Once it reaches that one, its speed picks up to 100% again and it will high tail it out of the map at that point. While this final waypoint has a depth of 2 ("Normal"), I don't think the game actually uses it, since it's set to 0 ("Touched Down") for most of the other Movement Behaviour types. From what I can see in the game code, though, the USO simply gets removed from the game once it reaches this final waypoint if it's invisible. If it's visible, it calls on another subroutine, which is likely displaying it taking off at a high speed, beyond X-Com reach. If that's the case, the depth and speed at the final Waypoint are not used ingame and therefore redundant. ================================================================================== Movement Behaviour type 1 Start address: 66838h Maximum Waypoints of this type: 8 Expiration timer: 4000 (in ticks of 5 seconds, so roughly ~28 hours) Waypoint counter: 01 02 03 04 05 06 07 08 Spawnpoint Index: 5 0 0 0 0 0 1 0 0 0 0 0 2 0 5 0 USO Depth: 4 0 2 0 2 0 1 0 0 0 2 0 1 0 0 0 USO speed %: 100 0 76 0 20 0 44 0 20 0 32 0 65 0 100 0 ================================================================================== Movement Behaviour type 2 Start address: 6686Ch Maximum Waypoints of this type: 5 Expiration timer: 5000 (in ticks of 5 seconds, so roughly ~35 hours) Waypoint counter: 01 02 03 04 05 06 07 08 Spawnpoint Index: 5 0 0 0 0 0 1 0 5 0 255 255 255 255 255 255 USO Depth: 4 0 3 0 2 0 1 0 0 0 0 0 0 0 0 0 USO speed %: 100 0 57 0 26 0 50 0 100 0 0 0 0 0 0 0 ================================================================================== Movement Behaviour type 3 Start address: 668A0h Maximum Waypoints of this type: 5 Expiration timer: 6000 (in ticks of 5 seconds, so roughly ~42 hours) Waypoint counter: 01 02 03 04 05 06 07 08 Spawnpoint Index: 5 0 0 0 0 0 2 0 5 0 255 255 255 255 255 255 USO Depth: 4 0 3 0 2 0 1 0 0 0 0 0 0 0 0 0 USO speed %: 100 0 30 0 25 0 20 0 100 0 0 0 0 0 0 0 ================================================================================== Movement Behaviour type 4 Start address: 668D4h Maximum Waypoints of this type: 8 Expiration timer: 7000 (in ticks of 5 seconds, so roughly ~49 hours) Waypoint counter: 01 02 03 04 05 06 07 08 Spawnpoint Index: 5 0 0 0 0 0 2 0 0 0 0 0 2 0 5 0 USO Depth: 4 0 2 0 2 0 1 0 0 0 2 0 1 0 0 0 USO speed %: 100 0 67 0 52 0 40 0 30 0 20 0 30 0 100 0 ================================================================================== Movement Behaviour type 5 Start address: 66908h Maximum Waypoints of this type: 8 Expiration timer: 4000 (in ticks of 5 seconds, so roughly ~28 hours) Waypoint counter: 01 02 03 04 05 06 07 08 Spawnpoint Index: 5 0 0 0 0 0 4 0 0 0 0 0 4 0 5 0 USO Depth: 4 0 2 0 2 0 1 0 0 0 2 0 1 0 0 0 USO speed %: 100 0 50 0 20 0 15 0 20 0 29 0 42 0 90 0 ================================================================================== Movement Behaviour type 6 Start address: 6693Ch Maximum Waypoints of this type: 5 Expiration timer: 5000 (in ticks of 5 seconds, so roughly ~35 hours) Waypoint counter: 01 02 03 04 05 06 07 08 Spawnpoint Index: 5 0 0 0 0 0 4 0 5 0 255 255 255 255 255 255 USO Depth: 4 0 3 0 2 0 1 0 0 0 0 0 0 0 0 0 USO speed %: 100 0 50 0 25 0 16 0 100 0 0 0 0 0 0 0 ================================================================================== Movement Behaviour type 7 Start address: 66970h Maximum Waypoints of this type: 5 Expiration timer: 9000 (in ticks of 5 seconds, so roughly ~62,5 hours) Waypoint counter: 01 02 03 04 05 06 07 08 Spawnpoint Index: 5 0 0 0 0 0 3 0 5 0 255 255 255 255 255 255 USO Depth: 4 0 3 0 2 0 1 0 0 0 0 0 0 0 0 0 USO speed %: 100 0 60 0 30 0 20 0 100 0 0 0 0 0 0 0 ================================================================================== Movement Behaviour type 8 Start address: 669A4h Maximum Waypoints of this type: 8 Expiration timer: 6000 (in ticks of 5 seconds, so roughly ~42 hours) Waypoint counter: 01 02 03 04 05 06 07 08 Spawnpoint Index: 5 0 1 0 2 0 3 0 4 0 0 0 2 0 5 0 USO Depth: 4 0 1 0 1 0 1 0 1 0 1 0 1 0 4 0 USO speed %: 100 0 60 0 20 0 30 0 20 0 42 0 56 0 100 0 ================================================================================== Movement Behaviour type 9 Start address: 669D8h Maximum Waypoints of this type: 2 Expiration timer: 2000 (in ticks of 5 seconds, so roughly ~14 hours) Waypoint counter: 01 02 03 04 05 06 07 08 Spawnpoint Index: 5 0 5 0 255 255 255 255 255 255 255 255 255 255 255 255 USO Depth: 4 0 0 0 1 0 1 0 1 0 1 0 1 0 1 0 USO speed %: 80 0 100 0 0 0 0 0 0 0 0 0 0 0 0 0 Movement Behaviour type 9 is only used by Colony Supply Cruisers on Colony Supply Missions. Note that it's the only USO that moves at 80% of its maximum velocity right after spawning. Given that it moves towards an Alien Colony after spawning, I am guessing that the proper coordinates of the corresponding Alien Colony are supplied as an extra Waypoint directly between the Spawnpoint and the final Waypoint (which functions as the exit for the USO, where it vanishes off the world map).

Once the missions have been picked at each month turn, the game refers to a table that controls the general Mission Flow. The table has 8 entries of 8 bytes each, for every of the 8 possible mission types. In addition to the 7 mission types already listed above, mission type 8 is formed by the Colony Supply Missions. Those missions are scheduled independently of the mission spawn table and depend on the presence of Alien Colonies on the map. Generally, the 8 entries represent Mission Stages within that mission. Each stage is composed of 8 bytes with the following meaning: Bytes: [0, 1]: USO type to carry out this Mission Stage; [2, 3]: Number of iterations for this Mission Stage (most have an iteration of 1, but exceptions exist); [4, 5]: Index to the USO Movement Behaviour table (detailed in the next post); [6, 7]: Spawn time base value for this Mission Stage (i.e.: when it has to move on to the next iteration of this Stage or next Mission Stage if it has reached the maximum number of iterations on this Stage); USO type is defined by number: 05 = Survey Ship 06 = Escort 07 = Cruiser 08 = Heavy Cruiser 09 = Hunter 10 = Battleship 11 = Dreadnought 12 = Fleet Supply Cruiser Iterations simply mean the same stage is repeated that many times. The Movement Behaviour table contains data for the trajectory between each of the waypoints that the USO follows during its mission. This table is detailed in the next post. The actual spawn time is calculated through a formula, to generate a random spread around this base value. The game calculates it as follows: Actual spawn time = [ RAND ( <base value> ) + TRUNC( <base value> / 2 ) ] Basically, this gives an actual spawn time between 50% and 150% of the base value. According to the UfoPedia, successful USO interceptions affect the timer for the next USO in the Mission Stage chain (and may even completely break the chain), but I haven't been able to discover that data yet. The Mission Flow table per mission type is detailed below. At the right hand side of the columns is the timer in better readable format. This is the base value in number of 30 minute ticks that have to pass to spawn the next Mission Stage in question. Note that this is a redundant value for the final Mission Stage and final iteration of that Stage, as no further Stages occur after it. ================================================================== Mission type: Alien Probe Mission Start address: 66604h Columns: USO NUM Index Spawn Time Stage 1: 5 0 1 0 0 0 44 1 || 300 Stage 2: 6 0 1 0 2 0 4 1 || 260 Stage 3: 7 0 2 0 4 0 44 1 || 300 Stage 4: 255 255 255 255 255 255 255 255 || unused Stage 5: 255 255 255 255 255 255 255 255 || unused Stage 6: 255 255 255 255 255 255 255 255 || unused Stage 7: 255 255 255 255 255 255 255 255 || unused Stage 8: 255 255 255 255 255 255 255 255 || unused ================================================================== Mission type: Alien Interdiction Start address: 66644h Columns: USO NUM Index Spawn Time Stage 1: 5 0 1 0 0 0 4 1 || 260 Stage 2: 5 0 1 0 2 0 4 1 || 260 Stage 3: 6 0 1 0 2 0 200 0 || 200 Stage 4: 7 0 1 0 0 0 4 1 || 260 Stage 5: 7 0 1 0 3 0 44 1 || 300 Stage 6: 8 0 1 0 4 0 100 0 || 100 Stage 7: 8 0 1 0 4 0 25 0 || 25 Stage 8: 11 0 1 0 2 0 50 0 || 50 ================================================================== Mission type: Alien Resource Raid Start address: 66684h Columns: USO NUM Index Spawn Time Stage 1: 5 0 1 0 0 0 244 1 || 500 Stage 2: 6 0 1 0 1 0 88 2 || 600 Stage 3: 7 0 1 0 3 0 44 1 || 300 Stage 4: 9 0 1 0 3 0 44 1 || 300 Stage 5: 9 0 2 0 4 0 2 0 || 2 Stage 6: 255 255 255 255 255 255 255 255 || unused Stage 7: 255 255 255 255 255 255 255 255 || unused Stage 8: 255 255 255 255 255 255 255 255 || unused ================================================================== Mission type: Alien Infiltration Start address: 666C4h Columns: USO NUM Index Spawn Time Stage 1: 5 0 1 0 0 0 38 2 || 550 Stage 2: 6 0 1 0 1 0 244 1 || 500 Stage 3: 6 0 1 0 6 0 204 1 || 460 Stage 4: 7 0 1 0 7 0 44 1 || 300 Stage 5: 7 0 1 0 7 0 2 0 || 2 Stage 6: 10 0 1 0 7 0 2 0 || 2 Stage 7: 12 0 1 0 7 0 2 0 || 2 Stage 8: 11 0 2 0 7 0 2 0 || 2 ================================================================== Mission type: Alien Colony Expansion Start address: 66704h Columns: USO NUM Index Spawn Time Stage 1: 5 0 1 0 1 0 194 1 || 450 Stage 2: 6 0 1 0 5 0 244 1 || 500 Stage 3: 7 0 1 0 5 0 2 0 || 2 Stage 4: 12 0 2 0 5 0 2 0 || 2 Stage 5: 11 0 1 0 6 0 2 0 || 2 Stage 6: 255 255 255 255 255 255 255 255 || unused Stage 7: 255 255 255 255 255 255 255 255 || unused Stage 8: 255 255 255 255 255 255 255 255 || unused ================================================================== Mission type: Alien Surface Attacks Start address: 66744h Columns: USO NUM Index Spawn Time Stage 1: 6 0 1 0 1 0 244 1 || 500 Stage 2: 7 0 1 0 1 0 64 1 || 320 Stage 3: 10 0 1 0 0 0 144 1 || 400 Stage 4: 10 0 1 0 7 0 44 1 || 300 Stage 5: 255 255 255 255 255 255 255 255 || unused Stage 6: 255 255 255 255 255 255 255 255 || unused Stage 7: 255 255 255 255 255 255 255 255 || unused Stage 8: 255 255 255 255 255 255 255 255 || unused Note that this mission flow control has nothing to do with the Terror Site missions that are spawned at the start of each month! Those missions are spawned without USO presence. Since these Terror Missions are also not spawned through the monthly mission spawning subroutine (see opening post), these may be spawned through another mechanism. I haven't found it yet, but I am very certain that I have shot down USO's that had Alien Surface Attacks as mission, according to the Transmission Resolver. ================================================================== Mission type: Floating Base Attack Start address: 66784h Columns: USO NUM Index Spawn Time Stage 1: 5 0 1 0 8 0 100 0 || 100 Stage 2: 6 0 2 0 8 0 100 0 || 100 Stage 3: 7 0 3 0 8 0 100 0 || 100 Stage 4: 11 0 2 0 8 0 100 0 || 100 Stage 5: 255 255 255 255 255 255 255 255 || unused Stage 6: 255 255 255 255 255 255 255 255 || unused Stage 7: 255 255 255 255 255 255 255 255 || unused Stage 8: 255 255 255 255 255 255 255 255 || unused ================================================================== Mission type: Colony Supply Missions Start address: 667C4h Columns: USO NUM Index Spawn Time Stage 1: 12 0 1 0 9 0 200 0 || 200 Stage 2: 255 255 255 255 255 255 255 255 || unused Stage 3: 255 255 255 255 255 255 255 255 || unused Stage 4: 255 255 255 255 255 255 255 255 || unused Stage 5: 255 255 255 255 255 255 255 255 || unused Stage 6: 255 255 255 255 255 255 255 255 || unused Stage 7: 255 255 255 255 255 255 255 255 || unused Stage 8: 255 255 255 255 255 255 255 255 || unused

As detailed above, the game uses the ZONAL.DAT file to pinpoint one of the Seas in which to undertake actions. Even as the game shows the Region and Seas maps on the UfoPedia site in graphic form, it doesn't show the values for each. The values are found in the GeoScape.exe file. From address 76A28h onward, it lists 38 strings of 10 bytes each. Each byte has a specific meaning within that string: Byte: [0, 1]: The X-coordinate of the top left corner of the rectangle that makes up the Sea area on the map; [2, 3]: The Y-coordinate of the top left corner; [4, 5]: The X-coordinate of the bottom right corner; [6, 7]: The Y-coordinate of the bottom right corner; [8]: The Sea code for that area (most Seas are composed of a few of these areas close to eachother); [9]: A padding byte and always 0; The X-coordinate runs from 0 (the Greenwich longitude) to 2880 in the eastward direction, the Y-coordinate runs from 0 to 720 (from the equator to the South Pole) and 0 to -720 (from the equator to the North Pole). By providing the top-left corner and the bottom-right corner, the game defines rectangular areas on the world map. The Regions are defined in a similar fashion, with starting address of 76BA4h. Like the Seas areas, the Region areas follow the same 10-byte string detailed above and like the Seas, there are 38 defined Regions. The purpose of these areas is to keep track of mission scores for both Aliens and X-Com. Whenever a mission is performed within a given area (or simply have a Craft present in the area), the score of that area is increased by an amount designated for that particular activity.

Basically, the game determines every month what to do against the inhabitants on earth. The USO's it will spawn, along with the activities they undertake, where they undertake them and how the flow of the mission goes. In order to do so, the game uses numerous data tables, which are mostly linked to one another in sometimes complex manners. This series of posts is intended to detail various specifics regarding those tables and the flow control used by the game to handle everything in proper fashion. The start is formed by the ZONAL.DAT file, in very close correlation to the ACTS.DAT file. The first one contains 12 index values, each referencing a Sea within the game (note that there are 15 defined seas in total; the final 3 in the list aren't used for this purpose). The second one contains actions to undertake within each of those seas. Because of their close relation, I will list the contents of these files together. The starting values of both files are held in the GeoScape.exe file. In my game (DOS v1.0 of TFTD), the addresses are: ZONAL.DAT: address 69620h, 12 bytes. ACTS.DAT: address 6963Ch: 12 strings of 7 bytes each. In table form: ZONAL.DAT ACTS.DAT 01 02 03 04 05 06 07 18 ------- 14 16 20 20 20 00 00 04 ------- 25 22 12 20 25 00 00 04 ------- 25 16 21 18 18 00 00 10 ------- 10 24 12 18 20 00 00 16 ------- 10 10 15 20 06 00 00 12 ------- 08 08 08 08 19 00 00 08 ------- 07 08 08 08 09 00 00 12 ------- 05 05 06 10 08 00 00 15 ------- 08 13 21 13 08 00 00 10 ------- 06 00 05 00 09 00 00 10 ------- 15 00 00 00 22 00 00 05 ------- 15 00 00 00 28 00 00 Each time the game month changes, it will run through a subroutine to determine which missions to spawn next. Note that the first month is taken separately, as it starts at noon on january 1st, so it doesn't go through the mission determination subroutine. The first time the game loops through that subroutine is on the switchover from january to february 2040. Assuming that month 0 is january (I am not 100% sure here, since I see claims on the UfoPedia site that month 0 is actually december 2039, but since the game start on january 1st of 2040 at noon coupled with the fact that a lot of data tables contain sections for month 0, I think month 0 refers to january 2040), the game will spawn 1 action for the aliens to undertake each month, besides the mandatory Terror Site mission at the start of each month. From july 2040 onwards, the game will spawn 2 actions per month, besides the Terror Site mission. Also, the game calculates a month from where to start launching monthly Floating Base Assaults, regardless of success against USO's. For that purpose, it determines the value ( 14 - DiffcultyIndex ), so for Veteran this value is 12 (january 2041), while for Superhuman, this is 8 (september 2040). It will scan the LOC.DAT file to find the first X-Com base that's not already suffering a Floating Base Attack mission against it and schedule one against that unattacked X-Com base, starting from 2h30m into the month. To determine which action to undertake during a month, the game will add up the 12 values in the ZONAL.DAT file and then determine a random number in the range of [ 1 .. that sum ]. Based on that, it is able to pick out a specific row in the table. It then uses that ZONAL.DAT index to find the proper row in the ACTS.DAT file. Like with the column of the ZONAL.DAT file, it will sum up all the values in the correct ACTS.DAT row, determine a random number in the range of [ 1 .. that sum ] and based on that, it is able to select a specific column. Each column in the ACTS.DAT table represents a specific mission type: 01 = Alien Probe Mission 02 = Alien Interdiction 03 = Alien Resource Raid 04 = Alien Infiltration 05 = Alien Colony Expansion 06 = Alien Surface Attacks 07 = Floating Base Attacks As can be seen from the ACTS.DAT table, the values for 06 and 07 are always zero, as these two mission types are determined differently: Terror Missions at the start of the month and Floating Base Attacks when X-Com shoots down too many USO's in a given region, as well as from the start of a certain month onwards (see above). Once it has determined a mission, it will set the corresponding entry in the ACTS.DAT file to 00. In essence, any ZONAL.DAT index can only ever have 1 of each mission types against it. When all missions on a given row in the ACTS.DAT file have been depleted, the corresponding ZONAL.DAT index is also set to 00. The effect of setting these values to zero is that the ratio of missions changes within a ZONAL.DAT index and setting the ZONAL.DAT index to zero changes the ratio between the remaining indices there. The link for the ZONAL.DAT index and the Seas actually came from a subroutine that handles Alien Infiltration success. It uses the ZONAL.DAT index to find which nations defect on a success and in which Seas and which Regions to increase the Alien Activity score (used in the monthly Graphs that can be seen ingame). Based on the information in that subroutine, I found the following: 01 North Atlantic --- USA -> Euro-Syndicate 02 South Atlantic --- Africa Corp -> Brazilian Union 03 North Pacific --- Euro-Syndicate -> Eurasia 04 South Pacific --- Australasia 05 Mediterranean --- Egyptian Cartel 06 South China Sea --- Free China -> Fed Korea 07 Indian Ocean --- Asian Coalition -> Arabian Bloc 08 Sea of Japan --- Neo-Japan 09 North Sea --- Scandinavia -> Icelandic Union 10 Caribbean --- New Mexico 11 AntArctic --- (no coupled Regions) 12 Arctic --- (no coupled Regions) 13 Eurasia --- (not referenced anywhere by the ZONAL.DAT file; essentially undefined) 14 North America --- (not referenced anywhere by the ZONAL.DAT file; essentially undefined) 15 Africa --- (not referenced anywhere by the ZONAL.DAT file; essentially undefined) Arrows indicate the distinction between Primary Region of a Sea and Secondary Region. This is important when the game determines which Region will suffer the Alien Infiltration mission. For completeness sake, I have included indices 11 through 15 as well, even though 11 and 12 have no Regions attached to it (but they do have Missions scheduled in them: Alien Probe Missions and Alien Colony Expansions) and 13 through 15 have no Regions or Missions at all. The above dissection suffers from multiple bugs or very weird design choices, however. In no particular order: - Alaska is missing from the list. As a result, Alaska will never suffer Alien Infiltration missions against it and will therefore never abandon the X-Com project; - Alien Infiltrations in the North Pacific will affect the chance for the Euro-Syndicate and Eurasia to defect, even if those two Regions are not anywhere near the North Pacific; - Euro-Syndicate is listed twice (likely one of these should actually be Alaska); - As an expansion to the above, it would actually be better to swap the North Atlantic and North Pacific entries: have the USA and Alaska coupled to activity in the North Pacific and Euro-Syndicate and Eurasia by activities in the North Atlantic; - ZONAL.DAT index 10 has no Alien Infiltration mission in the ACTS.DAT file. As a result, New Mexico will also never be targeted by Alien Infiltration missions and remain loyal to the X-Com project indefinately (maybe by design because that's where T'Leth is located?); - The Region order detailed above is important. When the game determines which Region to affect, it will check if the Primary Region is already defecting or has defected (specifically: whether byte 2 in the DIPLOM.DAT file has been set to 0 for that Region). If not, the Primary Region will defect on Alien mission success. Otherwise, the Secondary Region is targeted, but no check is made to see if that one has already defected!. However, this bug is masked by another one: since each ZONAL.DAT index is targeted by no more than 1 of each mission type, only 1 Alien Infiltration mission will ever be scheduled against that ZONAL.DAT index. As such, all Regions listed as secondary target will also never suffer an Alien Infiltration mission against them (Euro-Syndicate being the exception, since it is listed once as primary Region). Because of that, Brazilian Union, Eurasia, Fed Korea, Arabian Bloc and Icelandic Union will also remain loyal to X-Com indefinately; When it comes down to spawning the monthly Terror Site mission, the game uses the following determinations regardless of difficulty: Month 0 and 1: guaranteed Port Terror Site. Month 2: 50% chance on a Port Terror Site, 50% chance on a Ship Terror site. Month 3+, less than 12 Artefact Sites destroyed: 20% chance on a Port Terror site, 30% chance on a Ship Terror site and 50% chance on an Artefact Terror site. Month 3+: all 12 Artefact Sites destroyed: 40% chance on a Port Terror site, 60% chance on a Ship Terror site. Note that Port Terror Sites get replaced by Island Terror Sites where applicable. See the post about the Spawn table further down this thread on how the game makes this distinction.

I was wrong about my last claim. That Rank column is the very thing that defines the rank of the alien. The columns in the race type buildup are only types 1 through 8, unrelated to Alien rank. For instance, the Tasoth lineup features four entries of 23, two entries of 22 and two entries of 0. When the game spawns Aliens of this race buildup, all 23's will show up ingame as Tasoth Squad Leaders and all 22's will show up as Tasoth Soldiers. The Alien Stats table I listed above has all the Race and Rank combinations that the game knows. Also, when I wrote that in order to fix the Xarquid spawn on Terror Missions with the Mixed Tasoth Race type, I overlooked one detail: the same line is also responsible for populating Alien Colony Stage 1 missions. Replacing the 0 by a 23 effectively means that all Hallucinoid Terrorists will be replaced by Tasoth Squad Leaders instead. So to really fix it, the number of Aliens in the Alien Deployment table for Colony Stage 1 missions needs to be adjusted as well. Type 5 needs to be reduced and Type 1 needs to be increased, to retain the same number of Tasoth Squad Leaders and Hallucinoids in that particular mission. In the default setting, the game spawns this many Tasoth Squad Leaders for Colony Stage 1 missions: Beginner/Experienced: 3 + rand [2] Veteran/Genius: 3 + rand [2] Superhuman: 4 + rand [2] And this many Hallucinoids: Beginner/Experienced: 3 + rand [1] Veteran/Genius: 4 + rand [1] Superhuman: 6 + rand [1] So, to really fix the issue of the Xarquid spawning in a surface mission while leaving Colony Stage 1 untouched, the following adjustments are needed: Clear the spawn type 5 from the Colony Stage 1 deployment table: 68D84h: 03 -> 00 (this indicates the number to spawn at Beginner/Experienced) 68D85h: 04 -> 00 (this indicates the number to spawn at Superhuman) 68D86h: 02 -> 00 (this is the random amount of extra aliens of this type to spawn) Adjust type 2 to spawn all Tasoth Squad Leaders for Colony Stage 1: 68DC3h: 02 -> 03 68DC4h: unchanged 68DC5h: 01 -> 02 And change their Weapon Loadouts of Type 2 to that of Type 5: 68DCCh: 2A -> 22 (Sonic Cannon) 68DCDh: 2B -> 23 (Sonic Cannon Power Clip) 68DCEh: 2B -> 23 68DCFh: 2B -> 2C (Sonic Pulser) 68DD0h: 2B -> 00 2A is the Thermal Shock Launcher, 2B the ammunition for it. 68DD1h: 28 -> 1E (Heavy Thermic Lance) 68DD2h: 29 -> 2C 68DD3h: 29 -> 2C 68DD4h: 29 -> 2C 68DD5h: 29 -> 2E (M.C. Reader) 28 is the Disruptor Pulse Launcher and 29 its ammunition. Soldiers already carry this in many cases. Adjust type 1 to spawn all Hallucinoid Terrorists for Colony Stage 1: 68DD8h: 01 -> 03 68DD9h: 02 -> 06 68DDAh: unchanged And finally, adjust the Alien Race Type buildup table for the Mixed Tasoth so Type 2 is no longer referring to Hallucinoid Terrorists, but rather to Tasoth Squad Leaders: 76E1Ah: 00 -> 17 P.S.: the amount of aliens to spawn at Veteran and Genius levels is simply the sum of the number to spawn at Beginner/Experienced and to spawn at Superhuman, dividing by 2 and truncating the outcome. P.S. 2: Note that there is a bug with regards to Type 1 aliens for Alien Colony Stage 1 missions. Even though it is set to spawn as an Hallucinoid, it does get assigned items in the Loadout section of the Alien Deployment table; the items are loaded into the bottom right section of the Hallucinoid (where the top left section is the "main" section of 2x2 units), which is likely the reason they don't show up once the Hallucinoid is killed or stunned. Because of that, the only effect of these items is to clog up the already cramped item list. Hallucinoids don't use them anyway, as their attack is hardcoded into the exe. To remove the items from the Loadout section and thereby fix the bug, change the following addresses: First loadout (Sonic Blasta Rifle & 2 Clips): 68DDCh: 24 -> 00 68DDDh: 25 -> 00 68DDEh: 25 -> 00 Second loadout (Sonic Cannon, 2 Clips and 2 Sonic Pulsers): 68DE1h: 22 -> 00 68DE2h: 23 -> 00 68DE3h: 23 -> 00 68DE4h: 2C -> 00 68DE5h: 2C -> 00 Third loadout (Thermal Shok Launcher & 4 Thermal Shok Bombs): 68DE6h: 2A -> 00 68DE7h: 2B -> 00 68DE8h: 2B -> 00 68DE9h: 2B -> 00 68DEAh: 2B -> 00

As promised, here an update on where the game places the Zrbite within the Alien Colony Stage 2 mission. As it is placing items (including those held by units, be they X-Com or Alien), it keeps track of the number of items already present ingame. Surprisingly, it will skip placing the Zrbite if there are already 180 or more items ingame, despite there being enough room in the OBPOS.DAT for 200 items. I'm not sure if it simply reserves the last 20 spots for something else further down in the code, I didn't dig that far. First check against this value is made at address 46376h and when placing the second piece, it is checked against the value at address 463B3h. Both equal B4h, which is 180 in decimals. It scans the GeoData.Dat array to find the module with value 0Fh (15), which corresponds to the module with the Synomium Device on the ground floor. The address with this value is at 46344h. Once it has found it, it will place two stacks of Zrbite within the module, depending the item limitations. The first one is placed at (14, 14, 1), which is directly below the Ion Beam Accelerator in the lower right of the room, in the section closest to the wall. Address 46388h holds the value 01h, which is the Z-coordinate, while 4638Dh holds the value 0Eh, which is used for both the X and Y coordinate of the chunk of Zrbite. The second one is (likely erronously) placed at (10, 4, 1), which is below the Alien Implanter near the top right corner of the module. Much more likely is that it should have been placed at (4, 10, 1), which would place it below a section of Ion Beam Accelerator which is exactly diametrically opposed to the location of the other chunk of Zrbite when considering the Ion Beam Accelerator configuration of that room. The address 463BCh holds the value 0Ah (10 in decimals), which is assigned to the X coordinate, address 463CAh holds the value 04h, which is assigned to the Y coordinate and finally, address 463CFh holds the value 01h, which is assigned to the Z-coordinate. The item IDs that are placed there are located at address 4637Eh and 463C8h, both containing the value 2Dh (45 in decimals), which is the ID for the Zrbite item. Note that internally, the floors are numbered from 0 for the top floor to 3 for the bottom floor; ingame, this is shown exactly opposite, which has the ground floor as floor 0. The above Z-coordinate refers to the internal coordinate system, not the ingame coordinate system.

Thanks for that explanation . I've never used XComUtil, to be honest. I've been tempted to download it and see what it offered, but never got around to it. The option to just play a battle seems interesting and can be useful to train combat tactics. Actually I am having a lot of fun (even if it's sometimes rather frustrating, too ) to dig through the code and distill all these little tidbits of information as well as uncover bugs - and figure out ways how to patch them hard-coded into the .exe.

While exploring the GeoScape.exe and finding Craft Loadouts and Alien Stats of its crew, I also stumbled on something else: the location where the game places the Zrbite. In my game (DOS v1.0 TFTD), starting from address 689E9h, there are 17 strings of 6 bytes each. Writing them out, we get: 06 45 100 2 2 3 07 45 100 3 10 3 08 45 100 8 5 3 08 45 100 8 3 3 09 45 100 3 9 2 09 45 100 3 10 2 10 45 100 12 8 3 10 45 100 14 9 3 10 45 100 14 6 2 10 45 100 15 5 2 11 45 100 2 17 3 11 45 100 3 16 3 11 45 100 12 3 3 11 45 100 12 26 3 12 45 100 2 11 3 12 45 100 2 8 3 12 45 100 3 10 3 The first column of these refers to the type of USO, according to this table on the UFOPedia site. The second column holds the item ID to be placed. Item ID 45 is Zrbite. The value in the third column is used to compare against a random value between 0 and 99. I suspect it has something to do with damaged USO's, where the value of 100 is lowered - and therefore, has the odds of having the Zrbite destroyed, but I am not certain. Columns four, five and six are the Y-, X- and Z-coordinates respectively. Note that the Zrbite of the Escort is placed just outside the USO, as it misses the Ion Beam Accelerator in that ship by 1 in the Y-direction. Also, both Zrbite units of the Heavy Cruiser should be moved 1 spot further in the Y-direction to be placed under an Ion Beam Accelerator, too. It's arguable whether or not the Zrbite of the Cruiser is placed correctly, as it's not placed under an Ion Beam Accelerator, but rather in the pointy tail of the vessel under one of the grey orb objects. When the Cruiser is damaged, the Ion Beam Accelerators are gone, after all, not its tail section. P.S.: the game also places Zrbite in one of the Colony Stage 2 Map blocks, but that location is not embedded in the .exe at the location of the USOs. I've found the place in the exe where it gets added; I'll work that one out tomorrow evening, it's getting too late now to do it right now.

The UFOPedia lists the effects of difficulty levels on Alien stats, but it is yet missing the effects of the difficulty levels in TFTD. Below is an overview, derived from the game code itself (DOS v1.0 TFTD). Armor effects (factor is applied to all armor: front, rear, left, right and under): Beginner: 40% Experienced: 70% Veteran: 100% Genius: 110% Superhuman: 120% These values are hard-coded into the .exe. In my version, the values can be found at these addresses: 457E3h: 28h (40 in decimals) 457FCh: 46h (70 in decimals) 4580Eh: 64h (100 in decimals) 45820h: 6Eh (110 in decimals) 45832h: 78h (120 in decimals) Changing them will also change the effects on armor of all Aliens at the corresponding difficulty level accordingly. For other stats, the difficulty level is put through a (minor) calculation to find the alterations. The formula itself is fairly easy: [ ( Difficulty Level * Weight ) / 100 + 1 ] * Base Stat Value The Base Stat Value is derived from the Alien Stats table and all resulting values are truncated. Weight depends on the specific skill and is either 8, 6 or 4. Keep in mind that for TFTD, the difficulty levels are scaled as 0 = Beginner, 1 = Experienced, 2 = Veteran, 4 = Genius and 6 = Superhuman. Genius and Superhuman are probably at respectively 4 and 6 specifically for these calculations. Time Units, Stamina, Melee Accuracy, M.C. Skill and M.C. Strength have a Weight of 8%. In table form, the Base Stat is increased by: Beginner: 100% Experienced: 108% Veteran: 116% Genius: 132% Superhuman: 148% Reactions and Firing Accuracy have a Weight of 6%. In table form, the Base Stat is increased by: Beginner: 100% Experienced: 106% Veteran: 112% Genius: 124% Superhuman: 136% Finally, Strength has a Weight of 4%. In table form, the Base Stat is increased by: Beginner: 100% Experienced: 104% Veteran: 108% Genius: 116% Superhuman: 124% As is obvious, the Base Stats are all basically set to Beginner level, since that one is the 100% level - only Armor is an exception, which is by default at Veteran levels.

Well, there is a difference. The executable is located on your harddisk and essentially just a collection of bytes taking up diskspace. In order for the program to run, it has to be loaded into computer memory, where it also reserves all the memory locations for the game's data files and then loads up the data into those memory locations. During runtime, those values will get updated and changed, depending on what the game is doing. When you save your game, all the relevant memory locations are written to files on your harddisk and when you load the game, the values contained in those files are loaded up into memory registers. What I think XComUtil does, is alter the values in those memory registers, leaving the executable (or any other file) as it exists on your harddisk untouched. Rebooting your machine or simply quitting the program will also clear its memory, so you'd lose all alterations that have been made to those memory registers. I assume XComUtil keeps track of the changes you've configured within that tool and that whenever you start the game (and load everything into computer memory), XComUtil will subsequently overwrite the game's data with your personal preferences - again, all in computer memory. My post above details where to find it in the actual executable file on your harddisk - and a fix there will be persistent. Whenever you start up the game from it, it will load everything into memory, including the changes you've made to that file. Hopefully that clears up a bit of the confusion?

After some more thorough analysis of the GeoScape.exe, I've managed to identify a data range that links the Craft Loadout of USO's (including those that spawn Terror missions - and Artefact sites are spawned by Terror ships as well, with a little twist) to the Alien Stats table. In DOS v1.0 of TFTD, starting from address 76DD6h is a string of 98 bytes that takes care of this. Together with 2 padding bytes at the start of the string, these 98 bytes can be split up in 16 bytes per Race Type. Doing as such yields the following table: Race type All missions except surface missions Comm. Navi. Medic Tech. Sq.L. Sold. Terr1 Terr2 0 Aquatoid 12 00 11 00 10 00 09 00 08 00 07 00 00 00 00 00 1 Gill Man 16 00 15 00 14 00 14 00 13 00 13 00 02 00 02 00 2 Lobster Man 21 00 20 00 19 00 18 00 19 00 17 00 04 00 04 00 3 Tasoth 23 00 23 00 22 00 23 00 23 00 22 00 04 00 04 00 4 Mixed Tasoth 00 00 00 00 08 00 07 00 23 00 22 00 04 00 04 00 5 Mixed Lobster 03 00 02 00 04 00 07 00 18 00 17 00 04 00 00 00 Each set of 2 columns is assigned to an alien rank. Alien Rank together with Race Type determine a specific value in this table. These values each link directly into the Alien Stats table for TFTD. For completeness sake, the Alien Stats table for TFTD looks like this (I've omitted the 39 stats for each unit, just kept the number and name): 00 Hallucinoid Terrorist 01 Calcinite Terrorist 02 Xarquid Terrorist 03 Deep One Terrorist 04 Tentaculat Terrorist 05 BioDrone Terrorist 06 Triscene Terrorist 07 Aquatoid Soldier 08 Aquatoid Squad Leader 09 Aquatoid Technician 10 Aquatoid Medic 11 Aquatoid Navigator 12 Aquatoid Commander 13 Gillman Soldier 14 Gillman Squad Leader 15 Gillman Technician 16 Gillman Commander 17 Lobster Man Soldier 18 Lobster Man Squad Leader 19 Lobster Man Technician 20 Lobster Man Navigator 21 Lobster Man Commander 22 Tasoth Soldier 23 Tasoth Squad Leader 24 Coelacanth Tank 25 Male Civs 26 Female Civs 27 Displacer Tank This table is used for any mission at a Touchdown depth deeper than 0. Missions with a Touchdown depth of 0 are all surface missions (before a mission starts with a USO that is "Touched Down", the Touchdown Depth is changed from 0 to randomly 1 or 2) and when it generates aliens for those surface missions, it will alter the values read from the table during runtime. The alteration is to raise all values that are below 5 in the above table by 1, with Mixed Tasoth being a special snowflake: instead of raising it by 1, those values are randomly raised by 1 or 2 (the value is re-randomized for every alien). The table then would look like this: Race type All surface missions Comm. Navi. Medic Tech. Sq.L. Sold. Terr1 Terr2 0 Aquatoid 12 00 11 00 10 00 09 00 08 00 07 00 01 00 01 00 1 Gill Man 16 00 15 00 14 00 14 00 13 00 13 00 03 00 03 00 2 Lobster Man 21 00 20 00 19 00 18 00 19 00 17 00 05 00 05 00 3 Tasoth 23 00 23 00 22 00 23 00 23 00 22 00 05 00 05 00 4 Mixed Tasoth XX 00 XX 00 08 00 07 00 23 00 22 00 YY 00 YY 00 5 Mixed Lobster 04 00 03 00 05 00 07 00 18 00 17 00 05 00 01 00 The value for XX is either 1 or 2, the value for YY is either 5 or 6. Mixed Tasoth Terror missions never have Commanders, but they will have Navigators (1 to be precise, if I am not mistaken - there is one Navigator listed in the Battleship Craft Loadout, the Craft responsible for carrying out Terror Missions - unless I am mistaken in where the game deploys Mixed Tasoth crews). Notice that when it generates a Terror Mission, it will replace the Navigator by either a Calcinite or a Xarquid - essentially allowing the possibility to generate a Xarquid in a surface mission. I suspect that they wanted to have random Terrorists in the mission, by spawning either Bio-Drones or Triscenes, but then overlooked the Navigator in the process. In about 50% of the missions, it would probably not even be noticed, as it would spawn a Calcinite. Looking at the code, the easiest way to fix it is simply by setting the Alien stats link value of the Navigator from 00 to 23. P.S.: Note that the alien ranks listed above the tables and also used in the Alien Stats table are just references to different versions of a given alien. This is most clear for Tasoths, which use only 2 versions (designated as Soldiers and Squad Leaders) and other ranks simply refer to one of those 2, mostly the Squad Leader variant. In many cases, the rank listed in the Alien Stats table doesn't match the position within the table, because it's no more than a variant counter of the alien in question. Maybe it was used initially (original UFO?), but it seems that the rank table in the Alien Stats listing has no purpose (anymore), given that some of them occur in multiple places in the table.

I know X-Com Util fixes this, but I think it fixes it in memory. I don't know how the creator figured out where to patch it, but I assume he found the memory reference. In my post above, I've pinpointed the location within the .exe itself . I've already patched my own exe to spawn the 26th unit inside the craft. Actually, I am considering changing the layout rather more drastically as I want to have the HWP's right next to or close to the door. In the current incarnation, you first need to unload two soldiers to make room for the HWP to exit, potentially opening those soldiers up to hostile fire. As it is, HWPs are placed inside the craft first, so the first one will occupy spawn nodes 1, 2, 3 and 4. The second one the next four, etc .... I just need to make sure to place those clusters together in the craft near the door and the other nodes around it

After some analysis of the GeoScope.exe file, I've managed to find the tables responsible for deploying the Soldiers within an X-Com craft in missions that feature them. In the DOS v1.0 of TFTD, it can be found almost at the very end. Starting from address 75EF8h, there are 26 sets of 3 bytes for each of the three Troop carriers that the player has access to. The first set of 78 bytes is for the Triton, the second set is for the Hammerhead and the third set is for the Leviathan. Explicitely: Triton: address range is 75EF8h to 75F45h. Hammerhead: address range is 75F46h to 75F93h. Leviathan: address range is 75F94h to 75FE1h. Each range is composed of 26 sets of 3 bytes each, one for each X-Com soldier spawn node, in sequential order. The first byte is the X-coordinate of the node, the second byte is the Y-coordinate and the third one is the Z-coordinate (relative to the craft map, not the eventual total map!). A curious note: usually they put the Y-coordinate in front of the X-coordinate wherever they use them. That's not the case here, surprisingly. Organised per spawn node (instead of per craft): Triton Hammer Leviathan X Y Z X Y Z X Y Z 01 5 7 2 5 7 2 5 10 2 02 4 7 2 4 7 2 4 10 2 03 5 6 2 3 7 2 5 9 2 04 4 6 2 5 6 2 4 9 2 05 5 5 2 4 6 2 5 8 2 06 4 5 2 3 6 2 4 8 2 07 5 4 2 5 5 2 5 7 2 08 4 4 2 4 5 2 4 7 2 09 5 3 2 3 5 2 5 6 2 10 4 3 2 5 4 2 4 6 2 11 5 2 2 4 4 2 5 5 2 12 4 2 2 3 4 2 4 5 2 13 3 7 2 0 0 0 5 4 2 14 3 6 2 0 0 0 4 4 2 15 0 0 0 0 0 0 5 3 2 16 0 0 0 0 0 0 4 3 2 17 0 0 0 0 0 0 6 9 2 18 0 0 0 0 0 0 3 9 2 19 0 0 0 0 0 0 6 8 2 20 0 0 0 0 0 0 3 8 2 21 0 0 0 0 0 0 6 7 2 22 0 0 0 0 0 0 3 7 2 23 0 0 0 0 0 0 6 6 2 24 0 0 0 0 0 0 3 6 2 25 0 0 0 0 0 0 6 5 2 26 0 0 0 0 0 0 0 0 0 Note how spawn node 26 is 0 0 0 for the Leviathan - that's the bug where the soldier in slot 26 is spawned on the relative location (0, 0, 0) of the Leviathan map block instead of inside the craft (note that the Leviathan map itself only has 3 floors, with the ground floor having a Z-coordinate of 2; all overall maps with an X-Com Craft in it have 4 floors, a 4th one is added on top of it, changing the Z-coordinate of the ground floor to 3 instead of 2. This causes the Soldier in slot 26 to appear at (X, Y, 1) on the map, with X and Y being the offset values for the map block that holds the Leviathan). Schematically, when we translate the above coordinates, we get the following layout for the Soldier spawn nodes for each X-Com craft: Triton: \ X 00 01 02 03 04 05 06 07 08 09 Y \ ------------------------------ 00 | __ __ __ __ __ __ __ __ __ __ 01 | __ __ __ __ __ __ __ __ __ __ 02 | __ __ __ __ 12 11 __ __ __ __ 03 | __ __ __ __ 10 09 __ __ __ __ 04 | __ __ __ __ 08 07 __ __ __ __ 05 | __ __ __ __ 06 05 __ __ __ __ 06 | __ __ __ 14 04 03 __ __ __ __ 07 | __ __ __ 13 02 01 __ __ __ __ 08 | __ __ __ __ __ __ __ __ __ __ 09 | __ __ __ __ __ __ __ __ __ __ Hammerhead: \ X 00 01 02 03 04 05 06 07 08 09 Y \ ------------------------------ 00 | __ __ __ __ __ __ __ __ __ __ 01 | __ __ __ __ __ __ __ __ __ __ 02 | __ __ __ __ __ __ __ __ __ __ 03 | __ __ __ __ __ __ __ __ __ __ 04 | __ __ __ 12 11 10 __ __ __ __ 05 | __ __ __ 09 08 07 __ __ __ __ 06 | __ __ __ 06 05 04 __ __ __ __ 07 | __ __ __ 03 02 01 __ __ __ __ 08 | __ __ __ __ __ __ __ __ __ __ 09 | __ __ __ __ __ __ __ __ __ __ Leviathan: \ X 00 01 02 03 04 05 06 07 08 09 Y \ ------------------------------ 00 | 26*__ __ __ __ __ __ __ __ __ 01 | __ __ __ __ __ __ __ __ __ __ 02 | __ __ __ __ __ __ __ __ __ __ 03 | __ __ __ __ 16 15 __ __ __ __ 04 | __ __ __ __ 14 13 __ __ __ __ 05 | __ __ __ __ 12 11 25 __ __ __ 06 | __ __ __ 24 10 09 23 __ __ __ 07 | __ __ __ 22 08 07 21 __ __ __ 08 | __ __ __ 20 06 05 19 __ __ __ 09 | __ __ __ 18 04 03 17 __ __ __ 10 | __ __ __ __ 02 01 __ __ __ __ * = this node isn't on the ground floor, but 2 floors higher up. The fix is easy enough: just alter the three bytes at address range 75FDFh - 75FE1h from 00 00 00 to 03 05 02. This places node 26 just above node 24 and to the left of node 12, where it should belong. Probably when designing the craft layout, the developer assumed counting the nodes from 0 to 25, instead of from 1 to 26.

The above also applies to T'leth Stage 1, which is random too. I've also seen that there are more maps that suffer the "too many viable spawn nodes" issue, which causes some to never get populated in any game. Alien Colony Stage 2 suffer from it, but missions like Ship Terror missions (hence you encounter most aliens on the ground floor; applies to both Stage 1 and Stage 2 of either ship type) and T'Leth Stage 3 also suffer from it. The latter one is a pity, as you will encounter virtually all Aliens in that mission in the first part (roughly 1/3rd) of Stage 3, with just a few stragglers throughout the remainder. The only way to solve this is to edit the RMP files and make sure to do two things: - Make sure the total number of nodes is roughly equal to ~7 per 1x1 block (so 2x2 blocks have 4 times that number, 28), so you won't exceed the 250-node limit; - Make sure the total number of valid nodes for each priority level doesn't exceed ~40 across the entire map, so ~1 of each priority type per 1x1 map block (and likewise, ~4 for 2x2 blocks); It might be worth experimenting a little with the maximum limit, see if it can be raised higher. That would at least remedy the first issue. I assume that both limits are for performance reasons, actually ...