[DGD] Persistance

[Robert Forshaw]

>From: Noah Gibbs <noah_gibbs at yahoo.com>
>   Didn't figure you would.  You don't seem to have
>much experience with just how horrible most MUD
>builders' code is.  There's time for you to gain
>enlightenment in that respect.

Well I remember what mine used to be like (LPC was the very first language I 
actually learned properly and became good at).

>This is where you get to tell me that you'd never
>accept anybody that wasn't a good coder to build on
>your MUD.  I know the drill.  However, it's also where
>I get to laugh at you since I know how hard it is to
>find good builders who *can't* code, let alone the
>ones who can. :-)

I also think that not having done any programming diminishes your sense of 
achievement. When its just a matter of filling in templates...

>   That's because you don't like the idea of altering
>object attributes on the fly.

On the contrary, I think it is very useful to be able to do that. And you 
can do that by calling functions in the object.
I *really* like the
>idea of being able to change an object's description
>or weight or damage rating using a single command on
>the command-line.

You can do that too, by calling a function.

>Having a data format instead of all
>code starts paying off very quickly in that case.

So what you're saying is, a single command immediately updates the data file 
and then immediately updates the object? I'm beginning to get the idea (I 
think). I'm still not sure if its worth doing though.

>
>   And you're not avoiding the effort of code.  You're
>avoiding the error-proneness of code, and the slowness
>of code, and the security requirements of code, and
>handling errors caused by code...  The nice thing
>about a data format is that you can be really fascist
>about it.  Not an integer?  Ditch it.
>
>   You can handle all the same problems with code, but
>debugging all the error handling machinery is more of
>a pain.  Again, I know.  I do both.
>
> > > Plus you can alter the
> > >objects more easily after creation since your
> > >changes stick, and you don't have to make
> > >changes to the code.
> >
> > That is one advantage, sure, but with an object
> > manager keeping everything
> > in task it isn't so hard to make an 'update'
> > command to recompile an altred
> > object.
>
>   Nope, that's pretty easy, you're right.  However,
>given the choice of a one-line update command or
>editing a file and recompiling, I'll take the one-line
>update command.  Again, that's what my MUD does.

And don't worry I'll be having a look at it as soon as I think I am able to 
comprehend it all. ;)

> > But you only have to set attributes once 'my way' as
> > well.
>
>   Nope.  You have to write code that knows how to set
>it once, which is different.  You still have to keep
>the code around to keep setting it.  Your code has to
>keep working -- not just the line that sets the
>attributes, but the whole file, 'cause otherwise it
>doesn't compile and the object goes away.  The code is
>brittle, and you have to make sure it sticks around.

Ok.

>Well, yes.  Statedumps are the fastest complete
>backups you'll find under DGD.  You can complain about
>them causing lag, but any other form of complete
>backup will cause even more lag.  If you object to the
>possibility that a crash will destroy your stuff, you
>have to keep backups.  And statedumps are the fastest
>available backups.

Ok, got it. I thought save_object() would be faster.

>
> > And if you only permit a statedump
> > at shutdown (which interrupts the MUD, doesn't it?)
>
>   It does, in fact, interrupt the MUD.  That's why I
>(for Phantasmal) have a form of shutdown that allows
>statedumps, and I also have a "%statedump" command
>that does a statedump *without* shutting the MUD down.
>  As with a number of other issues you've mentioned,
>you don't have to pick one way and do it that way.
>You can do both, it just takes a little more code.  In
>this case, barely more code at all.
>
> > The only way to keep things backed up
> > enough would be to do a statedump every
> > hour or so,
> > and I think that's too
> > much lag. Which is why I was thinking, it
> > would be more appropriate to save
> > certain critical objects, like the users,
> > every 20 minutes or so, and do
> > statedumps as well say, every 5 days?
>
>   Sure, that'd work.  I think you've decided
>statedumps are laggier than they are, but whatever.
>You can try it out and see how much of a problem you
>have.  I suspect you'll discover that statedumps are
>fast and your worries are baseless.  But it's easy to
>make that configurable, so you'll write about the same
>code either way.

That's what I'll do then, try it out.

_________________________________________________________________
It's fast, it's easy and it's free. Get MSN Messenger today! 
http://www.msn.co.uk/messenger

_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd