The Rollback Bug and How it Works?

ID:156252
 
Nov 26 2010, 2:47 am
Allo. I know the rollback bug is caused by linking and sticking 2 mobs together. I saw a dev post on it awhile back that showed an example using "friend".

So from what i can tell saving your file while that mob is linked in etc could cause a rollback.

So...

Would having a similar thing for guilds and or villages cause the same thing?

e.g.
mob/var/villages/village = spider_village.

villages
  spider_village
  snake_village


as far as i know that -would- cause a rollback bug and a solution would be to make the village variable tmp. so that its never saved.

Is the only way to bypass this to make it a temporary var and an additional perma var (that contains the village name) that then has a proc ran on load that simply puts humpty dumpty back together?

or is their another way?
Nov 26 2010, 5:07 am
It seems that you don't quite understand it, so read that Dream Makers article again to understand what this so-called "mystified Rollback Bug™" is.

Midgetbuster wrote:
as far as i know that -would- cause a rollback bug

Your code as posted will only be potentially harmful in that regard if in its expanded form the village datums had references to player mobs in non-tmp vars.

Is the only way to bypass this to make it a temporary var and an additional perma var (that contains the village name) that then has a proc ran on load that simply puts humpty dumpty back together?

Since when is there only one way to design anything in programming?
The basic idea is not to save what doesn't need to and should not be saved, and restore it upon load instead. But there are multiple possible approaches to this. The pool of them also varies according to your situation.

Nothing requires to, for example, create a new dummy var for the mob to carry. You can control your object saving, so you can prevent (f.ex.) the guild's list of mobs from being saved and save key (or character) identifiers instead. If you're using a guild datum, then similar things would be done with it, as there's no need for the player to actually save that datum with himself neither for the guild to save the player mobs (and both of those would be stupid and potentially problematic). 
mob/player
   var/tmp/guild/guild
   Write(savefile/F)
      ..()
      //save location, whatever, if you want
      if(src.guild)
         F["myguild"] << src.guild.name //save whatever is a suitable identifier
   Read(savefile/F)
      ..()
      //...
      if("myguild" in F.dir)
         var/guild_id
         F["myguild"] >> guild_id
         if(guild_id)
            //find the guild object according to id (perhaps load it from the guilds savefile if necessary).
         var/guild = all_guilds[guild_id]
         if(guild) src.guild = guild


Of course, with a guild... you'd probably want a /guild to have some sort of textual list of its members at all times anyway, if only for display purposes.
Nov 26 2010, 5:57 am
Midgetbuster wrote:
Allo. I know the rollback bug is caused by linking and sticking 2 mobs together. I saw a dev post on it awhile back that showed an example using "friend".

The term "rollback bug" is a bit of a misnomer. It's only a bug insofar as it's a logic error in your own game.

So from what i can tell saving your file while that mob is linked in etc could cause a rollback.

So...

Would having a similar thing for guilds and or villages cause the same thing?

Yes, it would. If you have a datum and that datum holds a non-tmp reference to a mob, the mob will save with it.

Whenever you save any kind of datum, BYOND will save any references that datum has, and any references those other objects have, and so on. A /tmp var will avoid this because /tmp vars don't get saved. There are also other methods, like storing only info that would point to the item in question without actually having a direct reference.

Lummox JR