ID:2094900
 
Code:
/client/proc/saveMap(var/zLevel as num)
//Do normal stuff for verbs

var/savefile/mapsave = new("Z_Level_[zLevel]")

for(var/x = 1, x < world.maxx+1, x++)
for(var/y = 1, y < world.maxy+1, y++)
mapsave["[x]_[y]"] << locate(x, y, zLevel)

/client/proc/loadMap(var/zLevel as num)
//Do normal stuff for verbs

var/savefile/mapsave = new("Z_Level_[zLevel]")

for(var/x = 1, x < world.maxx+1, x++)
for(var/y = 1, y < world.maxy+1, y++)
var/turf/T = locate(x, y, zLevel)
mapsave["[x]_[y]"] >> T //Does this line even do anything?


Question description:
So I have been playing around with dmm suites recently, and I had an idea. What if I were to save and load maps from a savefile instead of processing the 2.5k lines of text that come with a 255x255 map? The pseudocode above shows what I'm trying to do.

I have three main questions:
1. Is this worth it? Will the text processing of 2.5k lines of code for 65025 tiles be slower than loading the objects from a save file?
2. Will that line I commented in loadMap() work for loading the tile? I know the savefile doesn't save locs, so it wouldn't try to overwrite T.loc and maybe it would carry over all of the contents etc?
3. As I am writing this, I realized this won't do anything for areas will it? How could I store that information in the savefile?

Sorry if the code looks a little off, I'm a SS13 coder so admin verbs are a little different.
There was actually a recent thread on this, regarding best practices for loading and saving turfs.

The save loop you have is very inefficient; you'd be better off using block() and either saving the list directly or traversing that list alone, rather than calling locate() each time through.

Turfs don't really behave very nicely on direct saves and loads, though. For one thing they don't preserve the area properly, which is kind of a big deal for some games. I would simply recommend going with one of the established libraries for this sort of thing.
Thanks for the advice. I went ahead and tried this, but it definitely did not work out well. The best I can figure, when saving the overlay information, it actually ends up putting the entire binary file as text into the save file. This caused the file to inflate to 200MB, fail, and result in a 4.5M line text document labeled _bad_000.

I think I will stick to NullQuery's dmm suit.