[DGD] Persistance

[Bart van Leeuwen]

On Thu, 8 Jan 2004, Robert Forshaw wrote:

> >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...

How interesting..
2 of my coders have been pushing for, and workign on a GUI based tool to
do just that, reduce writing basic rooms/monsters/objects to filling out
templates.. the tool will just ask the proper questions to ensure a
minimum of information is given that will work for the mud. They want this
to make that they can concentrate on describing things instead of having
to 'code' them, at least for all standard cases.

Designing a world is not about code, code is what makes the world work,
but it does no more and no less then that.

As a coder I take pride in my code, and I think there is a real
achievement in writing it. For the area designers that we have around, the
goal and achievement is in user experience, code, descriptions and what
not are a tool for that.

>
> >   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.

Using an interpreted data model always adds an extra layer. It is very
usefull, but it is also very hard to debug when somethign is wrong in your
design, or you just happen to have implemented some of the interpreting
code in a way that doesn't account for all conditions.

It is very usefull, but it is definitely not easier to debug unless you
have designed, written and debugged your code very well.

> > >
> > > 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.

If you have a few objects for which you need to keep state, it may be
faster, if you don't know or have a lot of objects that need to keep
state, go for state dumps.

>
> >
> > > 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.

>From what I understand, statedumps are more efficient if the swapfile is
kept uptodate (ie, when the only objects in memory are those that are
actually beign used)

This makes it seem to me that there is some use in scheduling swapouts?
I know I do a statedump every 60 minutes, and it doesn't cause any
noticable lagging, but I guess that with less then 10k objects around, my
environment quallifies as rather small for now

>
> _________________________________________________________________
> 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
>

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