So, I thought I’ll have another go and dive a bit deeper into this and write a little guide how everything relates to each other. And, oh boy, I think I might have dived a bit too deep… And detoured a lot.
Anyway, I’ve also added some screenshots as my “documentary” on its own is a bit dry.
All the files mentioned in this post are - regardless of their name - json files and can therefore be opened in any text editor.
I tried to use the terms defined here. However, for simplicity, I redefined two of them:
map square (ms) = tiles,
overmap terrain (omt) = overmap tiles.
Please keep in mind that, against my best effort, there might be some inaccuracies or misinterpretation on my part when I’ve analyzed and composed this explanation. If you notice/know a statement I’ve made is wrong, or if something isn’t explained clear enough, please let me know, so I can fix it.
It’s also possible that - at some point in the future - this system may changes and invalidates these information. This was written and tested in build 0.E-11094 (version 0.E-6779-gc3caa74).
Overmap Composition and Structure
First I’d like to write a bit about the overmap. As soon as you come close enough to the edge of the overmap you are on, it will generate the adjacent one. There are also other situations where it will generate a new one (looking at a (road) map, getting missions, …). It will generate the complete overmap, even if you can only see a single tile of it (or maybe not even that).
However, it does not “populate” (generate) the locations itself. That means, the game will know that there will be a house in the middle of the map and a secret lab in a forest near the south edge of the map, but it will not know which one or how they look like until you get there.
As soon as you save the game, it will write the structure of the complete overmap into a single file inside your world’s save folder.
The name of the file is o.[x].[y], where [x] and [y] represent the number of the overmap’s respective axis:
This file contains all z-levels of that one overmap.
The “layers” array contains all the overmap tiles with each z-level in its own array, starting with the lowest z-level (default -10) up to the surface (0) and up even more to the highest z-level (default 10):
It’s saved in a specific way; the id of the terrain tile and the count of the tiles in a continuous row. For a better understanding, let’s take a look at this snippet of the surface layer:
[ "forest_thick", 12 ],
[ "forest_water", 4 ],
[ "field", 3 ],
This defines - from left to right on the overmap - 12 forest tiles, followed by 4 swamp tiles and 3 field tiles. After 180 tiles it wraps around and starts the next row of tiles (one tile down on the y-axis):
This allows to search the file(s) for specific locations with the use of their id, if you want to (for example if an acid anthill, an airstrip or a refugee center is planned to spawn on this overmap).
It also allows designing and creating custom maps, either using tools or doing it all by hand.
Further, it contains the region type, monster groups and their submap coordinates, city names and positions (in overmap tile coordinates), roads for neighboring overmaps to connect to (in overmap tile coordinates), radio message broadcasts with their source coordinates and reach in overmap tile coordinates, monster & NPC & camp related stuff (including odor map) and specific points for locations to spawn in so that (for example) the doors and walls in labs line up.
If this file somehow gets deleted or corrupted, it will generate a new overmap the next time you visit its coordinates. The map might be substantially different from what you had; a city changes into a field, roads are where a river once was, … however, it will not actually replace already visited locations / overmap tiles. The location will just no longer match the map. Formerly unvisited tiles will correspond to the new overmap though, causing ugly seams in the world:
Overmap Tiles Seen
Next let’s have a look at another file in the world folder, the [gibberish].seen.[x].[y] files, where [gibberish] is the name of the character this files belongs to (encoded with base64) and [x] and [y] are the coordinates of the overmap which this file applies to. This file contains all z-levels of that one overmap.
This file contains a “visible” array which defines which tiles of that overmap were seen (but not necessary visited) with each z-level in its own array, starting with the lowest z-level up to the highest z-level.
The array consists of “false” (not seen) or “true” (seen) entries, as well as the count of overmap tiles this is covering, from left to right and top down.
The next array in this file, “explored”, is constructed in the same fashion. Its sole purpose seems to note if a tile was marked as Explored by the player by toggling it with ‘E’ in the game’s map.
It’s followed by another array, “notes”. Again, each z-level has its own array, starting with the lowest z-level up to the highest.
Each entry in any of these arrays represents an ingame note at a spot on the map. The entry consists of the x and y coordinates on that overmap (the z-level is given by the respective array used) counted in overmap tiles from the top right, the text of that note, a true/false switch that denotes if this note marks a dangerous tile and finally the radius in overmap tiles in which it will prevent auto-move (in case it is marked as dangerous).
The last array container “extras” concerns the “special” overmap tiles, like the “Corpses of Scientists”, “Burned Ground”, “Supply Drop”, “High Grass” and more…
As before, each z-level has its own array, from the lowest up to the highest z-level.
Whenever an extra is generated on an overmap tile in reach, it generates an entry. The entries have x and y coordinates (in overmap tiles) and the id of the map extra spawned at this location.
If you want to “share” map knowledge and/or notes between characters, you need to either transplant specific arrays from one file to the other or replace the file’s content completely - depending on what you want.
If this file gets corrupted or deleted… not much happens. You’ll lose the revealed map and your map notes, but otherwise you should be fine.
Map Locations, Terrain, Items
Finally we get to the content of the “maps” folder inside the world folder. Each time the game is saved, it writes all tiles, items and other stuff you have seen on your travels into files so that these things are still around like you left them (when you come back one day).
The files are split up into separate folders. The naming of the folders and files are different from the ones described before. Each folder represents a 32x32 area of a single z-level. Therefore, they are not bound to an overmap. The folders are named in the [x].[y].[z] format, where [x] is the number of overmap tiles on the x-axis away from the coordinates 0’0 divided by 32 (rounded down), [y] is the number of overmap tiles on the y-axis away from the coordinates 0’0 divided by 32 (rounded down), and [z] is the z-level.
So, the folder 0.0.0 contains the information of the overmap tiles from the coordinates 0’0, 0’0 to 0’31, 0’31 of the surface.
Here are two examples, the first centered around the 0’0, 0’0 coordinates and the other one around the 4’0, 6’0 coordinates. The red lines indicate the overmap borders while a beige border outlines the content of one folder:
Every file in the folders represent a single overmap tile. The naming of the files follows the [x].[y].[z].map pattern, where [x] is a representation of the absolute position of that overmap tile on the x-axis, [y] is the absolute position of that overmap tile in the y-axis and [z] is the z-level of that overmap tile.
The file contains a lot of variables; to prevent this guide from bloating up even more I’ll just concentrate on the ones remotely related to the topic… …Too little, too late… I’ll just add everything.
The file contains the 4 submaps located on that overmap tile. The “coordinates” is the position of the submap in absolute values (relative to the 0’0, 0’0 coordinates), in the x, y, z format (x-axis, y-axis, z-level).
We have the (internal) “version” used to generate that file/entry, the “turn_last_touched” which is basically the “last changed” of the entry, and the “temperature” of the submap.
In the “terrain” array all tiles of that submap are listed as they appear on that submap from left to right and top down. The entry in the array is the id of that tile. If the tile appears multiple times in succession, it contains the id of the tile and a number representing the number of repetitions of that tile.
The “radiation” variable contains a list of the level of radioactive contamination for all tiles of that submap, from left to right and top down. The first number notes the strength of the contamination, while the second number for how many tiles this number’s valid. If there are more than two numbers, the pattern repeats; the third number is the strength, the fourth is the number of tiles, …
Then there’s “furniture”, a list of all furnitures in that submap. Each entry starts with an x coordinate (valid for that submap), a y coordinate (for that submap) and the id of the furniture.
Similar to that, “items” contains all items of that submap. The first number is the x coordinate of that item in that submap, the second number is the y coordinate of it, followed by an array containing an entry with the information of the item for each item that exists at that position. The pattern repeats for other item locations.
Also, there’s “traps”, which follow exactly the same pattern as “furniture”. Each entry has the x and y coordinates in that submap, followed by the id.
On the other hand, “fields” are a bit special. They use a repeating pattern of x coordinate, y coordinate (both for that submap) and an array that contains the field id, the field strength and the number of turns that the field has existed, which also repeat if there is more than just one field on a tile.
Written text is represented by the “cosmetics” array. Anything written on the terrain gets an entry, in the format of x and y coordinate in that submap, the type, and the written text itself.
The array “spawns” offers all spawns planned for that submap, each entry contains the type, the number of spawns, the x and y positions, the faction, the assigned mission, a boolean if it is (or they are) friendly towards the player, and the name.
The “vehicles” entry contains the vehicles present at that submap, with (amongst other things) the x and y coordinates inside the submap, it’s name and a list of all parts of that vehicle.
Note: A vehicle counts towards a submap if its “origin point”, usually the driver seat or the first placed tile on custom vehicles, is inside it, even though a large portion might reach into an other submap.
Finally, we have “partial_constructions”, a list for all… well… partial constructions in the submap. An entry consists of an x coordinate, a y coordinate (both in that submap), the z-level, a number that represents the percentage of the build completed (10000000 = 100 %), the id of the construction and a list of all items used in the construction.
The pattern repeats for all entries if there is more than one unfinished construction in that submap.
If one of these file gets corrupted or deleted, it will generate it anew on your next visit - based on the tile defined by the overmap; you will lose all vehicles, changes made to terrain and furniture, written texts and items in that location.