Talk:WORLD.DAT

// World.Dat = World Map Terrain

  typedef struct worlddat
  {
     short         QuadData[4][2]; // Coordinates of quadrilateral
     unsigned long texture;        // Terrain texture of quad
  } WorldDat;
  
  #define MaxQuads 768      // Observed values, XCOM = 666, TFTD = 733

QuadData/8 = realworld latitude and longitude numbers.

if QuadData[3][1] = -1 then the shape is a triangle and that entery is not used. (for you non programers QuadData[0] is the first so [3] is the forth.)

This may not be usefull for the wiki but I once wrote a program to detect what world.dat entry a givin ship was located in and therefor what texture/terrain file used to create the battlescape map. I have the function if anyone is interested in the math.

--BladeFireLight 21:24, 20 January 2007 (PST)

---

Gah, I just spent the last 20 minutes or so figuring this file out, wish I would have seen this before.

Wonder how it defines the countries since this file only seems to designate terrain types. Maybe indexed all the polygons in this file? Be tough to find it then...

Oh, and one thing. When QuadData[3][0] is -1 when it designates a triangle (and actually QuadData[3][1] is 0 as well).

I'll probably put this info on the page article here soon though. --Pi Masta 19:42, 5 April 2007 (PDT)

---

Pi Masta, can you post an overlay of the TFTD world map? My first thought was that it was a representation of the quad's depth, but that doesn't seem entirely right either. Or perhaps it's a combination of terrain and height in the single byte? - NKF

---

Yeah it definitely holds terrain data. the TFTD map took a bit to recognize (aka make sure I was rendering it correctly) as it defines the oceans and not the land. I don't remember the depths that TFTD had, but didn't it also have missions on land as well? With differing land types? I never got into TFTD so my knowledge is limited.

I probably should upload a wire-frame version of the TFTD map, where you can see some of the overlaps. Well, I assume they are overlaps, otherwise they are really really small triangles.

This file is a bit of a pain to render as the points will cross the prime meridian thus X values will go from say 6 to 2700 to 2750 to 200, etc. in the same polygon line. I broke them up and split polygons when the difference was large and for TFTD it worked great. It was XCOM that was a problem and eventually I just excluded the troublesome polygons from being split (still rendered).

--Pi Masta 15:34, 10 April 2007 (PDT)

---

TFTD has four depth levels, one of which is "surface". However the game only puts polygons on the water so presumably this file would only cover three levels (all land missions are terror sites).

For UFO, I did some value tweaking and came up with these referrences on battlescape terrain:

 0 - Jungle
 1 - Farm
 2 - Farm
 3 - Farm
 4 - Farm
 5 - Mountain
 6 - Jungle
 7 - Desert
 8 - Desert
 9 - Polar
10 - Jungle
11 - Jungle
12 - Polar

This does more or less match the imagery, but the problem here is that even with multiple missions on each terrain type I couldn't get a forest to appear. My thought is it has something to do with the position on the globe as all the missions I did were in the one area (south pole).

Values above 12 seemed to all use jungle as well, and looped through the usual texture images (oddly enough, I still had to add images to the set to prevent a crash).

- Bomb Bloke 21:29, 1 January 2008 (PST)

---

If I'm not mistaken, the game picks between forest and jungle terrain depending on which part of the hemisphere you're on. Everything north of the Equator uses forest terrain while everything south of the Equator goes with jungle terrain.

- NKF

---

Is there any place in the article that we can elaborate that the 2880/1440 values makes for a resolution of 00°07'30"? I know it's not neccessary to the data file, but I think it's a nice little real-world statistic. --Danial 22:41, 29 January 2008 (PST)

---

Thank ye kindly NKF. :)

Ok, so I've gone and thrown all that stuff in the wiki page and nerfed the content re depth (as after quite a bit of testing I wasn't able to affect mission depth with WORLD.DAT values at all).

It might be a while before I play with this file again (mostly I mess with the battlescape data), so while it's fresh in my mind a few other points:

Where regions are located does seem to be controlled by this file... Kinda. For example, I got the impression that polygons 0 to 20 might be "America", polygons 21 to 35 might be "Russia", and so on and so forth. Move the polygons and you move the regions. As for which polygons are assigned to each region, that's gotta be in the executable (the border map you see by pressing space (or other buttons) is probably also in the executable, and is likely only cosmetic). If I get the time (and the right level of boredom) I'll try and create a list of which polygons point where.

I mentioned any TFTD location could produce a "Seabed Rubbish" or "Coral" mission, but I didn't mention the odds of these two turning up for any given polygon. Yeah, I didn't do enough tests for that... Polygons 0 and 8 could actually be set to use one of those two terrains (making one more likely to appear then the other).

By comparing the terrain lists to offset 10 in GEODATA.DAT, I came up with these strings:

?? 01 01 01 01 07 ?? 06 06 08 ?? ?? 08 (UFO)

?? 01 02 03 04 05 06 07 ?? 07 06 01 04 (TFTD)

I was able to find the first one in the executable, but TFTD's version eludes me...

- Bomb Bloke 02:20, 31 January 2008 (PST)

Borders data

FYI, in my UFO Defense Gold Edition executable (495 616 bytes), country borders data starts at offset 74AD4: 0xFFFF indicates the start of a new polyline, then each pair of words is a coordinate. 0xFFFE indicates the end of border data.

It looks like this (in my favorite tool ;-) ):

.data:00474AD4 GeoBordersData  dw 0FFFFh               ; DATA XREF: GeoDrawBorders+3�r
.data:00474AD4                                         ; GeoDrawBorders+C�o
.data:00474AD6                 dw 221h
.data:00474AD8                 dw 0FF43h
.data:00474ADA                 dw 238h
...
.data:00474DF4                 dw 0FE71h
.data:00474DF6                 dw 0FFFEh

HTH

Terrain Type 12 in UFO

Heh, I see you already updated terrain type 12 in UFO, MTR. I didn't realize you did this so I modded world.dat so that the polar area of Siberia is type 12 instead of 9. Everything checks out like you mentioned. Anyway, just thought I should upload the pic so other people could see it. --Zombie 19:15, 19 September 2008 (PDT)

Coolness. Actually, Pi's graphic on the WORLD page clinched it for me... look at where his terrain 12 is. I am in email with him concerning area calculations and etc. as we speak. -MikeTheRed 19:19, 19 September 2008 (PDT)

Map Wrap problem with WORLD.DAT

I've been trying to help Zombie with determining how much of the globe is covered by the various terrains. But I've hit a brick wall with WORLD.DAT records' areas (triangles or quadrilaterals) that cross the "date line" in the middle of the Pacific.

X-COM "longitudes" go from 0 to 2800. The dateline is where 0 and 2800 butt up against each other in the Pacific. It is, of course, possible to have a WORLD record whose area straddles the line (think, Hawaii)... a little of the quad is east of the line, and a little is to the west of it. Mathematically, this can be treated very easily by adding 2800 to the X coordinates to the east of the dateline. That's easy.

The real problem is determining which of the records with huge differences in X coordinates (i.e., approaching 2800) validly cover that amount of area.

1. As a first test (crossing my fingers that it would be this simple), I subtracted the lowest X coord from each record's highest X coord, to give a "max length estimate" (MLE) for each record. I was hoping most MLEs would be below, say, 1000, and all the rest would be up around 2800. But alas. While most records' MLEs were ~600 or less, and there was a spike of ~24 MLEs at 2700+, there was no "clear gap" between the low values and the high-end maxima. A histogram shows bin counts (with bins being 300 "wide") fall off a lot above ~600, but there is still a small number of counts in every bin, until you hit the spike at 2700+.
2. As a second test, I thought "why not test to see if any records have one leg that's longer than all the others put together". In other words, some kind of discrepancy with the leg lengths. I thought myself clever... but alas. Each area "makes sense" in terms of being a closed figure, so not a single record had a discrepancy. In other words, if one leg was real long, there was always another one that was, too. This method couldn't tell between legitimately large areas, and illegimate dateline wrap-arounds.
3. Finally I tried counting the number of legs for a given record that are greater than some arbitrarily high number (like 2600). This is sort of a variation on the first test; I was hoping for a clear division where most records have 0 very long legs, and approx. two dozen have two long legs. Foiled again, though... while most have 0 long legs and a cluster has 2 long ones, there are always a few that have 1 long leg (and no, they're not always triangles).

I can't help but think that there must be some easy way to do this, but I can't think of it. If I could do this graphically, it might be readily apparent... but I haven't worked with graphics at this very-basic level and don't know how to turn coordinates into a graphic figure. (Actually, I can do it, but it's just 4 points on an Excel X-versus-Y graph that aren't otherwise meaningful; they're not superimposed on a map of the globe or anything.)

Clear as mud? Does anyone have ideas? Pi Masta?? -MikeTheRed 17:21, 17 October 2008 (CDT)

The only thing I can think of is a brute force method. Flag a record which have huge differences in the X-coordinates, then edit it so the terrain type is something easily recognizable (like mountainous), go in the game and verify where the record resides. There can't be anything more straight forward than that, no? My 2 cents.--Zombie 21:32, 17 October 2008 (CDT)

Now there's an idea. Remind me... WORLD.DAT is not saved to the savegame slot, but I don't have to reload all of X-COM... I can just alt-tab to switch WORLD.DAT, and reload a "same old" GEO savegame, Right? ... Maybe it will get me past my mental wall of, not knowing how to handle these abstract coordinates, even. -MikeTheRed 21:51, 17 October 2008 (CDT)

Correct, just reload a saved game while the game is running and presto, the map should be updated. By the way, approximately how many records have huge differences in X-coordinates? If there are a lot of them, a brute force method may take some time. But from what I remember from the file there are only a handful records which meet this criteria. --Zombie 22:02, 17 October 2008 (CDT)

About two dozen. I'll take a crack at it; it's entirely possible that visualizing the first few may make things very clear. But give me a week or so. And if anybody has a brighter idea, jump in. -MikeTheRed 22:20, 17 October 2008 (CDT)

So, all these records with huge differences occur around the "dateline", in the Pacific ocean where the game meshes the start and the end of the render together, correct? There isn't going to be huge tracks of land in the Pacific ocean, so couldn't you just pretend that the areas are small and do it that way? A couple dozen records are just enough to indicate they are Hawaii and other small islands surrounded by ocean. Suppose it couldn't hurt to double check the theory, but that's my take on it. --Zombie 22:40, 17 October 2008 (CDT)

It fries my brain a little when I see that one coordinate of a record is an origin (e.g. X 0, Y +720), while the other coordinates are all over the place. A fair number of the high MLE records are like this. Is there a big strip coming down from the poles? Or around the equator? I think your idea of simply seeing what happens when you edit WORLD.DAT is a great idea. I didn't think of that approach... it's been too long since I sat down and hacked the game. But in this case, hacking the game supplies exactly what I said I couldn't visualize - seeing the difference superimposed on not just any map, but X-COM itself. Thanks bro. You owe me some excellent java. -MikeTheRed 22:57, 17 October 2008 (CDT)

Ah, I forgot about the origins. In that case, yeah, there are some fairly large tracks of land which start at the poles and radiate down (or up, depending on the hemisphere). You could double check that by looking at the terrain type and verifying if it is 9 or 12. If you give me the record numbers which straddle the dateline, I could help you out by editing a few of them for you and marking it on the globe. That way you don't have to do so many of them. --Zombie 23:22, 17 October 2008 (CDT)

Which Prime Meridian?

Some clarification here, please. Comments above say that the game engine's zero longitude meridian, X=0, is somewhere around the (real world) International Date Line, in the middle of the Pacific. But if you look at the maps rendered from the WORLD.DAT data, they appear to start at (real world) Greenwich Meridian, at 0° longitude: England is right at the left of the map, presumably the start of the render. Which is correct? Did the Bros. Gollop start in Greenwich and number 0-359° East longitude (in eighths of a degree)? Or did they start around Hawaii and number 0-359° East longitude from there? Spike 16:33, 5 December 2008 (CST)