That changes the memory from one contiguous section into multiple fragmented heap-allocated blocks. It also removes the ability to have O(1) index time.

Any change can't negatively impact the base game where it would never use that feature.

Yes I probably would fragment the shit out of it ...

It would be 1 extra byte for each tile on map ... one chunk is 32x32 tiles, medium sized map has ~25000 chunks (about 5000x5000 uncovered tiles)
So, extra 24Mb? It does not look too big compared with current usage.

Update to 0.16, load a "few" mods, start a new game, plop a radar, memory ...

"You can't do that..."

Sir you can do anything! :P pseudo slow buggy code...

data std::array<32, std::vector<byte>>

operator[](int x)
{
target = x % 32
index= 0
id = 0

for (std::vector<byte>::iterator it = data[int(x/32)].begin() ; it != data[int(x/32)].end(); ++it)
{
if index != target ...

err... dotnet number optimizations anyone? I assume the lowest random access level is by chunk? Use a value of 255 to mean there is another byte following for a tile using an extended id. infinite ids case solved...