code/modules/mapping/reader.dm

Define Details

MAP_DMM

DMM SPEC: DMM is split into two parts. First we have strings of text linked to lists of paths and their modifications (I will call this the cache) We call these strings "keys" and the things they point to members. Keys have a static length

The second part is a list of locations matched to a string of keys. (I'll be calling this the grid) These are used to lookup the cache we built earlier. We store location lists as grid_sets. the lines represent different things depending on the spec

In standard DMM (which you can treat as the base case, since it also covers weird modifications) each line represents an x file, and there's typically only one grid set per z level. The meme is you can look at a DMM formatted map and literally see what it should roughly look like This differs in TGM, and we can pull some performance from this

Any restrictions here also apply to TGM

/tg/ Restrictions: Paths have a specified order. First atoms in the order in which they should be loaded, then a single turf, then the area of the cell DMM technically supports turf stacking, but this is deprecated for all formats

MAP_TGM

TGM SPEC: TGM is a derevation of DMM, with restrictions placed on it to make it easier to parse and to reduce merge conflicts/ease their resolution

Requirements: Each "statement" in a key's details ends with a new line, and wrapped in (...) All paths end with either a comma or occasionally a {, then a new line Excepting the area, who is listed last and ends with a ) to mark the end of the key

{} denotes a list of variable edits applied to the path that came before the first { the final } is followed by a comma, and then a new line Variable edits have the form \tname = value;\n Except the last edit, which has no final ;, and just ends in a newline No extra padding is permitted Many values are supported. See parse_constant() Strings must be wrapped in "...", files in '...', and lists in list(...) Files are kinda susy, and may not actually work. buyer beware Lists support assoc values as expected These constants can be further embedded into lists One var edited list will be shared among all the things it is applied to

There can be no padding in front of, or behind a path

Therefore: "key" = ( /path, /other/path{ var = list("name" = 'filepath'); other_var = /path }, /turf, /area)