[DGD] Small note plus a draft FAQ
Gregory D Lewis
glewis at maths.adelaide.edu.au
Mon Dec 22 23:52:35 CET 1997
Hi all,
A couple of things just before Christmas.
For those using my mdbm or regex packages I will be uploading a new version
of each tonight. No new functionality but fixes for static vs. dynamic
memory management which caused some serious problems in the old version.
Much thanks to Dworkin for the tutorial on DGD memory management :).
I've also put together a draft FAQ for DGD. It almost certainly has a few
errors and doesn't cover all the topics people think should be covered, but
thats one of the reasons I'm posting it here first. Experienced users please
read and tell me about any incorrect information. Everybody please read and
tell me about things you think should be added to the FAQ! Submissions are
preferred but if you just think I should have a section on a certain topic then
please point that out too. Even general layout opinions are welcome.
Many thanks in advance and I hope to maybe post this in the new year after
some cleaning up based on responses during the Christmas - New Year period.
A happy and safe Christmas and holiday to all!
regards, Greg
--------------------------------Begin draft FAQ-----------------------------
DGD FAQ
-------
Contents
--------
1. Preface
2. Introduction to DGD
3. Getting and Compiling DGD
4. DGD Mudlibs
5. Miscellaneous Topics
Section 1. Preface.
What this document is
---------------------
This FAQ is an attempt to answer some of the more common questions concerning
DGD. It was written in response to a perceived lack of general information
about DGD.
What this document isn't
------------------------
This document isn't an FAQ on LPMuds in general. George Reese produces an
LPMud FAQ which is posted to rec.games.mud.lp and rec.games.mud.announce on
a regular basis. Nor is it an FAQ about Muds in general. Jennifer Smith
posts a Mud FAQ to rec.games.mud.announce regularly. If you are seeking
information on Muds in general, or LPMuds in particular, I refer you to
these documents.
Section 2. Introduction to DGD.
What is DGD?
------------
DGD is an LPMud driver. In brief, this means that it provides facilities
that allow people to execute LPC code, much in the same way that a Java
virtual machine provides facilities for the execution of Java. DGD also
provides people with the ability to connect to it, most often to some sort
of virtual environment built with objects written in LPC.
What does DGD stand for?
------------------------
DGD stands for Dworkin's Generic Driver, being named after its author and
developer -- Dworkin (Felix Croes). This originally was Dworkin's Game
Driver but was changed at some stage.
How does DGD differ from other LPMud drivers?
---------------------------------------------
DGD differs firstly in that it wasn't derived from a version of Lars
Pensj|'s original LPMud driver. It is a complete rewrite of the driver by
Dworkin from the ground up. In this way it has managed to get rid of a lot
of "baggage" and legacy code which other LPMud drivers still possess to
some degree.
Another important difference is that DGD is by default set up to be
disk based rather than memory based as other drivers. This means you can
load a huge number of LPC objects without DGD taking up a lot of memory.
What can I do with DGD?
-----------------------
Pretty much anything. The most common application for DGD is still running
muds, but there is no reason why it couldn't be used (with appropriate LPC
objects) as a httpd for example. DGD itself contains nothing specific to
any application, only certain kernel functions (kfuns) which Dworkin felt
necessary to LPC object coding, compiling and management, and multiple
connections.
To be more specific, DGD is written with a minimalistic philosophy and
provides no mud or game specific code such as other LPMud drivers provide by
default.
Section 3. Getting and Compiling DGD.
Where can I get DGD from?
-------------------------
The primary distribution site for DGD is ftp.imaginary.com. DGD can be found on
this site by following the URL ftp://ftp.imaginary.com/pub/LPC/servers/DGD.
The current version of DGD in the stable development branch stands at 1.1p5.
Experimental/developmental releases can be gotten from dworkin.simplex.nl
in the pub/dgd/experimental directory. These releases are not guaranteed
to be stable but contain developmental code which will eventually become
DGD 1.2.
The earlier DGD distribution site (which still contains a reasonably up to
date dgd archive is at ftp://ftp.lysator.liu.se/pub/lpmud/drivers/dgd/.
In addition to what you will find at the imaginary site you can find a
some LPC packages for DGD in the lpc directory.
What platforms/operating systems is DGD available for?
------------------------------------------------------
DGD is available for Unix-like operating systems on just about any platform
and for Windows 95/NT (PCs), MacOS (Macs), Amigas and Ataris. You will
find the Unix distribution in the top directory of the distribution site as
dgd-1.1.tar.gz (patches up to 1.1p5 are available in the patches
directory). Binaries for Windows are available in the pc directory in zip
format and for the Mac in the mac directory as binhex'ed stuffit archives.
The distributions for the Amiga and Atari are in the amiga and atari
directories and are in lha and zoo archive formats respectively.
Compiling DGD
-------------
For this task you will need a C compiler, the gunzip/gzip program, the tar
program and the patch program (should you wish to install the patches --
and you really do). These are standard on most Unix-like systems. You
will also need to select the appropriate HOST Makefile -- see doc/Platforms
for more information on selecting the appropriate HOST setting for your
machine.
Packages for DGD
----------------
As has been mentioned before DGD is built with a minimalistic philosophy.
This has resulted in a number of people issuing "packages" for DGD. The
general idea behind most of these is to extend the functionality of DGD in
some way that is of use to the author (and hopefully others) but that isn't
essential. Currently the following packages are available (in the pkg
directory unless otherwise specified) for the stable branch of DGD
development. These packages must all be installed prior to compilation.
They are all written for DGD 1.1 unless otherwise specified.
alarms Replaces the call_out related kfuns with kfuns that provide
fraction (1/10th) of a second alarms and which are
repeatable.
comment Allows LPC coders to use C++ style // comments.
ctors Provides LPC objects with constructors/destructors.
str2val Converts any variable to and from the string format used
in save files produced by save_object.
strftime Functionality as per the C strftime for formatting dates
and times is provided by this package.
wildmat A subset of regexp string pattern matching functionality
is provided by this package.
These packages were all written by Th. Lockert of SigmaSoft.
net-10 Often known as the networking kfuns this package contains
kfuns which allow DGD to open arbitrary numbers of telnet,
tcp or udp ports.
precomp-3 This package makes it easier to compile your LPC objects
into C by keeping track of inherited programs for objects
you wish to compile this way. It is only available for
Unix-like operating systems at the moment.
These packages were written by Richard Braakman and the net-10 package is
currently maintained by Erwin Harte.
95-api Adds 4 kfuns to dgd which make use of the win32 API and thus
are specifically for Win95 / WinNT.
NT-api Adds an extra 2 kfuns on top of the 95-api package which makes
specific use of the NT API. This package is specifically for
WinNT.
ansi By default DGD filters out the escape code of the so-called
ANSI colour codes and the VT100 terminal codes. This
package provides a patch which allows these codes to be
input and output successfully.
These packages were all written by Wim van der Vegt
rusage Borrows the rusage efun code from the 3.2 LPMud (Amylaar)
driver and adds it as a kfun. It uses the getrusage(2)
system call.
There is no author attribution attached to this package.
rgx Full regular expression string pattern matching facilities
are provided by this package. It was written for DGD 1.0.9
and uses the GNU regex library.
This package was written by Robert Leslie.
mdbm This package provides a kfun interface for manipulation of
ndbm/gdbm databases.
regex Full regular expression string pattern matching facilities
are provided by this package in a somewhat different
fashion than that used by the rgx package.
object_info Provides kfuns which give you information about inherited
programs, functions and global variables in an LPC object.
These packages were written by Greg Lewis and are available from his LPMud
related web page at http://www.enol.com/~asmith/drf/
Only the net package is currently being supported for the experimental
development line.
If you wish to use Unix-only package on a Win95/NT box I suggest looking
over the gnuwin32 stuff at http://www.cygnus.com/misc/gnu-win32/.
Alternatively, if you wish to use a win32-only package on a (PC-based) Unix
box then look at http://www.winehq.com (specifically, details on libwine,
not the wine program itself).
Section 4. DGD Mudlibs.
What mudlibs are available for DGD?
-----------------------------------
There are currently 4 mudlibs with publically available DGD versions.
Kernel mudlib This is the minimal kernel mudlib written by
Dworkin that is released with DGD. It provides
a foundation which gives developers a working
environment around which a fully featured mudlib
could be developed.
2.4.5 The venerable 2.4.5 mudlib was originally written
for the 2.4.5 LPMud driver. Unfortunately its LPC
is quite dated both in design and implementation.
It is the only choice available, however, for
people who wish to open a playable mud straight
away it is their only choice.
Melville This was a minimalistic mudlib written for DGD
1.0.9. It would need some minor porting to run
under DGD 1.1 and is not widely regarded as good
choice to base your mudlib on. This mudlib was
written by Steven Schmidt (Mobydick).
LPMOO LPMOO is quite a different mudlib in that it
completely masks LPC from users and developers and
instead simulates the LambdaMOO driver complete
with its MOO language. It was originally written
for DGD 1.0.9 by Robert Leslie.
Whats a kernel function (kfun)?
-------------------------------
A kernel function is a function provided by DGD itself. Documentation for
these functions can be found in the doc/kfun directory of the DGD distribution.
These functions are available to every object (unless redefined by an inherited
object -- the auto object often does redefine them).
Whats the auto object?
----------------------
The auto object is one of two special objects in DGD. It is (automatically)
inherited by every other object except the driver object. In this way, any
function in the auto object that is declared static will act much the same as
a kfun. Functions like this are alternatively called efuns (since they act
as efuns do in other LPMud drivers) or afuns.
Whats the driver object?
------------------------
The driver object is the interface between DGD and the mudlib. It is loaded
before any other object and is the only object not to inherit the auto object.
Various "applies" (see the LPMud FAQ -- these are functions called by DGD) are
called in the driver object by DGD in response to various events and are
expected to perform various tasks.
How do I do multiple inheritance with DGD?
------------------------------------------
Multiple inheritance in DGD is different from other LPMud drivers. To inherit
multiple files one must label the inherited files (other LPMud drivers
automatically label the inherited objects with the file name -- which is a
problem if there are two files of the same name in different directories
which you wish to inherit). The best way to illustrate the DGD method is via
an example. In this example two objects A and B are inherited and given
the labels foo and bar. These labels are used to call the inherited create
functions.
inherit foo "A";
inherit bar "B";
void
create() {
foo::create();
bar::create();
}
Are there any function pointer/lambda closure equivalents?
---------------------------------------------------------
No, but you can simulate this sort of functionality with LPC should you
require it. Indeed, Dworkin at one point wrote a simulation for the lambda
closures of the 3.2 LPMud (Amylaar) driver.
Can I compile my LPC to C?
--------------------------
Yes, you can. This must be done at the time the driver is compiled though,
one cannot do it on the fly. Look in the src/lpc for more information
concerning this. The 2.4.5 mudlib simulation contains a good example of
how to do this.
Section 5. Miscellaneous Topics.
Can I use DGD commercially?
---------------------------
Yes you can, but to do so you will need to buy a license from ichat, who can
be found at http://www.ichat.com. For more information see the Copyright
file provided with DGD.
Getting help with DGD
---------------------
There are a number of ports of call for help with DGD. A DGD mailing list
is maintained by the Centre for Imaginary Environments (CIE) and can be
joined from the web page at http://list.imaginary.com/mailman/listinfo/dgd/.
There is also a DGD newsgroup on the Idea Exchange (idea.imaginary.com 7890)
named drivers.dgd. The newsgroup rec.games.mud.lp is also appropriate for
postings about DGD.
--
Greg Lewis Applied Maths Department
Email : glewis at maths.adelaide.edu.au University of Adelaide
--
If A = B and B = C, then A = C, except where void or prohibited by law.
-- Roy Santoro
List config page: http://list.imaginary.com/mailman/listinfo/dgd
More information about the DGD
mailing list