Saving all objs and turfs on a map?

Page: 1 2
Jun 20 2009, 9:55 am
In response to Kaioken
Ah right, forgot about the "move mobs to nowhere and back" method. I still don't like that.

My point generally boils down to the fact that, in every case, you're doing an extra lump of work in order to filter out mobs. However, you'll likely only have a handful of mobs on a map and many, many times as many turfs. If you're saving everything, then increasing the time to save a turf even slightly (like, say, looping through contents) in order to avoid having to save a mob is wasteful, when saving moba amounts to writing a rather trivial amount of data. Doubly so if you change mob/Read() to not do anything while you're saving turfs.

So, the question is again... why the hell do you have such an issue with saving the mobs? The increase in file size is completely trivial, and that's the only justification you've given.
Jun 21 2009, 5:30 am
In response to Garthor
if you're having a problem were you can't change turf's loc, try this:

        for(var/turf/T in SAVES)
            if(istype(T,/turf))
                var/turf/Turf = new(T.saveX,T.saveY,T.saveZ)
                Turf = T

That MIGHT work... never tried that though...
Jun 21 2009, 10:05 am
In response to KingCold999
Won't work, atoms' new() takes the location as an atom reference, not numbers/coordinates. You need to actually get the turf at those coordinates first, e.g. with locate().
Jun 21 2009, 10:25 am
In response to Kaioken
As I already pointed out, though, the default Read() and Write() for turfs saves and loads their x,y,z coordinates.
Jun 21 2009, 11:13 am
In response to Garthor
And how does that have to do with anything I've said? o_O Seriously, you need to read the post you're replying to, and consider its context before replying. Write() and Read() have nothing to do with the fact you can't use coordinates in new() when creating turfs...
Page: 1 2