Sorry for the noise, finally had a chance to dig into your PR and I see what you mean, everything looks great so far. I thought you meant replacing mapbuffer, but looks like you didn’t change it other than implementing the uniform submap feature.
BTW, if load times for all those submaps become a problem, what I was planning on doing was making the number of submaps loaded (not the reality bubble, just the submaps cached in mapbuffer) larger, but making the actual load operation asynchronous by pushing load/save operations onto a workqueue and processing quads one at a time while waiting for player input. That way you’d have at least 12 turns of player input to catch up after a shift (or more if you put two “rings” of quads onto your preload queue instead of one, but at some point you’re just loading/saving constantly and hardly using any of the loaded data). Additionally you could prioritize loads over saves, and just develop a “tail” of still-loaded submaps that only get written out if the player stops hitting keys for a bit. Plus if the player is moving back and forth quickly you’d still have them loaded.
I didn’t implement this when I moved to loading/saving submaps in quads instead of all at once back in 0.B because it would have been premature optimization. It’s certainly more complicated, and I couldn’t see any load/save pauses after making load/save incremental. I had the same approach in mind in case submap loading ever became super expensive due to running catchup operations on them when they come in range. (field dispersion, rot, monster evolution, etc)
