[DGD] Revised FAQ
Gregory D Lewis
glewis at maths.adelaide.edu.au
Mon Jan 5 01:45:56 CET 1998
Hi all,
Here is the revised FAQ. Please note that I haven't done the HTML version yet,
so you won't find it at the URL I mention. That'll be done sometime this week.
Please read and comment if you have time, I'll post it to the appropriate
newsgroups in a week with any corrections.
regards, Greg
DGD FAQ
=======
Section 0. Contents
--------------------
1. Preface
1.1 What this document is
1.2 What this document isn't
2. Introduction to DGD
2.1 What is DGD?
2.2 What does DGD stand for?
2.3 How does DGD differ from other LPC drivers?
2.4 What can I do with DGD?
3. Getting and Compiling DGD
3.1 Where can I get DGD from?
3.2 What platforms/operating systems is DGD available for?
3.3 Compiling DGD
3.4 Driver/kfun packages for DGD
4. DGD Mudlibs
4.1 What mudlibs are available for DGD?
4.2 Whats a kernel function (kfun)?
4.3 Whats the auto object?
4.4 Whats the driver object?
4.5 How do I do multiple inheritance with DGD?
4.6 Are there any function pointer/lambda closure equivalents?
4.7 Can I compile my LPC to C?
5. Miscellaneous Topics
5.1 Can I use DGD commercially?
5.2 Getting help with DGD
6. Credits
Section 1. Preface.
--------------------
1.1 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.
It will be posted on a regular basis to the USENET newsgroups rec.games.mud.lp
and rec.games.mud.announce. Also, it is available from the URL
http://www.enol.com/~asmith/drf/dgd/faq.html.
1.2 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. I suggest looking at the Center for Imaginary Environments
(CIE) web pages starting in http://www.imaginary.com/LPMUD (the FAQ is at
http://www.imaginary.com/LPMUD/lpmud_faq.html).
Nor is it an FAQ about Muds in general. Jennifer Smith posts a series of
Mud FAQs to rec.games.mud.announce regularly. These can be retrieved from
ftp://muds.okstate.edu/pub/jds/misc/mud-faq/ (part1, part2 and part3).
If you are seeking information on Muds in general, or LPMuds in particular,
I refer you to these documents.
Section 2. Introduction to DGD.
--------------------------------
2.1 What is DGD?
-----------------
DGD is an LPC 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.
2.2 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 the suggestion of Robert Leslie, author of LPMOO).
2.3 How does DGD differ from other LPC 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 LPC drivers still possess to
some degree.
Another important difference is that DGD 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.
DGD also possesses (at driver level) the ability to perform a state dump,
that is, to "dump" the state of all loaded objects to a file and restart
the driver with them exactly as they were (with the exception of active
TCP connections being closed during this process).
2.4 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.
This minimalistic philosophy and lack of application specific code allow
you to create any look and feel you choose through building around basics
written into the auto and driver objects (see 4.3 and 4.4 respectively).
A classic example of making DGD appear to be something other than an LPMud
using this methodology is the LPMOO simulation by Robert Leslie (4.1).
Section 3. Getting and Compiling DGD.
--------------------------------------
3.1 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 current release in this development branch is 1.1.30. In
terms of bug fixes the following table indicates the correspondence between
the experimental and stable branches.
1.1p1 <-> 1.1.8
1.1p2 <-> 1.1.9
1.1p3 <-> 1.1.13
1.1p4 <-> 1.1.17
1.1p5 <-> 1.1.28
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
some LPC packages for DGD in the lpc directory.
3.2 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.
Dworkin expects to release a version of the 1.1 branch for BeOS in January.
A list of the current versions available for each OS is:
Unix dgd-1.1.tar.gz
patches/1.1p*.gz (* = 1 through 5)
Win32 pc/dgd-1.1p5.zip
Mac mac/dgd-1.1p5.sit.hqx
Amiga amiga/dgdAmiga-1_0_9.lha
Atari atari/dgd10a71.zoo
3.3 Compiling DGD
------------------
For this task you will need a C compiler, the gunzip/gzip program, the tar
program, the make 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. If you do not have one or more of these tools, they are
available for almost any flavour of Unix from ftp://prep.ai.mit.edu/pub/gnu
or any of the GNU mirror sites.
DGD is known to compile on Windows 95/NT using MSVC 5. One suspects that it
would also compile with the gcc version from the gnuwin32 collection (see the
note at the end of 3.4) and with the Borland compiler as well, although I
have no reports one way or the other on this.
3.4 Driver/kfun 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 The network package extends the IP networking features,
allowing you to open/close TCP ports, start outgoing TCP
connections and receive and send UDP packets."
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 Windows 95/NT.
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
Windows NT.
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 a Unix-only package on a Windows 95/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.
------------------------
4.1 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.
Melville This was a minimalistic mudlib written for DGD
1.0.8. It would need some minor porting to run
under DGD 1.1 and is not widely regarded as a 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.
4.2 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).
4.3 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.
4.4 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
itself, not another LPC object) are called in the driver object by DGD in
response to various events and are expected to perform various tasks such
as dealing with compile or runtime errors, calling, compiling and inheriting
objects, etc.
4.5 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 program "A" and label it as foo.
* Inherit program "B" and label it as bar.
*/
inherit foo "A";
inherit bar "B";
void
create() {
/*
* Call the create functions in programs "A" and "B" via their inheritance
* labels.
*/
foo::create();
bar::create();
}
4.6 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.
4.7 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 (almost). 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.
To perform this operation almost on the fly, compile the new version of the
driver with the C version of the new LPC objects included then perform a
state dump of the game before shutting down and restarting with the new driver.
Section 5. Miscellaneous Topics.
---------------------------------
5.1 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.
5.2 Getting help with DGD
--------------------------
There are a number of ports of call for help with DGD. A DGD mailing list
is maintained by 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 USENET newsgroup rec.games.mud.lp is also appropriate
for postings about DGD.
Section 6. Credits
-------------------
First and foremost thanks must go to Felix Croes (Dworkin) for creating DGD!
A number of people have volunteered information and suggestions for this FAQ.
Thank you to you all! Special thanks to Felix Croes, Erwin Harte and
Wim van der Vegt for providing additional information on aspects of DGD.
This FAQ was written by Greg Lewis and is Copyright (C) 1997-1998. You may
redistribute it as you please in electronic or hard copy form as long as these
credits are left intact and any changes you make are marked as such.
Please save bandwidth and reader annoyance by not posting it to USENET
newsgroups that it is already regularly sent to. Instead point people to
the URL mentioned in 1.1 :).
--
Greg Lewis Applied Maths Department
Email : glewis at maths.adelaide.edu.au University of Adelaide
--
Anybody can win, unless there happens to be a second entry.
List config page: http://list.imaginary.com/mailman/listinfo/dgd
More information about the DGD
mailing list