Save/Load issue

Page: 1 2
Jul 23 2015, 2:08 pm
True but I did need help. @Ter13, tarunofman helped me but now I realize that the method of save he's using isn't going to work for me. I have too many vars

        signs=0      //max=1
        birdhs=0 //max=1
        birdhsm=0    //max=25
        boarhs=0 //max=1
        boarhsm=0    //max=25
        doghs=0      //max=1
        doghsm=0 //max=25
        dragonhs=0   //max=1
        dragonhsm=0  //max=25
        oxhs=0       //max=1
        oxhsm=0      //max=25
        tigerhs=0    //max=1
        tigerhsm=0   //max=25
        snakehs=0    //max=1
        snakehsm=0   //max=25
        raths=0      //max=1
        rathsm=0 //max=25
        horsehs=0    //max=1
        horsehsm=0   //max=25
        monkeyhs=0   //max=1
        monkeyhsm=0  //max=25
        harehs=0 //max=1
        harehsm=0    //max=25


And this is just a little 1 out 26 of them.
Jul 23 2015, 2:18 pm
Description: So this method works but once I remove the "//" by 
s["mob/player"] << src
players can't load their files.

Ter13 would you like to take a look?

Also, Tarun helped me with it and gave me this format. The only issue now is that I have to manual define and save every var.


mob/proc
    SAVEcharacter()
        if(fexists("Players/[ckey].sav"))   fdel("Players/[ckey].sav")
        var/savefile/s = new("Players/[ckey].sav")
        s["icname"] << src.icname
        /*s["x"] << src.x
        s["y"] << src.y
        s["z"] << src.z*/
        s["LX"] << src.x
        s["LY"] << src.y
        s["LZ"] << src.z
//      s["mob/player"] << src
        src<<"Game Saved"
    LOADcharacter()
        if(fexists("Players/[ckey].sav"))
            var/savefile/s = new("Players/[ckey].sav")
            //s = new ("[src.ckey].sav")
            s["icname"] >> src.icname
            s["LX"] >> src.LX
            s["LY"] >> src.LY
            s["LZ"] >> src.LZ
//          s["mob/player"] >> src
            src.loc=locate(LX,LY,LZ)
            src<<"Success Loading"
            winshow(src,"mainwindow",0)
            stage4()
atom/var
    LX
    LY
    LZ
mob/verb/SAVE()
    alert("SAVE VERB")
    usr.SAVEcharacter()
mob/verb/LOAD()
    alert("LOAD VERB")
    usr.LOADcharacter()
Jul 23 2015, 2:43 pm
@Alex: Tarun is leading you in the wrong direction. His method is absolutely irrevocably wrong. If you had trouble with my approach, you've gone wrong with something. Show me what you did with my approach and I'd be happy to fix it. I can assure you that Tarun does NOT know what he's talking about and he's not interested in understanding where he's gone wrong. His approach may work, but it's completely terrible.

@Jin: Write() is called automatically when you try to put a datum into a savefile. Read() is called automatically when you try to read a datum from a savefile.
Jul 23 2015, 3:18 pm
Ahh I see so I could do

F << src to save

and

F >> src to load?

Do I have the basic concept right there?
Jul 23 2015, 3:23 pm
Confirmed, removing the manual call of Read and Write fixed the issue completely. Thank you for helping me with the problem and explaining why it was wrong Ter13, I appreciate it.
Jul 23 2015, 6:20 pm
Nobody really addresses this very often. I'm glad you solved your problem, but nobody really pointed out the issue I'm seeing.

When writing/saving an object, or mob to a file, you're also saving the contents as well as non-temp variables.

So from my understanding, you're putting the "Captain" object inside usr.contents. This isn't a problem, but the "Captain" object also has a non-temp variable that contains the "usr" as well. So you're saving yourself, inside the object, which is then inside yourself. Basically you're cloning yourself.

If this is the case, then you'll want to work around this. You can do this by first chaing the "user" variable to be a temp variable. (IE: var/tmp/mob/user) and then override the Object's "New()" protocol and do a check like this:
for(var/mob/M in world) if(src in M.contents) user=M

Although it's working without errors for you now. After continuous saving/loading you'll notice the savefile getting bigger... and bigger... and bigger. Till it can no-longer be loaded due to BYOND limits.

I hope this helps, or at the very least is informative for you to avoid clone-saving in the future. :)
Jul 23 2015, 6:32 pm (Edited on Jul 23 2015, 6:40 pm)
So you're saving yourself, inside the object, which is then inside yourself. Basically you're cloning yourself.

This is not true. Let me link you to some information on the subject. Object duplication is only possible if you save reference to the same object in multiple savefiles. Thus, any variable that contains anything that shouldn't log off with the player should be marked tmp. This is especially true for variables that can contain references to other players and stuff that's generated on log-in like shadows, screen objects, etc.

http://www.byond.com/docs/notes/235.html

V 235 was released in early 2000 or late 1999. The dates for these releases don't exist anymore. So this is nothing new. This predates even MY participation in this community, and I'm one of the three oldest active community members (I joined before Lummox.).

Dan wrote:
Added default behavior to the object Read()/Write() procs. All variables that are not marked tmp, global, or const (ie those for which issaved() is true) and which are not equal to their initial value will be written to a data directory with the same name as the variable.

Savefiles now automatically attempt to avoid duplicate objects or, even worse, recursive references which could cause an infinite loop. For example, suppose players have both an inventory list (mob.contents) and an equipment list (mob.equipment) and the items in the equipment are also in the inventory (ie it is a list of items being carried that are also in use). A bonehead save routine would simply write each value in each list, generating two copies of equipped objects in the savefile. When reading these back in, two different objects would be created, rather than two references to the same object.

Now, however, the savefile enters deduplication mode when writing an object (like say the player) to the file. Multiple references will automatically be detected and handled internally. You just have to make sure you read things back in the same order you wrote them for this to work correctly.

Also note that duplicates between two independent savefile operations will not be detected. For example, if you write player A and then later write player B, any references from the two players to the same object will not be detected. The two savefile entries are completely independent. (So you don't have to worry about the order you read them or the possibility of mangling one when you delete the other.)

However, suppose a player has two objects in hand when being saved. Even though the two objects are written in separate statements, these both take place inside the ongoing savefile operation that is writing the player. That means references to the same thing inside object 1 and object 2 _will_ be detected.

You are right though that not marking variables temporary is a big problem with savefiles, but any references to the player that is being saved are safe to store without tmp status.
Jul 24 2015, 7:28 am
@Ter13: Ah I see. I always just assumed this would happen, and if you're not careful it does.

So then the case is only possible if var/mob/user = Mob1 and the object is saved inside Mob2.

Still usually a good idea to make any reference variables tmp to avoid any issues. If you need an identifier use a player's key instead.
Page: 1 2