[DGD] Could it work...

[Matt Taylor]

Thanks Erwin, 

Sorry to take up loads of time with simple questions. I'm probably the most
inexperienced coder here ... Hope it's not too much trouble.

I guess what we want to know is what do we need to ensure our MUD can be
persistent. I know we've been warned off doing it as an initial project, but
if the help is out there then my coding partner at least is willing to give
it a shot :) There's strength of will for ya ;)

Obviously we are going to need to include more than we have.
The way I understand it we might need:

(1) Some sort of object manager to keep track of compiled objects and their
clones so they are not lost.

(2) Some sort of r-limits applied. This would be on call-outs,
receive-message and open, close? I couldn't understand why open/close would
need r-limits though :(

(3) Resource management. So that, as you mentioned, someone doesn't take the
game down with 60000 clones of an object.

(4) State dumping and restarts from state-dump for crashes etc.

But I can't think of any more. Perhaps I am being Dr. Dim so I would
appreciate help (cheeky I know, seeing as you guys have been so helpful
already) :)

Please don't despair with me ... I do learn, it just goes in slowly ;)

Regards and thanks,


Matt 

> On Wed, Sep 19, 2001 at 12:22:35AM +0100, mtaylor wrote:
>> Me again I'm afraid,
>> 
>> My coding partner thinks that we can use what we need of the kernel lib to
>> develop our own system. The good thing for us about doing that is that we
>> will then understand what is going on.
>> 
>> Does anyone have the time (and/or patience) to list what it is the kernel
>> lib does and very briefly how and why it does it.
> 
> Disclaimer: I doubt this list is complete.
> 
> The kernel-lib...
> 
> - provides the basic ability to add users, grant users access, grant
> users limited quota of objects, stack/ticks/callout-usage, to avoid
> someone going ahead and creating 60000 clones of some object and
> thereby taking the game down.
> 
> - provides the ability for external objects to 'hook' themselves into
> the /kernel/sys/driver.c object (and one or two other /kernel
> objects) so that you will be notified if an object is compiled,
> cloned, destructed, freed, inherited, a file #include'd, etc.
> 
> This is where you would hook up an 'Object DB' that keeps track of
> the inheritance information so that you can write your own 'upgrade'
> command that recompiles whatever is necessary.  This is one of the
> things that is _not_ provided by the kernel-lib. :)
> 
> - provides a basic wiztool (with a very nice 'store results for reuse'
> approach).
> 
> - enforces that inheritables, clonables and 'other' code are in
> separate directories, 'lib/' subdirs for inherities, 'obj/' subdirs
> for clonables and, more recently, 'data/' subdirs for LWOs.
> 
> I'm sure there are other useful things but these are just some that
> come to mind right now.
> 
> Hope this helps,
> 
> Erwin.

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