Anno 2070 Wiki

Dev Page | < Development Pages


see source code:

island map (from .dds file, 2nd mipmap) result of v0.5

v0.4 zoomed in where tiles are correct

in-game printscreen
Island map orig Island map transformed Island map transformed crop Island map ingame test

Jan 01 - 03[]

Hi, i just created v0.1 as a prove of concept if it is possible to use the game data files to create import files for anno-designer and other External tools.

Reading .png: First i / we need to understand the meaning of colors in original .png files, and how these can be mapped to the categories important for building - buildable tiles (+ underwater buildable tiles) and blocked tiles (rocks + water). I don't have an insight how to read the files correctly yet + in-game testing is required, so i invite any help or even speculations :))

Output formats: What this should be? An actual .png image like above (cropped) example or actual import format of anno-designer or something like






--deathApril (talk) 20:24, January 1, 2012 (UTC)

&%^#%^$@*: i've just found out that these .png are oriented orthogonally like minimap, not diagonally like tiles, so this is a dead end ;((( --deathApril (talk) 21:33, January 1, 2012 (UTC)

I like the idea of an island map converter, but I don't quite understand what you mean by "oriented orthogonally" and why this should be a dead end..? ZackSchneider (talk) 21:56, January 1, 2012 (UTC)

.png: tiles and .png are rotated by 45° from each other, it would probably be impossible to do a correct transformation (top of tiles = norht-east corner of the .png)

.dds: i found bitmaps that are the same rotation as tiles = .dds files (read by GIMP) from data3.rda data\levels (e.g. \islands\normal\ and n_l22.isd found in \scenarios\multiplayer\01.www as the first [bottom left] island of The Jorgensen Plateau scenario) => these serve as a background for polygons i want to read from .isd files

.isd: these are xml files that contain binary data inside BuildBlockerShapes/i/Polygon/i elements - each CDATA[] contains 20 bytes of data that can be unpacked to 5 32-bit integers (16, x, 0, y, 0). I was able to transform the x and y values to polygon coordinates that more or less match one hill from the .dds file.

v0.2: currently on GitHub - a test of reading polygons from .isd files, in-game testing needed

v0.3: with a lot of tweaking, i guess i got the algorithm right to match polygons to in-game blocked tiles (see top of this page for image comparisons)

--deathApril (talk) 15:46, January 3, 2012 (UTC)

Jan 05 - xx[]

.isd: how is possible that BuildBlockerShapes appear to be stored as integers (in subtiles = 2**12 tiles) and SurfLines as floats (in tiles with decimal places) ???

--deathApril (talk) 22:13, January 5, 2012 (UTC)

another dead end: BuildBlockerShapes look more or less ok, but SurfLines look like a very very bad way to get island boundaries - see converted_isd files from v0.5

Terrain: since Terrain in .isd files contains TileCountX and Z, i hope to reverse engineer the Element quasi-xml elements, since number of these elements is exactly ChunkMap.Width * ChunkMap.Height (e.g. 13*13 = 169 elements for 208x208 tiles => each non-empty element should contain a box of 16x16 tiles-related numbers in the CDATAs)

TextureIndex: anyone with any idea how to find textures by TextureIndex values [0, 18, 29, 52, 71, 72, 74, 75, 76, 78, 79, 80, 82, 83, 84, 85, 86, 87, 94, 95, 96, 98, 99, 104, ...] - these should somehow apply to the island tiles and hopefully one might be green/red texture overlay for available/blocked tiles ;))

--deathApril (talk) 18:54, January 7, 2012 (UTC)

TextureIndex: the Element chunks look ok, to explore what textures are present in what chunks see result.txt with result.png ... textureindex 52 might be something usable, but i'm not that happy with it ..

byte data: how do you store 16*16 = 256 pieces of information into 293 bytes? (actually 289 bytes, since first 4 are always '!\x01\x00\x00', but all other bytes have different values in different TexIndexData) e.g.:

!\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x08\r\x12\x12\x16\x14\r\x04\x00\x00\x00\x00\x00\x00\x00\x01\x0c"2?DCA.\x1a\x04\x00\x00\x00\x00\x00\x01\r\'Gc~\x81\x80qW7\x19\x04\x00\x00\x00\x00\x03\x188_\x85\x9d\xa9\xa3\x91sM$\t\x00\x00\x00\x00\x05\x1a9^\x88\x98\xa6\xa2\x9a\x8ag7\x15\x00\x00\x00\x00\x02\x0f*Jeju\x84\x95\x92\x85X3\x03\x00\x00\x00\x00\x04\x11\'515Sv\x90\x8emM\x18\x00\x00\x00\x00\x00\x02\x0c\x10\x04\t)`\x80\x90w[)\x08\x00\x00\x00\x00\x00\x00\x00\x01\x07\x19@gxwN \n\x00\x00\x00\x00\x00\x00\x00\x00\x03\r/N_R7\x17\x07\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x0f"2$\x1a\x07\x00\x00 

--deathApril (talk) 00:28, January 8, 2012 (UTC)

bit data: i have a feeling that 256*9 bits (or 3*3 RGB colors) = 288 bytes + 4 bytes at the beginning + 1 lost byte .. might have something to do with the data format .. i need to do some experimentation with bitstring module - tomorow .. --deathApril (talk) 01:27, January 8, 2012 (UTC)

Texture data: yeeah,, i cracked the texture data - however, i can see no practical use, except maybe TextureIndex 52 for island boundaries ... each chunk/element contain 17x17 pixels (=289 bytes), but chunks overlay by 1px, so every 17th byte + last 17 bytes can be ignored --deathApril (talk) 23:08, January 9, 2012 (UTC)

HeightMap: not that good data as i hoped for :(( see test result --deathApril (talk) 14:56, January 10, 2012 (UTC)