"Rollbacks"

ID:174979
 
Jun 25 2003, 8:04 pm
Ok, lately my game and its players have been experiencing "rollbacks" where they login into an older character with lesser stats and items. I can't really find the problem in my programming. I only have one client/Del() and it's been over ridden, but using ..() it should be fine. I even have del(mob) and it still isn't deleting the person, I also have it deleting the mob in mob/Logout()
Jun 25 2003, 8:11 pm
MLAAS had a problem like this a while back. Make sure you're not saving the loc var, because then it will save everything on the turf. If a player saves while there's another player on the same turf, then both mobs will get saved. When the player who saved loads again, the other player's mob will be recreated. If that player then logs in, they'll log into their old mob, thus creating a rollback situation.

Instead of saving the loc var, save the x, y, and z vars under different names, and then restore the mob's position when loading.
Jun 26 2003, 12:26 am
In response to Crispy
STRANGE, this is my read/write procs, but...it's not saving.loc it's saving their x,y,z coords.

    Write(savefile/F)
        ..()
        F["Saved_Verbs"]<<verbs
        F["last_x"]<<x
        F["last_y"]<<y
        F["last_z"]<<z
    Read(savefile/F)
        ..()
        var/Saved_Verbs
        var/last_x
        var/last_y
        var/last_z
        F["Saved_Verbs"]>>Saved_Verbs
        F["last_x"]>>last_x
        F["last_y"]>>last_y
        F["last_z"]>>last_z
        src.loc=locate(last_x,last_y,last_z)
        src.verbs+=Saved_Verbs
Jun 26 2003, 12:33 am
In response to Crispy
Crispy wrote:
MLAAS had a problem like this a while back.

The problem has returned to MLAAS >_<

Stealth2k
Jun 26 2003, 12:36 am
In response to Stealth 2k
Stealth 2k wrote:
The problem has returned to MLAAS >_<

I know. =( Maybe it's the same reason Goku's having trouble. *shrug*
Jun 26 2003, 2:16 am
In response to Crispy
This has happened with DBZeta and may actually be a BYOND bug. If the server isnt shutdown in a manner in which world/Del() is called (ie. killing the server via shell) all save files, regardless of whether or not players have saved their game since then, are reverted back to when the server started.

This only seems to apply to savefiles that are in-use at the time the server is shutdown...
Jun 26 2003, 4:00 am (Edited on Jun 26 2003, 4:06 am)
In response to Crispy
In addition to this, just having simple references to other mobs(such as a party member(s)) can also produce this same effect. Declaring those variables as temp would solve that issue.
Jun 26 2003, 5:48 am (Edited on Jun 26 2003, 6:12 am)
Make it so saving and loading of anything don't load references to mobs...


This should fix all of everyone's rollback problems.


This includes mobs with reference vars.

THe easiest way to do that is to just turn reference vars of mobs to /tmps
Jun 26 2003, 6:05 am
In response to Nick231
Nick231 wrote:
This has happened with DBZeta and may actually be a BYOND bug.

This is not a BYOND bug. If you read the other posts you'll see it's a well-known issue with savefiles caused by carelessness about object references.

If the server isnt shutdown in a manner in which world/Del() is called (ie. killing the server via shell) all save files, regardless of whether or not players have saved their game since then, are reverted back to when the server started.

This only seems to apply to savefiles that are in-use at the time the server is shutdown...

No. You're totally off-base there.

Lummox JR
Jun 26 2003, 6:18 am
Tenkuu's advice is correct: Any reference to a mob, or any atom that contains a mob or a list with a reference to it, may have the same problem. The reference doesn't even have to be direct. If you have a reference to a /party datum, for example, and party.members has a list of party members, every single one of those party members will be saved into your savefile along with you.

The solution is to use /tmp vars for anything like that. If you declared a var as var/tmp/mob/leader, for example, it wouldn't save. (Nor should it load, but if it does you can always override mob/Read() to ignore and delete it.)

And if you really need to save that information so a /tmp var won't do, then you need to override Write() and Read() so the information is converted into a safer form before it saves and then translated back after it loads. Like this:
mob
  var/mob/player/leader

  Write(savefile/F)
    ..()
    if(leader && leader.key)
      F["leader_key"] << leader.key
    else
      F["X"] << x
      F["Y"] << y
      F["Z"] << z

  Read(savefile/F)
    F.Remove("leader")    // fix old savefiles; prevent rollback
    ..()
    var/lk
    F["leader_key"] >> lk
    if(lk)
      for(leader)     // loop through /mob/player
        if(leader.key == lk) break    // stop on the right key
      // leader is null if the key wasn't found
    if(leader)
      // rejoin the party leader
      var/atom/A = pick(oview(2,leader))
      while(!isturf(A)) A = A.loc
      loc = A
    else
      // reload old saved position
      var {X; Y; Z}
      F["X"] >> X
      F["Y"] >> Y
      F["Z"] >> Z
      loc = locate(X, Y, Z)

Lummox JR
Jun 26 2003, 9:53 am (Edited on Jun 26 2003, 10:06 am)
In response to Kunark
hmm...strange, I have no "leader" type variable set up, nor do I use a mob in a list/reference except MAYBE when they use a Fusion Technique. But, that rarely happens...it does it no matter what it feels like :-S

********
*<EDIT>*
********
Also, here is my Read()/Write() procs that I've over ridden:
And, one more thing, my fusion variables are as well tmp variables. Any suggestions?
    Write(savefile/F)
        ..()
        F["Saved_Verbs"]<<src.verbs
        F["last_x"]<<src.x
        F["last_y"]<<src.y
        F["last_z"]<<src.z
    Read(savefile/F)
        ..()
        var/Saved_Verbs
        var/last_x
        var/last_y
        var/last_z
        F["Saved_Verbs"]>>Saved_Verbs
        F["last_x"]>>last_x
        F["last_y"]>>last_y
        F["last_z"]>>last_z
        src.loc=locate(last_x,last_y,last_z)
        src.verbs+=Saved_Verbs

*********
*</EDIT>*
*********
Jun 26 2003, 11:02 am
In response to Goku72
This isn't a problem with your Write()/Read()... This is a problem somewhere else.

The area in those that is making them rollback is the ..() because that calls the parent proc.

Also, deleting ..() wont do anything but make it not load right unless you put in a custom made read/write area in the proc (as shown by lummox's custom read/writes in the post above.).


You have to be skipping a var that you didn't think of, or you are saving other atoms with references to mobs and not thinking about those. group/party/guild_mates vars are examples of variables that can cause this, Also, lets say a poisoned_by var could cause this too.
Jun 26 2003, 8:39 pm
In response to Kunark
A hint for detecting whether you have any non-tmp vars that should be tmp: Use the Object tab above the file list. Make sure it's updated, then go through all atom types looking for vars that reference other atom types. If there are any, double-click on the var definition and change it to a tmp var.
Jun 27 2003, 9:54 am
In response to Crispy
Crispy wrote:
Stealth 2k wrote:
The problem has returned to MLAAS >_<

There was one case I think that may have been this bug, but for the most part, what people think was a rollback was simply the fact that the server crashed, and not all progress was saved. When the server came back up, the most recent save was loaded, but for some people, it was several hours out of date, if they hadn't triggered a save in-game.