Phantasmal MUD Lib for DGD

Phantasmal Site > DGD > Getting DGD > Customizing DGD

Compiling and Customizing Your Copy of DGD

Tools for working on DGD

Tools on Unix

Chances are you've already got what you need. You'll need a good C compiler. GCC is perfect. You'll need a text editor that respects Unix-style line breaks, like emacs, vi, or pretty much any other normal Unix editor.

Tools on Windows

  • For utilities like grep and patch the Cygnus Cygwin tools are excellent. You'll definitely want them if you're using the experimental branch of DGD even if you compile with Visual C++ or another non-GNU compiler. They also come with a Windows version of GCC, which may be worth considering. If you compile with Cygwin's GCC, remember to use 'DMAKE=gmake' or whatever you choose to call CygWin make. Basically, you'll need to let DGD's makefile know what tools to use if any of them don't have the standard names.
  • Textpad is supposed to be a fine editor, and it has the advantage that it'll handle DGD and unix-style line breaks correctly. If you use J. Random Editor on Windows you'll probably find that the file just doesn't compile. Textpad fixes that problem. You can also use the Crimson Editor, which autodetects the kind of line breaks that a given document uses.
  • If you're using CVS to get really experimental versions of software you use with DGD (for instance, the Phantasmal MUDLib), you should also be aware that the native Win32 version of CVS may cause problems with line endings (newlines). If you have troubles with the CVS versions of the software but not the regular distributions, consider using the Cygwin CVS client instead of the Win32 native client.
  • In addition, for TortoiseCVS, there's a SourceForge tutorial on how to set it up for SourceForge projects.
(About Tools, from a message by Par Winzell:)

As you seem to have already figured out, there's two substantially 
different ways to compile DGD for Windows; one's native to Windows, uses 
the Windows API, and requires Visual C++... and one compiles DGD as a 
Unix application, on top of Cygwin. Presuming you can't find somebody to 
compile DGD+ANSI for you using Visual C++ (I loathe the Microsoft IDE's 
and try hard to keep them away from my computer), by far your best bet 
is to use Cygwin. So...

... first of all, DGD compiles cleanly under Cygwin and runs without 
trouble. It does need to use the 'SYSV' Makefile in dgd/src/host rather 
than the 'BSD' one. I understand you were frustated with Cygwin by the 
time you quit, but I suggest you persist. If things continue to go 
wrong, please let us know what 'missing files' actually means. 
Meanwhile, these commands should fully compile DGD under Cygwin, if you 
have a sufficient installation:

   *  wget --passive-ftp ftp://ftp.dworkin.nl/pub/dgd/dgd-1.2p4.tar.gz
   *  tar -xzvf dgd-1.2p4.tar.gz
   *  cd dgd/src
   *  cp -p host/Makefile.sysv host/Makefile
   *  make install

If all goes well, you will have a binary in dgd/bin/driver. The Cygwin 
version, not being a native Windows application, is also not a GUI one; 
you'd do

   * cd ..
   * bin/driver mud.dgd

after modifying mud.dgd with the correct absolute path(s).

Finally, please don't worry overly much about installing Cygwin on your 
machine. It's not going to do any harm and I don't think it gets into 
the guts of your installation. You don't even really need to uninstall 
it if you get tired of it; delete i.e. C:\Cygwin and remove the links 
from the start menu, and I believe it's pretty much gone. You might even 
find that you get used to having it around. As tools go for making 
Windows sane, it's unparallelled in competence.

And please dump Wordpad!! :)

Making an Experimental Version of DGD

To patch up to an experimental version of DGD, say one of the 1.2.X series, first you'll need to get DGD . The latest version is definitely best if you're going to patch up to an experimental version, unless you need some very specific older version like 1.1.96. You'll also need to download the whole set of experimental patches from the version of the code you have up to the version you want. Then, if you've got Unix and patch, or if you've got the Cygnus Cygwin tools under Windows (they also supply the patch utility) you'll want to type in a whole lot of lines like the ones below. When you type them you should be in the same directory where you first untarred or unzipped the DGD source:

patch -p 0 < 1.2-1.2.1
patch -p 0 < 1.2.1-1.2.2
patch -p 0 < 1.2.2-1.2.3
patch -p 0 < 1.2.3-1.2.4
patch -p 0 < 1.2.4-1.2.5
      [...]
patch -p 0 < 1.2.21-1.2.22

You'll need all those files on the right, the ones with names like "1.2.1-1.2.2". Be sure to unzip or ungzip them if they're compressed when you download them. Netscape may do this for you -- that's what's happened if you download 1.2.1-1.2.2.gz and Netscape offers to save it without the ".gz". Each one takes you up one experimental release, so to patch up to 1.2.22 above took 22 patches from 1.2. And this is all before you get around to building it. Be sure to play with a stable version before you take the plunge the first time on the experimental one.

Note that you'll need to do all of this patching before you build DGD to be sure everything works. On the bright side, under Unix you may be able to avoid typing all those lines -- try just typing "patch -p 0 < 1.2.*" in a directory containing the unzipped patchfiles. If you try it and it starts giving you rejected patches then something's wrong. If that happens, you should go back to trying it the long (but certain) way.

And a final note: if you're the sort that grabs the experimental version, you may be rebuilding from nothing, or you may be altering the lex/yacc files for some reason. If you're using a nonstandard version of Yacc (for instance bison) you can type "YACC=myyacc" after the make command and it'll use the appropriate version. For bison, you'll need to pass a command-line flag to make it output the appropriate filename. For me, that command line winds up being "make YACC='bison -o y.tab.c'"

Making an Experimental Version of DGD with Cygwin

This is Will Shattuck's set of instructions for compiling DGD version 1.2.47 under Cygwin. It should be pretty adaptable for other DGD versions.

download dgd-1.2.tar.gz
untar dgd-1.2.tar.gz
download the experimental patches from ftp.dworkin.nl and save them into a
dir called patches in the same root as the untar'd dgd*.gz file
      eg: ~/dgd and ~/patches in your home directory
use patchit script to patch dgd
cd dgd/src
cp host/pc/local.c host/lrand48.c
cp host/Makefile.sysv host/Makefile
vim host/Makefile
      change the host to LINUX
vim src/Makefile
      change the host to LINUX
make
make install

============================

The patchit script was just a file that I created from doing "ls -l
patches > patches.txt" and then editing it within Excel and a text editor
with a Find and Replace feature

== Begin patchit script ==

patch -p 0 < patches/1.2-1.2.1
patch -p 0 < patches/1.2.1-1.2.2
patch -p 0 < patches/1.2.2-1.2.3
patch -p 0 < patches/1.2.3-1.2.4
patch -p 0 < patches/1.2.4-1.2.5
patch -p 0 < patches/1.2.5-1.2.6
patch -p 0 < patches/1.2.6-1.2.7
patch -p 0 < patches/1.2.7-1.2.8
patch -p 0 < patches/1.2.8-1.2.9
patch -p 0 < patches/1.2.9-1.2.10
patch -p 0 < patches/1.2.10-1.2.11
patch -p 0 < patches/1.2.11-1.2.12
patch -p 0 < patches/1.2.12-1.2.13
patch -p 0 < patches/1.2.13-1.2.14
patch -p 0 < patches/1.2.14-1.2.15
patch -p 0 < patches/1.2.15-1.2.16
patch -p 0 < patches/1.2.16-1.2.17
patch -p 0 < patches/1.2.17-1.2.18
patch -p 0 < patches/1.2.18-1.2.19
patch -p 0 < patches/1.2.19-1.2.20
patch -p 0 < patches/1.2.20-1.2.21
patch -p 0 < patches/1.2.21-1.2.22
patch -p 0 < patches/1.2.22-1.2.23
patch -p 0 < patches/1.2.23-1.2.24
patch -p 0 < patches/1.2.24-1.2.25
patch -p 0 < patches/1.2.25-1.2.26
patch -p 0 < patches/1.2.26-1.2.27
patch -p 0 < patches/1.2.27-1.2.28
patch -p 0 < patches/1.2.28-1.2.29
patch -p 0 < patches/1.2.29-1.2.30
patch -p 0 < patches/1.2.30-1.2.31
patch -p 0 < patches/1.2.31-1.2.32
patch -p 0 < patches/1.2.32-1.2.33
patch -p 0 < patches/1.2.33-1.2.34
patch -p 0 < patches/1.2.34-1.2.35
patch -p 0 < patches/1.2.35-1.2.36
patch -p 0 < patches/1.2.36-1.2.37
patch -p 0 < patches/1.2.37-1.2.38
patch -p 0 < patches/1.2.38-1.2.39
patch -p 0 < patches/1.2.39-1.2.40
patch -p 0 < patches/1.2.40-1.2.41
patch -p 0 < patches/1.2.41-1.2.42
patch -p 0 < patches/1.2.42-1.2.43
patch -p 0 < patches/1.2.43-1.2.44
patch -p 0 < patches/1.2.44-1.2.45
patch -p 0 < patches/1.2.45-1.2.46
echo This is the last patch
patch -p 0 < patches/1.2.46-1.2.47

== End patchit script ==

How do I set up DGD to work with ANSI color?

First, you should get and configure DGD without ANSI color. Make sure you have DGD working with your other options before worrying about color. One option at a time is always your best bet.

Once you have DGD working with all other patches you want to use (including the net package if you're planning to use it) you'll need to get and install the ANSI Color package. Note that the ANSI color package isn't guaranteed to work with the net package -- keep reading anyway. The 'patch' utility will do your dirty work for you if you can find an appropriate ANSI package for your DGD version. Again, if you have the net package installed (or certain other nonstandard patches) then you'll have to hand-patch it. To hand-patch, you'll need to look for lines like this:

         } else if ((*p & 0x7f) < ' ' && *p != HT && *p != BEL && *p != BS) {

There'll be one or more in .../src/comm.c, so start looking there. You'll need to change the "0x7f" in the line above to 0xff to let any high-ASCII characters through, or change the line in some other way to let only specific characters through. Once you do that, all should be smooth sailing. Incidentally, the there may be problems if you let all high-ASCII characters through, which is why DGD doesn't do it by default. You may want to be more selective and just let the ones you care about through. The best option is usually just to install the ANSI color package rather than mucking around in the source unless you already know what you're doing -- it'll let only the escape character (\033) through, which is all you need for ANSI color.

To enable non-English character codes you'll need to hand-patch. You can either do the 0xff hack above or specifically let through the foreign character codes you plan to allow. You'll need to find out their ASCII values or ranges and add them to the if statement.

If you've got the net package installed, you'll need to search comm.net.c for the same line and replace it where it occurs in that file as well.

As of DGD 1.2.41, there's another possibility if you're willing to play with telnet codes, or if you don't care about them. Since you can now have as many telnet or binary ports as you feel like, you could just make your primary MUD port a binary port, it'll let all high-ASCII characters through, and you're still compatible with stock DGD rather than requiring patches.

Compiling DGD with a larger maximum string size

By default the largest allowable string in DGD is 64kb. If you need a larger string size you can increase it by recompiling the driver with a couple of modifications.

In dgd/src/config.h, change the type of ssizet to Uint, #define SSIZET_MAX as UINT_MAX, and #define MAX_STRLEN as what you want the maximum string length to be.

Old state dump files with a smaller ssizet type can be restored safely.

Compiling DGD with a larger maximum number of objects

Plain vanilla DGD has a maximum of 65536 objects at once. If you need more objects than that, you'll need to change a couple of things in the driver source.

In dgd/src/config.h, you'll need "typedef unsigned int uindex;" and "# define UINDEX_MAX UINT_MAX" in place of the previous definitions of uindex and UINDEX_MAX. This type and constant define how DGD handles objects, so now you should be good up to potentially four billion objects. If you need more than that, you should probably ask the mailing list. Alternatively, you might notice that these are regular heavyweight objects -- LWOs don't count. So if you're using a late-vintage 1.2.XX DGD and are willing to have the swapping behavior do some funky things, you can seriously cut down the number of objects by using LWOs.

If you fix this and still can't get enough objects, you should check your .dgd file -- for instance, "mud.dgd" for the Kernel MUDLib which has all your configuration information. You did increase the maximum number of objects to the new limit you want, yes?

Copyright (C) 2010 Raymond Jennings

This website is released to the public under the terms of the GNU Free Documentation License, Version 1.3 or later