[DGD] Re: Strange clone_object behaviour

[Frank Schmidt]

<SKIP THIS PAGE IF THE FIRST PROBLEM IS IRRELEVANT; MORE INFO BELOW>

On Sun, 13 Sep 1998, Tim Blommerde wrote:

> Well, I haven't tinkered with the auto object what so ever.  It's the object
> that comes with the standard dgd package, though it might be changed a bit
> by either the patches 1.1p1 to 1.1p6, the net package and/or the object-info
> package.  The clone_object() in the auto object takes two strings as an
> argument, the first being the path and the second, being an user id.  The
> only return value in this function though is:
>     return ::clone_object(obj);
> Where 'obj' is the object returned by the original kfun find_object() with
> as variable the path string.  So, for as far as I can deduct, the
> clone_object() function in the auto object is alright. And yes, 'FTP_USER'
> is indeed a string.
> 
> >As for your questions at the top: yes, clone_object() should return an
> >object with a  '<master_file>#<id>' type name.

I think this problem has been addressed in this mailinglist some time
ago. It arose with the new compile_object() in dgd. Whenever you
compile_object() a file, you need to call a dummy function in it so that
create() is called in it. It would look something like this:


/* clone an object */
static object clone_object(string path) {
  object ob;
  if (!(ob=::find_object(path)))
    return ::clone_object(compile_object(path));
  return ::clone_object(ob);
}

/* compile a file */
static object compile_object(string file) {
  object ob;

  if ((ob=::compile_object(file))) {
    /* call dummy function in program to ensure __create() gets called */
    ::call_other(ob, "??");
  }
  return ob;
}


This should help "load" the master program correctly. Problems with this
tends to arise and disappear seemingly randomly.

> Ps. Btw, are there a lot of people using the lib that comes with the dgd
> driver, or is everybody writing/has written their own version?  And if so,
> have you based it on the original lib, or used the 2.4.5 or Melville lib as
> a skeleton?


<MUDOS FOR DGD-1.1p6 package>

For myself, I think the lib that comes with dgd do not suit me at all.
With all respect, I think Dworkin is a hellofalot better driver coder than
mudlib (or kernel lib) coder. The problem wasn't that it lacked all nifty
features (like ftp daemon, intermud, doors, torch, lantern, rope and
ai_monster support), but that it limited the actual mudlib-base to be
coded upon it (by occupying the auto and driver object). And no, I don't
think the code was bad, just too different to suit my own ideas of
building a mudlib.

That raises another issue, namely that DGD itself (I think) is too bare to
form a base for a mudlib. So you would need some kind of "kernel".

I wouldn't use 2.4.5 as base for a "modern" mudlib. It is just too old.
Melville is not suitable as a starting point either I think, it is a very
good mudlib for novice mudlibbers to learn the basics from though.

In lack of something better, I decided 1 1/2 years ago to make my own lib
for DGD. The code was made from scratch, but I used all the mudlib code
I could get hold of (LambdaMOO, Melville, 2.4.5 emulation, div.
examples, the docs, help from others more into the details than I were).
Although, examples gave me ideas, on how to- and not how to do it, 99% of
the code in the finished version is my own. All of it has undergone
several rewrites/upgrades.

The project started up to emulate MudOS in DGD. Most of the basic
functions in MudOS are supported, but not the ones that just can't be
emulated in DGD without packages (like net-functions, undefinedp(),
nullp(), zerop() you know, all those "stupid" functions are left out. ;)
Additionally, "impossible" emulatable things like function
pointers are emulated through macros. FPs are those (: :) in MudOS.

The project evolved to be something much more than just emulating
stinky ol' MudOS. It enhances it with several new/improved functions for
arrays, strings and perhaps one or two for mappings. Also, MUCH of the
MudOS-specific things can be switched OFF. That means that ALL
(stupid?) support for "living", "inventory" etc, etc, can be completely
turned off. Also, inconsistent function-naming (like MudOS' extract())
can also be avoided by configuration. It is up to you to configure what
you want. You can have the best of MudOS and DGD in one! (Weee ;)

All in all, this lib is designed to work; both as a port from MudOS to DGD
and as an excellent base to write new DGD mudlibs. The lib-code should be
compilable to C for those who wants more speed (not sure how that is done
in practice yet). Though the lib is _very_ optimized.


The "MudOS-alike for DGD" (for dgd-1.1p6) can be obtained at:

-Beta version (without specific docs about functions):
http://colargol.idb.hist.no/~franks/MudOSa4DGD-1.1b.tar.gz

-Latest working version (90% specific docs written, RECOMMENDED):
http://colargol.idb.hist.no/~franks/MudOSa4DGD-30.06.98.tar.gz


Best Regards, 

Frank Schmidt




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