Talk:WORLD.DAT

Terrain

  // 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 -Seb76, 31 January 2008

Hey Seb76, you posted the information above. By any chance, did you also find borders for continents? XCOM must track them, because it tells you where you are when you start to make a new base. It could help Zombie and me relative to posting the percent of area devoted to different terrain types, because southern continents use jungle and northern ones use forest, for the same terrain code in WORLD.DAT. -MikeTheRed 20:38, 30 April 2009 (EDT)

The continents data is located at 0x474F38. Each entry represents a quad (4 values of 2 bytes) and a continent (2 bytes):

.data:00474F38 18 06 87 09 D0 FD 47 FE 00 00+geo_globe_zones structGlobeZone <618h, 987h, 0FDD0h, 0FE47h, 0>; 0
.data:00474F38 30 07 87 09 48 FE 0F FF 00 00+                                        ; DATA XREF: GetWorldZoneFromPos+10�o
.data:00474F38 80 07 5F 09 10 FF AF FF 00 00+structGlobeZone <730h, 987h, 0FE48h, 0FF0Fh, 0>; 1
.data:00474F38 00 00 3F 0B 30 FD CF FD 01 00+structGlobeZone <780h, 95Fh, 0FF10h, 0FFAFh, 0>; 2
.data:00474F38 00 00 3F 0B E0 01 D0 02 02 00+structGlobeZone <0, 0B3Fh, 0FD30h, 0FDCFh, 1>; 3
...
.data:00474F38 28 00 B8 01 40 01 DF 01 0D 00+structGlobeZone <0A28h, 27h, 78h, 1DFh, 0Dh>; 29
.data:00474F38 B8 01 2F 02 88 FF 4F 00 0E 00+structGlobeZone <28h, 1B8h, 140h, 1DFh, 0Dh>; 30
.data:00474F38 30 02 CF 02 D8 FF 4F 00 0E 00+structGlobeZone <1B8h, 22Fh, 0FF88h, 4Fh, 0Eh>; 31
.data:00474F38 B8 01 47 03 50 00 DF 01 0E 00 structGlobeZone <230h, 2CFh, 0FFD8h, 4Fh, 0Eh>; 32
.data:00474F38                               structGlobeZone <1B8h, 347h, 50h, 1DFh, 0Eh>; 33

At 0x475090, the country data starts (using the same format). HTH Seb76 13:31, 1 May 2009 (EDT)

Very cool! Listen, if you can capture the country and continent data, I can turn it into e.g. a spreadsheet that I'll post here. You can email it via my User link or post it as a new page with a hotlink here (so as not to clutter this one too much). If it's too much trouble, don't worry about it. The formats above are fine, but I have a couple of questions about what I'm looking at. If you're up to it. Thanks! -MikeTheRed 19:36, 7 May 2009 (EDT)

Concerning the format, the game uses a series of "quads" (xstart,ystart,xstop,ystop IIRC) and a continent number for each quad. It is quite crude, but the game crosses this data with the polygon data. So, for a given point it checks if it is on water or land, and then which quad it is contained into to deduce the continent's ID. Seb76 17:12, 9 May 2009 (EDT)

Thanks. Any chance you can send the two datsets to me? If not, I can get it. Sounds like you're primed to capture it, though. -MikeTheRed 18:25, 12 May 2009 (EDT)

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)

Actually it was easier just to go and find out. The X=0 meridian is the real world prime meridian running through Greenwich, UK. This was determined by hacking my starting base location in LOC.DAT.

Spike has it right and I have to admit - I made that mistake and have been posting that it's at the dateline, but in hindsight this was only an assumption based on how the XCOM Geoscape acted a little weird for me in the Pacific sometimes (plus I assumed the devs made it easy on themself). By coincidence, I just hacked WORLD.DAT today to address the wrap problem (see above) and indeed, it is at the usual Greenwich meridian (see my alternate File:WORLD DATwithTerrainChangedFor24SuspiciousAreas.DAT). Anybody is welcome to cleanup places where I said the meridian is at the dateline. -MikeTheRed 18:09, 5 December 2008 (CST)

Hey thanks MTR for clearing that up.

One more question - this is being a bit picky, but - shouldn't the correct range for longitude be stated as "2880 values, from 0 to 2879"? 2880 is the same as 0, and 'wraps' to 0, right? Spike 17:11, 6 December 2008 (CST)

The precomputed trigonometry reference tables COS.DAT and SIN.DAT have lookup values for 0 through 2880, although 2880 indeed 'wraps' (has the same values as 0). I used these reference tables to decide what the authoritative range was. -- Zaimoni, 11:48, 7 December 2008 (CST)

Sounds right. For the record, in WORLD.DAT, the minimum X value is 0 and the maximum is 2877 (in terms of what actually appears in the records). But it's an easy stretch to assume that the displayed coordinate system goes to 2879 (there just don't happen to be any corner points of areas that fall on 2879).

Cool, that nails it, Zaimoni. Thanks! -MikeTheRed 12:30, 7 December 2008 (CST)

FWIW, I don't understand why "the resulting map could be said to have a spatial resolution of 00°07'30" (one-eighth of a degree)". To me, it makes more sense to compare it to degrees and minutes, and I can wrap my brain around something like this, better: "the XCOM coordinates have 13% of the precision of the real world's degree:minute value system (2880/(360*60) = 2/15 = 1/7.5)". Extending it to seconds seems arbitrarily harsh; it could also be arbitrarily extended to decimals of seconds - even harsher. Also FWIW there is, of course, a 2:1 relationship for longitude to latitude in the XCOM values (2880:1440), just like in real life (360:180). (Actually, 1441 and 181 values, but who's counting.)

Same here, I inserted the phrase "eighth of a degree" to soften up, and to get my own head around, the 'harsh' statements made previously by somebody that referred to 00°07'30". Spike 19:08, 6 December 2008 (CST)

Interestingly, while we mainly use offsets on the wiki (values start at 0, not 1) because programmers do - even though counting starts at 1 for most of "the regular world" - here's a case where reality uses an offset, too. The Prime Meridian is 0, not 1. :P -MikeTheRed 18:36, 6 December 2008 (CST)

AI Helpful Cheating

Incidentally this [test above] also showed that the AI cheats and sends its missions to the area around your starting base. Even though I teleported my base from Hawaii to Casablanca at the start of the game, all the UFO missions still flew to the Pacific region in January. Then in February, all the missions shifted to North Africa or adjacent regions. The Pacific area went totally quiet. So the game "knows" where your base is, and plans the missions accordingly. Spike 17:08, 5 December 2008 (CST)

The AI sending its missions in January near the first X-COM base is called "Giving the player a sporting chance." Arrow Quivershaft 22:18, 5 December 2008 (CST)

Not to mention making the game more fun and more playable. This is a well established principle, as evidenced by the fact that when the Daleks want to invade the Earth, they always start their attack in England, purely because that's where Dr Who lives. :) Spike 17:11, 6 December 2008 (CST)

I thought the Daleks did that cause they recognize Dr Who as the only force on Earth which can stand in their way?

It's not just January... the AI seems to give aliens a tendency to follow X-com around all through the game? I find that even in late game, the aliens seem to center on my original base, instead of a smooth worldwide distribution of activity.

Spike, your test has also proves that the aliens queue up their missions at the beginning of each month. Hmm... Jasonred 05:57, 2 May 2009 (EDT)

World Area and Cylinder vs. Sphere

Ok Zombie, I finally finished all the math on the areas of terrain types in WORLD.DAT... I'd upload it here, but the Upload File link here is not working for me - is it working for others?

Anyway, I got a somewhat surprising result, that I'm hoping someone can help with. Apparently, WORLD.DAT is "straight up" areas; the XCOM devs did not control for sphericity per se (which is probably simply handled, for all practical purposes, by how it maps onto a "3D" globe in the Geoscape). Which is to say, when I calcuated areas, the poles got stretched way big, very much like the "cyclindrical projection" of the Earth seen in Pi Masta's "maps" on the WORLD.DAT page... and the terrain types of 9 (Ice) and 12 (Icebergs) account for 43% of all XCOM Land. Of course, this makes zero sense if you look at a globe (in XCOM or elsewhere). A quick check of the WORLD.DAT areas shows that Ice and Icebergs have an average latitude of 70° (this is if you take absolute values; otherwise South cancels North). Now, this is just an average of the latitudes of the centroids of each area, and doesn't take into account at all e.g. how large each one is (there could be a lot of tiny ones in Siberia, and a few huge ones at the Poles). Furthermore, it is 43% of the *land* found in WORLD.DAT - Ocean isn't accounted for at all (in XCOM terms, it is simply the absence of any WORLD.DAT land). But anyway, it does show that polar land in the Geoscape could definitely be way overestimated, if one takes spherical coordinates but treats them like a cylinder. Like I just did. :P

Anyway, to make a long story short... Would anyone know a way to "sphericalize" this data, so I can turn it into real-world areas? I'm not sure exactly how that would work - I used the Surveyor's Formula to get areas to begin with; would I have to back all the way up to actually using some variation of Surveyor's for a spherical surface - and WTH would that look like? Or would it be a close enough approximation to simply scale the area of each record somehow, based on the centroid latitude (average of its Y values)? Or maybe I can just straight up scale them relative to the Equator being 100% of area, the Poles being 0% of area? (None of the records actually have a centroid latitute of 90°, of course - in fact the largest ABS(centroid of latitude) is 85°.)

If I can get a handle on this, we could ultimately do a rough check of all my computations by comparing it against the land area of Earth.

Help, anyone? -MikeTheRed 22:24, 20 November 2009 (EST)

Well, latitude/longitude coordinates don't correct for sphericity either.

The catch, here, is that the length of a degree of longitude varies by latitude. Recall that the scaling factor to convert the length of a degree of longitude at the equator, to a degree of longitude at latitude θ, is cos(θ). How to proceed from there depends on how you want to numerically model it (integration is feasible, while trapezoid approximations are easy to visualize and should be workable until very close to the poles.) -Zaimoni 13:44, 21 November 2009 (CST)

I don't have intergration apps at hand. Cosine of theta. You bastard. Now I have to refresh myself on geometry, lol. Question: Does a scale from 100% to 0%, closely approximate real life -MikeTheRed 16:50, 21 November 2009 (EST)

cos(0°) is 1 i.e. 100%; cos(90°) is 0 i.e. 0%. So it is a scale from 100% to 0%, it just isn't a linear scale. -Zaimoni 11:02, 22 November 2009 (CST)

Seems to me that to compute this on paper would take far too long. For example, say you were to draw one of the polygons, then scale each line of that polygon according to the latitude (multiply it by cos(latitude), I guess). You'd then be able to add up the resulting number of points covered, and get the area as a result... But this'd take far too long to do by hand.

It may be that there's a formula that can be applied to determine the area covered by a given polygon to a spherical surface (still too much effort to do on paper), but off the top of my head I can't even think of one to do it with a flat surface, so getting a computer to do all the math in bulk seems to be the easiest way.

The results would end up approximate however you do it, because the real world isn't a sphere.

- Bomb Bloke 19:38, 23 November 2009 (EST)

Ok, so here's what I came up with for the 2D map:

2D map is 2880x1440 with 4147200 points total, with a land area of 1542330 points (37.189670138888886%).
00: Forest     = 53876 points (1.2990933641975309% world area, 3.4931564580861427% land area), Jungle = 189766 points (4.5757619598765435% world area, 3.4931564580861427% land area)
01: Farm       = 32441 points (0.7822386188271605% world area, 2.10337606089488% land area)
02: Farm       = 134294 points (3.238184799382716% world area, 8.707215706106993% land area)
03: Farm       = 72882 points (1.757378472222222% world area, 4.725447861352629% land area)
04: Farm       = 138245 points (3.3334538966049383% world area, 8.963386564483606% land area)
05: Mountain   = 13513 points (0.3258342978395062% world area, 0.8761419410891313% land area)
06: Forest     = 346 points (0.008342978395061729% world area, 0.02243359073609409% land area), Jungle = 24708 points (0.595775462962963% world area, 0.02243359073609409% land area)
07: Desert     = 105327 points (2.539713541666667% world area, 6.829083270117291% land area)
08: Desert     = 23575 points (0.5684558256172839% world area, 1.52853150752433% land area)
09: Polar      = 714710 points (17.233555169753085% world area, 46.33962900287228% land area)
10: Forest     = 20530 points (0.49503279320987653% world area, 1.331102941653213% land area), Jungle = 18117 points (0.43684895833333337% world area, 1.331102941653213% land area)
11: Forest     = 0 points (0.0% world area, 0.0% land area), Jungle = 0 points (0.0% world area, 0.0% land area)
12: Polar Seas = 269183 points (6.490716628086419% world area, 17.453009407843975% land area)

Now assuming those figures check out with yours, Mike, then (with any luck) these should also be accurate for a 3D map (the sphere):

3D map is 2880x1440 (kinda) with 2659696 points total, with a land area of 783210 points (29.447350373877317%).
00: Forest     = 49970 points (1.8787861469882272% world area, 6.380153470972025% land area), Jungle = 189766 points (4.061178420390902% world area, 6.380153470972025% land area)
01: Farm       = 24014 points (0.9028851417605621% world area, 3.066099768899784% land area)
02: Farm       = 98378 points (3.6988437776347376% world area, 12.56087128611739% land area)
03: Farm       = 56052 points (2.1074588975582174% world area, 7.156701267859194% land area)
04: Farm       = 122488 points (4.605338354458555% world area, 15.639228304030848% land area)
05: Mountain   = 10971 points (0.4124907508226504% world area, 1.4007737388439883% land area)
06: Forest     = 324 points (0.012181843338486806% world area, 0.04136821542115142% land area), Jungle = 24708 points (0.41200197315783454% world area, 0.04136821542115142% land area)
07: Desert     = 92444 points (3.4757355727872663% world area, 11.803220081459633% land area)
08: Desert     = 19755 points (0.742754059110515% world area, 2.5223120235952043% land area)
09: Polar      = 152979 points (5.751747568143126% world area, 19.532309342321984% land area)
10: Forest     = 19957 points (0.7503489120561146% world area, 2.548103318394811% land area), Jungle = 18117 points (0.6355989556701217% world area, 2.548103318394811% land area)
11: Forest     = 0 points (0.0% world area, 0.0% land area), Jungle = 0 points (0.0% world area, 0.0% land area)
12: Polar Seas = 87871 points (3.3037986296178214% world area, 11.21934091750616% land area)

Zaimoni, I used this formula to add up how many points the 3D map would be (2659696), does it look right to you? If so, then the rest of my scaling is probably accurate enough as well.

for (int i=-720;i<721;i++) worldsize[1] += (int)(Math.cos(Math.toRadians(i/8))*2880);

- Bomb Bloke 07:12, 24 November 2009 (EST)

What's the target language? That controls whether you'll be nailed by integer division at i/8. (You want the highest-precision floating point available.) For Java, I would try something like

for (int i=-720;i<721;i++) worldsize[1] += (int)(Math.cos(Math.toRadians(i/8.0))*2880);

to try to get some automatic type conversions going without using an explicit cast on i. - Zaimoni 10:35, 24 November 2009 (CST)

Whoops, I've spent too long dealing with integers. Well caught. - Bomb Bloke 01:12, 25 November 2009 (EST)

Rats, my percentage of polar land mass on the 2D map comes out at about 64%. Still 46% if I disclude the polar seas. Back to the drawing board, then. Bomb Bloke 07:32, 24 November 2009 (EST)

Ok let me try it with Cosines used against the area of each record, based on the latitude of the centroid point for each area. One thing first, though - the WORLD.DAT page says "at the equator, each possible map location on the Geoscape occupies a square that is 111 kilometres on its side", but shouldn't it be an eighth of that? And for a WORLD.DAT record making a perfect square (0,0; 0,1; 1,1; 1,0), the area would be 193.6 km²? -MikeTheRed 23:06, 24 November 2009 (EST)

Indeed, should be an eighth, as the game map is in eighths of degrees (distance between real world degrees of latitude = ~111km, varying slightly as you move around the globe). A WORLD.DAT record can't really be a "perfect" square anywhere (because our lines can't bend to properly fit the 3D shape on which they're rendered). But say you made a polygon of one unit squared at the equator, it'd be a square eighth of a degree, and so should be pretty close 193.6 km² (192.5 km² to my count). This changes wildly as you move towards the poles, as the distance between points of longitude shrink down to 0 as you move from the equator (unlike latitude, where distances remains roughly the same). [1] - Bomb Bloke 01:12, 25 November 2009 (EST)

P.S. Can someone remind me - is Polar Sea With Icebergs considered land, in the game (can make bases or fight UFOs there)? -MikeTheRed 23:10, 24 November 2009 (EST)

Yup, you can build bases and visit UFO sites on the polar sea texture so it's considered land. Though, in some cases it's a little iffy (probably due to how the area is mapped out on the globe). --Zombie 23:15, 24 November 2009 (EST)

Just for comparison, I got a global land percentage of 31.224.. The way I did it however also suffers from some mapping distortions, although not so big.. So 29.44 is probably not to wrong.. Method I used: pixel/color scan of cube.map generated images, rendered using a 3D UFO.world.sphere.. Additional data: north pole: 55.300, south pole: 21.774. --Mvgulik 22:43, 25 November 2009 (EST)

After scraping out a heap of integer based calculations my figures vary a bit, but they're still fairly close to what they were. I think my main problem is correctly determining when polygons cross the prime meridion and loop around to the other side: Get that wrong, and certain polys will be way out in terms of accuracy.

Still, I figure a count of the mountain polys vs total world size should be a good benchmark. Don't think any of those loop. - Bomb Bloke 19:17, 26 November 2009 (EST)

Done them all for you. Marked the one's where your number is to high if I'm correct. Oddly mountain's is one of them. --Mvgulik 16:26, 27 November 2009 (EST)

00: 5.7033% *
01: 1.0427%
02: 4.2849%
03: 2.9602%
04: 5.2986%
05: 0.4005% *
06: 0.3188% *
07: 3.9370%
08: 0.9793%
09: 3.0936% *
10: 1.0211% *
11: 0.0%
12: 2.1456% *

Giving it a second thought after comparing the numbers. I initially figured the cubemap distortion only worked one way(Up). But it probably works in both ways. So these giving values that can be above and below the real value your after. That more or less leaves only the polar regions with having a somewhat suspicious large difference.

Flat Earth Projection

As noted under UFO Interception#Movement

Your ship autopilot prefers to move along lines of latitude (parallel to the equator) for long-range travel. This is especially noticeable when charting trans-polar routes: the ship will circle around the pole instead of flying straight across it. You can shorten the route taken by directing the ship to several intermediate way points along a straight line towards your destination.

A very clear example of this is if you take a craft at say 85 deg N, 0 deg E and set a waypoint to 85 deg N, 180 deg E (the opposite side of the pole). Instead of flying in a straight line over the surface of the earth, a great circle (in this case right over the pole), it travels along the 85th parallel.

I think the explanation for the waypointing behaviour is that the wayfinding uses what is known as the Flat Earth Approximation method of approximating a great circle. Basically it is taking polar coordinates of latitude and longitude on the surface of a sphere, and treating them as if they were x and y coordinates on a flat rectangle of 360 x +/- 90. The rectangle is 'wrapped' at 0 deg E = 360 deg E, but it does not wrap at the 'top', along the +90 deg N and -90 deg S lines.

If you imagine a craft on a flat rectangle of this type, at coordinates (0,85) heading to (180,85), it would travel along the y=85 line. On a flat plane, this is the shortest route, the Cartesian distance.

The Flat Earth method is a reasonable approximation for short distances nearer the equator. It is poor for long distances and near the poles. It's probably ok for interceptions, especially of slower craft by faster craft. The more exact methods of calculating a great circle course were possibly too expensive to be done continually during an intercept. However they could've been used for plotting paths to static waypoints, even on a 16 bit computer.

Note that the Geoscape movement engine itself is not Cartesian, it is fully aware of spherical geometry. The flat earth method is only a shortcut for the wayfinding, not a shortcut used for actual movement.

I think the behaviour at the pole cited in the example above is pretty much proof, but I guess a harder proof would be to find two cities at reasonably high latitude (away from the equator) that are on a roughly 45/135/225/315 degree bearing to each other, a reasonably long distance, then fly a Skyranger between those via waypointing. Check a gazeteer to find the actual distance and see how much the Skyranger distance (760nm per hour) differs. I'm not even sure if this is a valid test, I haven't thought it through enough. I have tested Skyrangers orbiting pole to pole and they give a very close figure for the correct radius of the Earth, that's why I believe that the actual movement model is accurate. Also, the waypointing model is accurate in the special case where you are travelling along a line of longitude (which is already a great circle). The equator is the only line of latitude that is also a great circle, so the waypointing is also valid when travelling along the equator.

Spike 20:06, 8 November 2010 (UTC)

Latitude or longitude?

FYI:

Latitude Latitude is used to express how far north or south you are, relative to the equator. If you are on the equator your latitude is zero. If you are near the north pole your latitude is nearly 90 degrees north. If you are near the south pole your latitude is almost 90 degrees south.

Longitude Longitude shows your location in an east-west direction, relative to the Greenwich meridian. Places to the east of Greenwich (such as Middle East, India and Japan) have longitude angles up to 180 degrees east. Places to the west of Greenwich (such as the Atlantic and North and South America) have angles up to 180 deg west. For inputting to the satellite dish pointing calculator, longitude west figures need to be input as negative numbers.

--Volutar 02:33, 23 August 2012 (EDT)

• The problem is that what is idiomatic English (latitude and longitude) does not describe the file contents (longitude and latitude). Until this edit war is thrashed out, I'd like the table to not be misleading should idiomatic English win out over factual accuracy. [Yes, earlier drafts had me lose my temper.] --Zaimoni 03:04, 23 August 2012 (CDT)