you totally builded your own net dream

That depends upon how you want to save the maps, whether you want it to be lag free, and whether or not you want to use SQL vs Write().

If you don't mind massive lag and possible crashes, just add every turf to a list and save the list, along with a hash, then rehash and compare the 2 at load to make sure it's the same map.

If you want to go with Write(), but don't want the massive lag of writing a giant list to a file, you can use a for loop on the turfs that defines a variable/I, writes the turf to savefile/F["[I]"], then increases I for the next one, then does the same with loading, with a for loop on the file with the same increment setup.

Either way be sure you turn off recursion checking or it will crash if you have a big map.

As for SQL, there are libs out there for it, and I really don't know much about it myself.

I don't see why you would need to save the actual maps themselves, though. Couldn't you just save the variables entered to create them and regenerate the same map when it's loaded, and only save the objects in the world? If all you need is object saving I have a working example of the second option(the one with tons of save buffers) from my work on Archipelago Remastered. Saves 3MB worth of objects in a matter of seconds with no lag/crashing.

proc

TestSave()

world<<"Saving objects!"
var/I = 1
var/savefile/F = new ("world.sav")

for(var/turf/T in world)

if(T.x)

T.saved_x = T.x
T.saved_y = T.y //location.
T.saved_z = T.z
F["[I]"] << T
I++
sleep(0)

That's a general example of what it should look like.

I didn't get much from Robertbanks2's jumble about SQL, but his advice about saving parameters rather than maps is sound.

Your map generation is not truly random, but psuedorandom. Accordingly, you could save a seed of a psuedorandom generator (simply a number) to represent a randomly generated map. Look it up, we even have an article about this somewhere in DreamMakers.

Toadfish wrote:

I didn't get much from Robertbanks2's jumble about SQL, but his advice about saving parameters rather than maps is sound.

I didn't actually try to explain much of anything about SQL, as I personally don't know much of anything about it in the first place. Though I will admit to rambling a bit. I posted an example of what I WAS rambling about just a moment ago if you're interested in seeing what I meant.

That code wasn't actually used on turfs when I made it, it was used to save the massive amounts of objects produced in a similar game, and yes, actually, it is tons more efficient than adding them all to a list and saving them. Saving to a giant list then writing it is 2 huge operations, while this is a bunch of tiny, individually unnoticeable operations that are performed with small breaks allowing the game to continue processing other things while it's going on. My own testing and experience shows that it functions in roughly 1/4 the time, with quite a lot more stability, and next to no noticeable effect on the players/server.

With that out of the way, no, he shouldn't be using it with turfs, saving his seeds is a much better way of handling it, and there are always ways to avoid changing turfs that are much better than allowing them to be altered at runtime and then saving them later. That said, if he's going to do something like this anyway, I may as well provide him with the best way I know how to do it, and advise against it, rather than allowing him to use an even WORSE method of dealing with his turfs.

But really Jittai, just use a seed for turfs and ignore changing the turfs themselves, in favor of using objects placed on top of them to do what you need to.

This looks almost like a cellular automaton.

It is important that you realize the only thing random about most computer applications is the time you start them up. Computers can't generate truly random sequences of numbers. Rather, a formula is used to pick a psuedorandom number whenever you call rand(). For this reason, sequences of "random numbers" can be repeated given one knows the seed. Now think about how this relates to random map generation.

Currently the buildings only save at maximum four variables and only save when those particular variables are changed.

This is irrelevant, what's relevant is what those variables contained. If they contained a file (such as an icon), for example, things would quickly become very bad.

I don't know why you think your map generation is "truly random" and nonrepeatable if you don't even use random numbers. "Locations randomly chosen in a range?" So you use pick()? Pick() obviously uses rand(), or some variant of it.

Then think of what parameters are involved.