Ramps don't update when new tile data is added.

[RosaryMala]

If a ramp is generated on the edge of a map block, it won't respect the wall on the side that is loaded after it. The solution would be to regen the surrounding geometry once a block is pulled from DF.

[kazimuth]

We could also try prioritizing blocks whose surroundings are fully loaded, but that's more of an optimization than a solution, since map updates can cause this problem too.

[RosaryMala]

Okay, the problem with this right now is that map blocks that are sent to the mesher have no knowledge of their surrounding tiles, so even if they get regenerated, they still have broken ramps, even if the data is there. Not sure what the solution for this is, besides keeping two entire copies of the map.

[kazimuth]

Oh, that makes sense.

I actually have a solution for this - map data is passed to meshing in small slices of the map stored in MapDataStores, which can transparently hold map slices of any size. We can modify the MapDataStore.CopySlice(BlockCoord) method to return not only the tiles in the block but also the tiles around it; that way the mesher should get all the tiles it needs. We'll need to be careful about meshing operations that require more than the immediately adjacent tiles, though.

[kazimuth]

I'm not in a place to test this right now, but the new code for CopySlice and CopySliceTo would be along the lines of:

public void CopySliceTo(BlockCoord block, MapDataStore target) {
   CopySliceTo(block.ToDFCoord() + new DFCoord(-1,-1,0), BLOCK_SIZE+new DFCoord(2,2,0), target);
}

[RosaryMala]

I did a partial fix of this by pre-calculating the ramps before sending over the block update request, in the main thread. This partially solved it, but sometimes the ramps still end up funny.

[RosaryMala]

Fixed properly by making block chunks include the surrounding tiles.