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.
@@INCLUDE tools@@
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:
@@INCLUDE patching@@
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'"
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.
@@INCLUDE will_shattuck@@
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.
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.
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?