Author Topic: Persistence w/ MUD Crash?  (Read 2706 times)

Offline Nilrin

  • Friend
  • **
  • Posts: 85
    • View Profile
Persistence w/ MUD Crash?
« on: February 08, 2013, 11:29:05 pm »
Here's the scoop. Currently I have a 'sort of persistence' scenario in which the majority of rooms in my MUD persist when destructed. Both tangible items and NPCs persist within these rooms.

Let's say, for instance, that there was -NPC rat- and he is lucky enough to be loaded into the MUD some place in the deep dark forest. Now, he was loaded there because the silly -player- came walking in and loaded a room that happened to have a persistence file, and within that persistence file was the saved -NPC rat-. When the -player- saw the -NPC rat-, he decided that it wasn't worth the experience, and wandered on his marry way. Ah, but -NPC rat- had his own plan, and went exploring the vastness that is the deep dark forest. Since the -NPC rat- and the -player- were both gone, there was nothing left for the room to persist, so it removed its persistence file.

However, before long, something strange happened. Who knows what caused it. Perhaps it was meant to be, or perhaps it was the great nothing, or an act of god, or perhaps the great -creator- of everything flipped his shoe off and bumped the power button on the world we call computer. The point is, everything ceased to be. The -player-, gone. The -NPC rat-, gone. The deep dark forest, and everything else, gone.

Fortunately, what was once nothing can become something again, thanks to the magic the -creator- refers to as reboot. The -player- logs back in to the MUD, the rooms will load into memory when they are ready, but what of the -NPC rat-?

The -NPC rat- lost his persistence file, was loaded in memory, but had not the chance to create himself a new persistence file in whatever room he found himself in while exploring. The -NPC rat- is effectively gone forever. We can only hope that one day the merciless -creator- will notice the generic yet brave -NPC rat- is missing from the world, and will be brought back into existence again with the power of -clone-.

So therein lies the problem.

I've been pondering this problem for a few days now and due to a lack of imagination (see story above if you don't believe me), I've only come up with a few solutions. Of them, only one really seems reliable. Still, I thought I would share this with others full well knowing I'm not the only one with this issue and has probably been solved before.

Solution 1: Have regular MUD reboots, which, upon ending, does a backup of the entire MUD.

Solution 2: Have a daemon persist all NPCs, even NPC rats, which are currently loaded in memory. Again, this would have to be at regular intervals.

Solution 3:  When specific (generic) NPCs are cloned, they tell a daemon that they just loaded into memory, “Persist me, just in case.” When eventDestruct is called within the same NPCs, they again inform the daemon, “Alright, I'm safely persisted in my own room now, you can remove my separate persistence file.” When the MUD boots up, it loads the daemon and within its create() function, it checks to see if there are any persistence files it created. If so, go ahead and load them in to memery.

Any thoughts?

Offline Camlorn

  • Friend
  • **
  • Posts: 76
    • View Profile
Re: Persistence w/ MUD Crash?
« Reply #1 on: February 08, 2013, 11:54:32 pm »
Solution: use Dgd, which can do full mud persistence for you, and is tested more than your implementation will be before you start testing it.

    If you're working on a new mud--there you go.  If you're not, the answer is harder, and will be very, very complicated and difficult to maintain.  The issue here is that a mob is not different than a room, in that both are objects, and if you want to persist other things besides mobs, the solution may involve dealing with circular references.  Also, you can not guarantee that, when a room is reloaded, it will have the same name--not unless you're restricting yourself to the old "every room is an lpc file" approach, and so now you can't be sure which rooms need those mobs back.  Moving to Dgd will require mudlib rewriting, probably; it may or may not be worth it, depending on what you want to do.

    I don't have a link, but there's a FluffOS persistence daemon on these forums somewhere.  I do not know if it handles circular references without crashing.

    I'm afraid I can't offer much beyond move to Dgd, as the best approach depends on a lot of things, including me not having experience in this area and what mudlib you're using, etc.  If FluffOS handled circular referencces--references at all for that matter--you could just serialize the root object and watch it go.  In truth, though, circular references are the biggest stumbling block, but FluffOS does not, when I last looked at it anyway, save objects contained by/referenced by other objects, anyway.

Offline Nilrin

  • Friend
  • **
  • Posts: 85
    • View Profile
Re: Persistence w/ MUD Crash?
« Reply #2 on: February 09, 2013, 12:57:45 am »
The same name issue you mentioned isn't really a problem. When generating virtual rooms for example, each room is using a virtual file name and can be referenced as such. Of all the possible 90,000+ virtual rooms, they share the same 50 or so files, but I have solved issues persisting them.

Honestly, even though the driver side would handle true persistence, in Dead Souls, the specific persistence stuff (such as when to decide an object should be persisted) is handled within the library.

But anyway, it isn't a new MUD I'm working on. I'm only hanging on to object persistence, not full persistence. IE: I don't have a desire to boot up the MUD and resume where I left off in combat. Years ago I looked at DGD as a possible start for Rebirth, but decided against it in favour of Dead Souls running off of FluffOS.

I guess what I'm getting at is I'm not looking for a solution to making things 'truly' persistent. The problem lies in the method that Dead Souls uses to persist rooms, items, and NPCs, in that it isn't safe against MUD crashes. I'm hoping to find a half-way elegant solution to solve this.

Offline chaos

  • BFF
  • ***
  • Posts: 291
  • Job, school, social life, sleep. Pick 2.5.
    • View Profile
    • Lost Souls
Re: Persistence w/ MUD Crash?
« Reply #3 on: February 09, 2013, 01:13:20 am »
I'm doing something like what you're doing, in a "beta" type fashion only deployed in some areas, and the way I address the issue you raise is basically your option 2: objects don't manage their own persistence in any way (and nothing is tied to a "home room"), their persistence is managed by a daemon that periodically takes state dumps of them and restores them in their previous state and location after boot.  (I devolve responsibility for this upon project control daemons rather than a global daemon.)

Offline quixadhal

  • BFF
  • ***
  • Posts: 642
    • View Profile
    • WileyMUD
Re: Persistence w/ MUD Crash?
« Reply #4 on: February 09, 2013, 09:03:10 am »
I would probably do something along the lines of what chaos was saying, perhaps even leaning a bit more towards the DikuMUD camp.

Have each domain keep a daemon that manages persistent objects (of any kind), and simply tracks their last known location and state info.

You could do that pretty simply.  Have each create event register the item with the daemon, and push state info to it.  That might be as simple as the save variables + the environment.  The daemon can then know exactly how many objects/npcs/etc are, WHERE they ware, and keep a serialized state info to restore if they need to be recreated.

Whenever an object moves, have it repeat the process, so the new location is updated.  Up to you if you think you need to refresh the state info for other events.  On destruct, just tell the daemon to remove its data.

Extra bonus feature, you can now easily find out where every "sewer rat" is without having to walk through all the rooms... the daemon would know and report without swapping anything in.

Extra extra bonus feature... you could code your areas to spawn NPC's in random rooms, rather than tying them to "spawn points", which is old 1990's code.  It makes sense for guards to be at their post, but why always have the Fluffy Bunny of Death spawn in the carrot patch?  Maybe he should start in the lettuce today?

Offline Nilrin

  • Friend
  • **
  • Posts: 85
    • View Profile
Re: Persistence w/ MUD Crash?
« Reply #5 on: February 09, 2013, 12:17:48 pm »
That's actually what I have going on as far as 'spawn' points, which is partially what brought attention to the main issue. I have all this wilderness right, and the admin come in and go, "Ah, this wilderness needs some bunnies." So the admin just clones, say, 25 bunnies and allows them to wander and load new rooms as they go along. If the player comes and kills a bunny, upon death, the bunny tells a daemon that it dies and needs to eventually re-spawn some place random. The daemon remembers that, waits a certain amount of time, and then eventually spawns the bunny some place else. The wait to spawn is also cumulative. This means players, for example, can over hunt all the bunnies, meaning they will be underpopulated for a while due to the players being frivolous.

The same goes for more unique NPCs as well, such as shopkeepers. I just code the file and clone them in. One exception though, is that they don't ask the daemon to re-spawn. So, if a player kills a shopkeeper cause he's a jerk, that shopkeeper never comes back. This could be a bad thing in terms of game mechanics, but in small player base role playing MUD, it's a welcome feature.

Anyway, the one caveat I see in a daemon saving objects as they wander around is that unless it writes to a file each and every time an NPC moves, it will be subject to the same MUD crash as the objects themselves. If it did save every time, that would be a huge amount of disk access.

This is why I was leaning towards option 3. I could save objects when they clone in to memory with their own pseudo swap file, which simply remembers where they came from and what variables they had upon cloning in. Sure, if the MUD crashes it wont remember their last known location, but at least the MUD wont forget that there are 25 bunnies.

BTW, I really appreciate the feedback from you guys. It helps clue me in and tell me I'm at least going in the right direction.

Offline quixadhal

  • BFF
  • ***
  • Posts: 642
    • View Profile
    • WileyMUD
Re: Persistence w/ MUD Crash?
« Reply #6 on: February 09, 2013, 12:34:21 pm »
A couple of points to remember... disk I/O is not the same as it was in 1990.

When you "write to disk", you're really asking the OS to "write to disk", which means it gets written to a memory buffer and flushed whenever the OS feels like it... and then the disk itself buffers it for a bit more to see if other writes will be to the same cylinder.

So, writing to disk a whole bunch is generally not going to even be noticeable, unless you're already resource starved in some other way.

But, you can always decide for yourself when to flush buffers... if you want to save on each change, or if you want to register a call_out to do it every 5 minutes.