[DGD] Persistance

[Noah Gibbs]

> > Yes.  When you change the definition of
> > an object to have new data fields, you have to
> > put something in the new data fields.  When
> > you change how things get stored, you massage
> > the data into the new forms.
>
> That sounds like a big pain. Unless you have
> good foresight and know a good 
> way of avoiding such difficulty (I don't :P).

  Yup.  In a non-persistent MUD, you'd change your
routines for reading and writing files, which would
require you to write almost the same code.  It's a
tradeoff.  If you save and reload to external files,
you'll probably write less code, but you can't keep
your MUD up all the time.  That's the reason
Phantasmal does it your way, and uses file save/load
rather than update functions for most things.  I don't
care about uptime or professionalism, I just want to
upgrade with minimum pain.  File load and save is
probably the least pain if you don't care about
uptime.

  Skotos has running games, and they want to keep them
running cleanly and smoothly, so they use in-place
update.  That way they don't have to take their server
down for bugfixes.

> > [... Example ...]
> >   So far, so good.  But where do I put the
> > code to fill in all those fields?  One answer
> > is "in the ObjectD".  My favorite answer is
> > to have the ObjectD call a function
> > called "upgraded" if it exists on every
> > object that gets upgraded.  That's what
> > Phantasmal does.
>
> I thought it would go in the object where the
> data is being loaded to...

  It does.  That object defines the upgraded()
function, which gets called by ObjectD.  But the
function is in the object that's being upgraded.

> [...] I don't like the
> idea of datafiles and I think that is
> something to be considered seperately.

  Yes it is.

> > > I never have
> > > thought that writing an
> > > object manager will be hard.
> >
> >   Look at the existing ones before you
> > decide that. Please.  There are some
> > subtleties you're not considering.  Seriously.
>
> I do keep examing the kernel one but I just
> end up confused.

  Yeah.  One reason you're probably confused is that
the kernel library doesn't come with one.  It just
knows how to delegate to one.  Look on my page of LPC
code samples and look for the example object manager
by Geir Harald Hansen.  It's the same one I used for
reference when writing Phantasmal's.  Or you could
look at Phantasmal's ObjectD, but it's a little more
complicated.

> >   Also, bear in mind that altering objects
> > in these ways is actually a good way for
> > builders to do stuff.  That's harder if it
> > all goes away every couple of weeks :-)

> I'm not sure what you mean. By 'do stuff' do
> you mean build or interfere with the games
> natural process?

  I meant build, though you could interfere as well.

> If you mean building, then what exactly goes
> away every couple of weeks? The code they've
> produced doesn't go away (*confused*).

  Being able to reshape an existing object depends on
being able to easily make alterations.  If you *can*
easily make alterations (i.e. without altering the
code), then those alterations can stay.  So builders
could have, say, a wand that makes things heavier and
lighter, and use that to adjust weights.  Or if you
have light levels, they could use a similar
contrivance to make sure everything is of a similar
light level without having to edit files.

  But if you're set on objects consisting only of
code, and being recompiled to change their object
values, then that doesn't matter as much to you. 
Since objects can't change attributes in any
programmatic way in your system, you'll care less
about altering them and having it stick.

> Thanks for the response though, it was valuable
> because you've swayed me into going for a
> persitant MUD rather than a 'standard' one. :)

  Happy to help.


=====
------
noah_gibbs at yahoo.com

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd