3D mapgen

[PatrikLundell]

Summary

None

Purpose of change

Allow mapgen to make use of 3D functionality.
Fix #74044, i.e. dermatik roof matching level below.

Describe the solution

• Change the mapgen to use smallmap for 3D access.
• Save partial submaps resulting from writing to other Z levels for the current level just before the current level is generated.
• Merge of partial current level submap with "real" submap.
• Moved generation of uniform maps into the "generate" operation to allow these sections to be used for mapgen overlays even if on a lower Z level by generating these in a first pass.
• Merged the two map::loadn operations into one to cut down on repetition.
• Factored out the logic determining if overmaps are uniform to allow it to be used by mapgen as well.
• Changed editmap's overmap editing to be 3D aware.
• Changed the dermatik nest taking care of Is the dermatik nest roof intended not to cover all walls? #74044 as a demonstration of the new functionality.
• Updated MAPGEN.md to cover the changed functionality.
• Fixes to a number of "apply" operations where the Z coordinate was treated as absolute rather than relative (Testing was poor, as the reference used was 0, so relative and absolute ended up the same...).

Describe alternatives you've considered

• Tinymap will probably have to be removed completely. It's safe to use when no 3D is involved, but using it is risky; should 3D ever happen to be introduced where it's used you'll get weird behavior, but no error reports. That's probably better left for a separate PR, though.
• The implementation causes map directives to be lost (wipe items, keep items, etc.) when making changes to a lower Z level that isn't uniform (all tiles the same, such as air or soil), but are applied when writing to a higher one. This is due to the order in which data is generated (I've set it to be from the top down, since I think it's more likely to want to generate additional data on a higher level than a lower one), and there is no easy solution to that (at least I haven't found one). Technically adding things to a higher level when generating from the top down means the higher level already exists when generating the overlaying data, but for lower levels the overlay is generated before the base map, and so has to be saved and merged.
  It WOULD be possible to generate each Z level, record which other Z levels are affected, wipe the results between each level, and then determine a level generation order (or that there is a circular dependency). However, that would be rather expensive. The approach to generate everything with a default generation order (top-down) and then work out a load order when an out-of-order case was detected falls on the generation potentially writing to preexisting maps, and you can't undo that. You could potentially get away with that if you copied all preexisting submaps and then replaced the originals with the (potentially) updated copies when done (making new copies once a suitable generation order has been determined). I think that's too much code mess for a rather niche case, though.
  All the use cases I know of where you'd want to tie things on multiple Z levels together go upwards (match roof to building for Aftershock ruins, match roof to wall for dermatik mound, match tree top to tree for all trees). I wouldn't mind to receive suggestions for cases where you'd want to tie lower levels to higher one and don't want to switch the level dependency if someone can think of them.
• The submap merging code has some fields that aren't merged due to a lack of knowledge on how to to it. I currently think they're not important as that info shouldn't be generated by mapgen.

Testing

• Generating the campus and teleport to it a bazillion times to check whether the shacks look OK.
• Checked that the staircase and chair hacked into the campus looks OK.
• Used editmap to generate a garage, which seems to work. It doesn't have a roof, but I would expect it not to have one prior to this PR either, since the roof adding magic isn't applied.
• Used editmap to generate the campus pedestrian area with a shack hacked into it, and the shack was generated, complete with the roof.
• Issued a camp order to log a world tile and verified that it indeed looks logged afterwards. The code uses a map, which would benefit from a change to a smallmap (which didn't exist when this was made 3D aware).
• Issued a camp order to set up a hide site and verified the stuff sent appeared in a leanto (this code uses a tinymap).
• Debug spawned a dermatik hive and verified walls that may be either paper or dirt are covered with the corresponding material roof (the PC is standing on one such dirt tile, while the tile beside him is a paper tile from the same base definition).
  
  

Additional context

You may have seen this PR before. I switched "back" to 3D_mapgen after some other work and continued without incident. Then uploaded it to 3D_mapgen, and now I can't upload to 3d_mapgen after switching back to the "real" branch, so I'll try to continue here instead (if it works).

A weird thing is that the code talks about not bothering to save uniform submaps because it's cheaper to recreate them, but then it proceeds to save every submap on every Z level without sorting out uniform ones.
I would assume that if you actually wanted to be able to selectively skip uniform levels you'd also need something lightweight to recreate them, rather than the current only option of recreating the whole OMT on all Z levels (although that logic doesn't actually regenerate things that already exists).