[DGD] A few questions

[Jesse Garrison]

I've worked with DGD a bit in the past and followed it's development
for quite a few years now so I'm not a total newbie, but originally
coming from a MudOS background and having no non-LPC programming
experience I never really felt capable of building anything that could
take full advantage of the driver. I took a few years off MUD coding
(other than helping a few friends here and there) to go to school and
study computer science (because I wanted to, not for the sole purpose
of being a better MUD coder, that's just a nice side effect). Lately,
I've been thinking about getting back into LPC and rereading all the
DGD documentation to study up on the advanced features. It's amazing
how much easier all this stuff is when you've been exposed to things
like Data Structures and Operating Systems. I can actually read and
understand the Kernel library now. (It always made my head explode
before).

I don't have a whole lot of free time because my school believes in
learning by doing and I've been spending an average of about twenty
hours a week on programming assignments for senior level classes, but
I've been doing some experiments with DGD and I have a few questions.

1) Full Persistence is a really neat idea. My original idea for
implementing it was to have each inheritable store a list of all the
objects that inherit it (and each master object store a list of its
own clones). Basically a tree that could be traversed to find every
child of a particular inheritable. It would also allow the lists to be
swapped to disk. I realize at this point that I'm really fuzzy on how
inheritance works internally. Is it even possible for inheritables to
store data in their variables? I suppose so since most mudlibs fail to
differentiate between inheritables and cloneables. I'd also assumed
that every child would have a new blank copy of the variable. I think
this is true, but I'm not entirely sure.

The issue I run into then is that every object right down to the
clones is going to have a copy of this variable. That seems slightly
wasteful, but I don't know if it will make a big difference in the
long run since it should never be initialized for them. I've looked,
but I haven't found a way to make a variable ONLY appear in the
current object, rather than appearing in all of its children or
clones.

So what is the proper way of storing these lists? I think I read
somewhere to use LWOs and just put an object pointer in every object
that could be used to point to such a list. Is this the most effective
solution?

2) On the Phantasmal site in the Persistence section there is a quote
from Par Winzell that says "In a persistent world, rather than write a
lot of startup code, you tend to write behavior code, and configure
objects." Now this is probably just my MudOS background talking, but
if all of your objects are virtual where do you put this behavior
code?

I absolutely love the idea of LPC OLC without having to save
initialization scripts to disk (I assume this is done with clones),
but what if a builder wants to add special functionality to their room
or object? (ie behavior code) Normally, that code is stored in the
file with the initialization code, but if there is no initialization
code... Is this saying that each object is still its own .c file, but
without any initialization code (therefore objects without any
behavior code wouldn't really need files?). What happens if you decide
to add some behavior code after the fact? What if you want to take a
certain set of clones of " longsword.c" and give them the
functionality in a new "vorpal_longsword.c". That wouldn't be too hard
to hack around with reboots that wiped out all existing objects, but
how would you do it in a persistent game? Maybe I'm completely
thinking about this from the wrong direction and it's actually really
simple, but how does not having any initialization scripts work
exactly? Is it exactly the same as having initialization scripts, you
just never bother to call create() in the objects and set all their
values manually each time a new clone is made?

Thanks a bunch,

Jesse Garrison