SaveFile Size

Page: 1 2
Mar 4 2013, 9:59 am
I usually recommend deleting the file as well, just to be sure. But honestly, I prefer to save my file as "path/name.ext1", then once the save function is 100% done, to copy the file to "path/name.ext", then delete the ext1 file if the copy is successful.

But overall, yeah, I haven't had huge problems removing directories from file.dir, or setting a buffer's eof to -1 (which is a feature I learned from the reference.).
Mar 4 2013, 11:37 pm
Interesting system indeed.

Using this system i receive the exact same savefile size as i was previously obtaining by just doing but doing it this way may cause less problems later on i guess?

mob
    Write(var/savefile/F)
        src.overlays = null
        src.icon = null
        src.underlays = null
        ..()
        F.dir.Remove("icon","overlays","underlays","controls","watching","camera")


then simply just relaunching my builder procs (which i also still need to launch when i use your save system)

but was interesting all the same.
Mar 4 2013, 11:50 pm
You shouldn't need to launch any builder procs when you use mine.
Mar 5 2013, 12:05 am
Well i made a verb for it for the sake of testing it while still inside the game instead of just at Del() and it wiped the overlays. the "icon" itself which is the player base is fine that survives perfectly but any overlays i had are wiped.

And i commented out all my write/read in items/mob aswell so as to not conflict with me testing out your system
Mar 5 2013, 1:51 am (Edited on Mar 5 2013, 2:28 am)
Hmmm... I'll do some testing to see if I can duplicate this problem.

I have the feeling that it's because of the disconnect between developer-defined lists and internally backed lists. There are some odd behaviors when you start playing around with var lists, contents lists, overlay lists, the dir list for savefiles, in particular.

It should be an easy fix, but let me confirm what's going on before I fix it.


Alright, I confirmed what's going on. Basically, when you change the overlays of an object, there's internal behavior that causes the overlays list to update.

You can't really assign the overlays list to a placeholder, then expect it to come back easily. If you assign the overlays/underlays to a list(), it will completely wipe it.

So, I just modified my saving function a little bit for atoms:

atom
    NeverSave(var/list/L)
        //add what we don't want to save
        L.Add("icon","icon_state","overlays","underlays")
        return ..(L) //return whatever the parent type does.
    Write(var/savefile/F,var/list/neversave=null)
        //if we don't have any defined nonsavables yet.
        if(neversave==null)
            neversave = src.NeverSave(list())

        //we want to get a local copy of the overlays and underlays
        //because you can't just assign a list to overlays or underlays
        //at runtime. Things get messy.
        var/list/ol
        var/list/ul

        if(src.overlays!=initial(src.overlays)&&neversave.Find("overlays"))
            ol = src.overlays.Copy(1,0)
            src.overlays = initial(src.overlays)
            neversave.Remove("overlays")
        if(src.underlays!=initial(src.underlays)&&neversave.Find("underlays"))
            ul = src.underlays.Copy(1,0)
            src.underlays = initial(src.underlays)
            neversave.Remove("underlays")

        . = ..(F,neversave)

        if(ol!=null&&ol.len)
            src.overlays.Add(ol)
        if(ul!=null&&ul.len)
            src.underlays.Add(ul)


It might be faster to remove the directory of the savefile instead of copying the overlays list and adding it back, but given that several people have mentioned that there are corruption concerns with removing things from savefiles, it might be best to play it safe.

EDIT: Sorry, I borked some things. Didn't stop and think about not making copies for overlays/underlays equal to their initial value.
Page: 1 2