[DGD] Persistance

[Noah Gibbs]

--- Robert Forshaw <iouswuoibev at hotmail.com> wrote:
> Well I remember what mine used to be like (LPC was
> the very first language I 
> actually learned properly and became good at).

  *grin*

  While LPC wasn't my first language, my first MUD
code (in C, on a Diku-ish base) was pretty bad.

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

  Calling MUD programming "filling in templates" is
like saying that Neal Stephenson is "just pushing keys
on the keyboard" to write things like Cryptonomicon. 
Technically true, but missing the point.  If you do it
well, building is storytelling.  Saying that
storytelling sucks because it isn't programming is... 
Well, silly.

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

  But you need to either have a persistent MUD, or
have the ability to load and save.  At least, if you
want those changes to stick around.  And since those
changes can be used for building, now we're at the
point where building in a persistent environment is
different again :-)

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

  And again, you have to either do save/load or
statedumps, or you have to have all that state go away
every time you reboot.

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

  Conceptually, I guess.  A more accurate way to put
it is that the in-memory version is definitive, so
updating that is updating the only thing that matters.
 If you ever bother to put it back in a data file
(which Phantasmal does), you'll just write the data
file instead of dumping state (which Phantasmal *can*
do, or it can dump state).

  So the data file is, by its nature, out of date at
the time you run the command.  If you want new
up-to-date data files you'll need to output them
again.  In Phantasmal's case you do that with the
%shutdown or %datadump commands.

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

  Don't think so.  Statedumps use a format that's easy
for DGD to parse and hard for humans.  The
save_object() command is mostly the opposite.  Also,
Dworkin dislikes it and prefers you not use it, so
it's probably not very fast :-)


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