Saving issue

Page: 1 2
ID:1895140
 
Jul 13 2015, 2:09 am
(See the best response by Nadrew.)
Code:
client
    proc
        LoadChar(S)
            screen=null
            if(S==1)
                var/savefile/F=new("Player Saves/[ckey]/Slot 1.sav")
                F["name"]>>mob.name
                F["mob"]>>mob
                F["x"]>>mob.x
                F["y"]>>mob.y
                F["z"]>>mob.z
            if(S==2)
                var/savefile/F=new("Player Saves/[ckey]/Slot 2.sav")
                F["name"]>>mob.name
                F["mob"]>>mob
                F["x"]>>mob.x
                F["y"]>>mob.y
                F["z"]>>mob.z
            if(S==3)
                var/savefile/F=new("Player Saves/[ckey]/Slot 3.sav")
                F["name"]>>mob.name
                F["mob"]>>mob
                F["x"]>>mob.x
                F["y"]>>mob.y
                F["z"]>>mob.z

        SaveChar()
            if(!src||!mob||!mob.loggedin||cantsaveatall)return
            if(mob.save_file_1)
                var/savefile/F=new("Player Saves/[ckey]/Slot 1.sav")
                F["name"]<<mob.name
                F["mob"]<<mob
                F["x"]<<mob.x
                F["y"]<<mob.y
                F["z"]<<mob.z
            if(mob.save_file_2)
                var/savefile/F=new("Player Saves/[ckey]/Slot 2.sav")
                F["name"]<<mob.name
                F["mob"]<<mob
                F["x"]<<mob.x
                F["y"]<<mob.y
                F["z"]<<mob.z
            if(mob.save_file_3)
                var/savefile/F=new("Player Saves/[ckey]/Slot 3.sav")
                F["name"]<<mob.name
                F["mob"]<<mob
                F["x"]<<mob.x
                F["y"]<<mob.y
                F["z"]<<mob.z

mob
    Logout()
        ..()
        del(src)

mob
    PC
        Logout()
            del(src)

client
    proc
        AutoSave()
            set background=1
            spawn while(1)
                if(cantsaveatall||!src)break
                src<<"<u>[servername]:</u></font> Character <font color=green>saved</font>!"
                SaveChar()
                sleep(6000)

client
    Del()
        if(istype(mob,/mob/Guest))return ..()
        if(istype(mob,/mob/PC))
            SaveChar()
        for(var/mob/P in world)if(P.name=="PC-[src.key]-PC")del(P)
        ..()


Problem description:

Sometimes people report weird rollbacks from a few hours to a few days, they get randomly teleported in locations with stats rollbacked, even though saving happens every few min and on client del. Also from what I can tell the way it happends is when they get a random disconnect and then log back in play for few days and then the rollback happends they get to that moment of past disconnect.

Current Player Save's: 6 710 If it matters.
Jul 13 2015, 2:14 am
When a person has disconnected, are you sure that they are attached to a mob? Perhaps you should use mob.Del() instead of client.Del().
Jul 13 2015, 2:18 am
The if statement makes sure its the player mob that's getting saved. But I'm going to try mob.Del()
Jul 13 2015, 2:24 am
In response to Zasif
Hmm. It makes sure that if the client has a mob and that mob is a /PC then save it.

But if the client doesn't have a mob then nothing is saved which could explain why people are losing data.
Jul 13 2015, 2:28 am
They are not losing data whne they get the disconnect, they just log back in and play the rollback happends days aftar.

In that time, auto saving happends even that should be stopping the days rollback.
Jul 13 2015, 2:30 am
In response to Zasif
Days after? Well now that's strange. I would hesitate to say that if it's days after a disconnection then the disconnection probably isn't the issue.
Jul 13 2015, 2:32 am
Yeah, trying to find out what's causing this and if the issue is in the saving, would like more inputs on this.
Jul 13 2015, 2:22 pm
Best response
If you have any variables that can be set to a reference to another player they should be made 'tmp' so they don't save, if they do save, when that player connects it will roll back the person to the state they were when they were saved as the original person's variable.

In other words, check your variables that can be set to a reference to another mob.
Jul 13 2015, 2:32 pm
If you have any variables that can be set to a reference to another player they should be made 'tmp' so they don't save, if they do save, when that player connects it will roll back the person to the state they were when they were saved as the original person's variable.

In other words, check your variables that can be set to a reference to another mob.

This is definitely the problem. Not setting mob references to tmp will cause pseudo-rollbacks in certain cases.
Jul 13 2015, 2:34 pm
That was my first thought. I remember when I started learning I had this issue all the time and could never figure out why.

Using tmp variables for mob references is generally a safe route to take if you don't know what you're doing.
Jul 13 2015, 2:36 pm
Using tmp variables for mob references is generally a safe route to take if you don't know what you're doing.

Setting everything tmp by default should be the route you want to take until you start tackling saving.

Unfortunately this is one of those housekeeping habits that never really caught on.
Jul 13 2015, 2:37 pm
Zasif sent me a couple of savefiles to look at. While those specific files were not part of the problem (the best way to find the problem files is to look for savefiles that are much bigger than the others), I was able to find at least one var that's problematic: an obj var called TargetList.
Jul 13 2015, 6:33 pm
Delete the old save before making the new, solved the issue for me when it came up in my zeta source. I, of course, removed mob references after the matter; so I suggest keeping to their suggestions first. Also, maybe try not using the horrible [anything] in zeta sources? Of course, that would require very basic understanding of programming and a saving library, to which I recommend Ter13's
Jul 14 2015, 3:41 am
From the experiments lumo made me do it seems some people's savefiles have another player's savefile in it now I just need to figure out whats causing this issue.
Jul 14 2015, 3:47 am
In response to Zasif
Woah that's weird. If you find out why please update this. I'd be interested.
Jul 14 2015, 4:44 am
yeah finding whats causing this issue, will be hard to find. X:
Jul 14 2015, 6:14 am
@Zasif: You can use Foomer's savefile editor to investigate savefiles. Once you find variables that are triggering the saving of other players, you can fix those one at a time and then write a program that will run through all of your savefiles and remove the offending entries.

Another thing you should pay attention to that Zeta games do wrong:

new/obj/screen_obj(owner)

^That is wrong. The first argument when creating an atom is always the location. Part of the reason that savefiles get so ridiculously huge in zeta/naruto games is because objects are initialized in the player's contents that shouldn't be every time they log in. This can result in potentially millions of objects hanging out in a regular player's contents before long.
Jul 14 2015, 6:56 am (Edited on Jul 14 2015, 7:14 am)
In response to Ter13
Ter13 wrote:
@Zasif: You can use Foomer's savefile editor to investigate savefiles. Once you find variables that are triggering the saving of other players, you can fix those one at a time and then write a program that will run through all of your savefiles and remove the offending entries.

Another thing you should pay attention to that Zeta games do wrong:

new/obj/screen_obj(owner)

^That is wrong. The first argument when creating an atom is always the location. Part of the reason that savefiles get so ridiculously huge in zeta/naruto games is because objects are initialized in the player's contents that shouldn't be every time they log in. This can result in potentially millions of objects hanging out in a regular player's contents before long.

Yeah, trying to find what triggered this issue, but its not as easy but I did find a player's savefile that has 2 players saves in it. I found out about it by the person who got teleported at the end of a map, right aftar the person with this savefile logged in, and it also showed as both logging in.
http://files.byondhome.com/Zasif/Slot%20111.txt

Edit@ This issue seems to only happend to few people, not everyone. Fixing those peoples savefiles might be harder said then done from looking at the savefile itself it looks very messy. :X
Jul 14 2015, 8:09 am
That's exactly why I wrote this two-part tutorial over two years ago: http://www.byond.com/forum/?post=1187245


An excerpt that's exceptionally relevant to you:

This next bit is important: You want to know a fast way to really mess some things up? Saving variables that reference objects that the player doesn't actually "own". Watch what happens when you save a player with a reference to another player in their variables. Not only do you wind up saving the player you meant to, but the player you didn't mean to. If you reference objects that shouldn't log off with the player, set them to temporary. Always.
Jul 14 2015, 8:21 am (Edited on Jul 14 2015, 8:29 am)
Yeah this seems to be the case here. The issue still remains on finding which var is causing this issue.
Page: 1 2