This is part 4 in a 4 part series of FAQs.
Disclaimer: This document may be seen to be biased towards TinyMUDs. This is because the original author of this document mainly plays those types of servers, not because she thinks they are inherently better or worse than other types of servers. However, this document is meant to be generalized and useful for all MUDdom, and so corrections and contributions are always welcome. The new maintainers will be gradually modifying the FAQ to be geared towards all of the various server types.
Table of Contents
MUD Servers at a Glance
Please see section #3 of the MUD FAQ “Clients and Servers”, a basic overview is presented on mud servers in general.
Servers at a glance will provide more detailed information about the various mud server types that are available. For each server type our team will provide history, feature lists, resource locations, and technical data. Not all of the server types will be included immediately, however, as new sections are created they will be added.
This section will describe the mud server types that we currently have data for.
CircleMUD: Contributor: Daniel A. Koepke (firstname.lastname@example.org) Server Family: DikuMud Authors: Jeremy Elson, et al. Language: C Current version: 3.0 beta patchlevel 16 Status: Active development.
Primary Website: http://www.circlemud.org/
Primary FTP site: ftp://ftp.circlemud.org/
Technical Details: Operating systems: UNIX, Linux, Windows 95/98/NT, Mac, VMS, Amiga, OS/2 Memory usage: Approxiamately 2MB stock w/ no players Disk usage: Approxiamately 7MB stock w/ no players Code size: 36000 lines of C code.
History (summarized from the CircleMUD homepage):
CircleMUD began as an actual, running MUD administrated by Jeremy Elson on a system located at John Hopkins University. The name of the machine, a DECstation, was “circle” (i.e., its address was circle.cs.jhu.edu). CircleMUD was fairly popular during its run, but on August 26, 1992 Jeremy, increasing dismayed over the politicking involved in running a MUD, decided to shutdown the MUD and accept a coding position at JediMUD.
In May of 1993, Jeremy decided to dust off the CircleMUD source code and, after some work, release it. A summer’s worth of coding produced CircleMUD 2.0 on July 16, 1993. There would be five more releases in the 2.x before the first release of 3.0 (bpl4) in September of 1994. Since then, Jeremy has built a small core of developers that do the official work on CircleMUD. The latest release of CircleMUD is bpl 16, which was released in September of 1999.
CircleMUD is intended to be a clean, stable base from which others can build their ideal MUDs off of. As such, it does not include many of the features that you’ll find stock in Merc and Merc-derived MUDs. In essence, CircleMUD is a cleaner, more efficient, and more stable DikuMud. Current development efforts emphasize code and low-level feature maturity, rather than game mechanics, so a stock CircleMUD is nothing to get excited about.
CircleMUD is currently in a (sort of) feature-freeze while it is debugged. However, there is an active community of MUD administrators and coders that share their ideas and code with the rest of the CircleMUD community. Beginning coders should find the CircleMUD code to be very friendly.
Crimson2: Contributor: Ryan “Cryogen” Haksi (Cryogen@infoserve.net) Server Family: 100% custom, DikuMud style interface Authors: Ryan “Cryogen” Haksi (email@example.com) Cam “Corbin” Lesiuk (firstname.lastname@example.org) Language: C Current version: 1.0 Status: Version 1.0 released Feb, 2000
Primary Website: http://phantom.me.uvic.ca/mud/index.html
Primary FTP site: ftp://phantom.me.uvic.ca/pub/Crimson2799
Technical Details: Operating systems: All UNIX (good portability). Win95/NT/2000 Memory usage: About 3.2 megabytes with stock areas Disk usage: About 25 megabytes after compilation with no player files Code size: 51,919 lines, 1,727,144 bytes (1.7 Megs) lines of C code (server only) Code style: Strict package prefixing naming scheme. Strict variable/type/constant naming. quasi-OO style data struct hierarchy (With runtime typing). Areas: A reasonably complete selection of areas is included. I’ve not actually counted them but there’s a fair number (10-15), and some are veryand some are very large. All are story/quest driven.
After running a diku gamma based mud (Crimson1) for 3 years, I finally decided to bite the bullet and write a new mud from scratch to get away from limitations imposed by the design of diku muds. Also I had vague plans of selling it as a pay-mud once it was finished, which of course wasnt possible with the diku license.
After a year or so of development I managed to lean on a friend of mine (Corbin) and got him involved in mud coding. 4 years of development later on a “one year project” we’ve decided to turn the project over to fresh blood. Most of the areas and all of the coding on the mud have been done by Corbin and myself and frankly we’re a little burned out.
- Embedded byte-code compiler/interpreter/diassembler/decompiler for the C4 scripting language. - Security system so that the scripting lanaguage cannot be used to cheat or bring down the system. - Command line text based OLC (Crimson1 style) - Integral Win16/32 GUI online OLC client. (Mole=Mud Online Editing client) - src is included. - All objects in the game can have arbitrary properties and scripts attached to them. Scripts are event-driven. Scripts can be changed without rebooting the mud of course. - Online editing of boards, help entries, reset commands, mobs, world files, area settings, and objects. - Integral ANSI color strings, user-configurable. - Offline grid-based .wld file layout tool. With it you can create the layouts for complete areas in minutes.(src included) - 100% from scratch code base, strict package prefixing naming scheme. Integral ansi-colour (lots of it, user configurable), built in Hint system to help new players. - standard diku-mud command line interface plus a few extras (ie command line history, user defined aliases, an editor that supports search and replace among other things) - All data files are text based to help with easy maintenance. All area files are diku compatible, adding areas is particularly easy, the server will even renumber them on the fly when it loads them (if its necessary) - Since the area files are standard diku format you can use your favorite dikumud area editing tool. - Complete documentation on C4 scripting language. - Unique race/class system, every combination is different. Every class gets psi powers of some sort.
Original Crimson2799AD mud homepage
Dikumud: Contributor: Michael Seifert (Seifert@Dikumud.com), Hans-Henrik Staerfeldt (God@Dikumud.com) Server Family: DikuMud Authors: Michael Seifert, Hans-Henrik Staerfeldt, Sebastian Hammer, Tom Madsen, Katja Nyboe Language: C Current version: The last publicly available release was “Dikumud Alfa” Released approximately June 1991. Please note, that the name “Alfa” does not refer to the concept of “Alpha” releases, it was merely the name of the computer on which it was developed. Status: Initial version (Gamma) released June 1990. No active development.
Primary WEB site: http://www.dikumud.com/
Operating systems: Ported to most UNIX systems. Derivatives: All DIKU derivatives.
DIKU MUD was written by the authors as a hobby project during their first years at Computer Science at Copenhagen University (called DIKU). DIKU MUD was written with the intention of making an efficient, small codebase with game focus on playability. The game was build for fast expandability of the online world.
Enjoyable mudding and a great code base for producing a variety of derivatives.
* Shops that can sell and buy items. * Pets/ Pet shops. * Rent rooms for saving your character+equipment at the server. * 4 basic classes: Mage, Fighter, Cleric, Thief. * Guilds for classes. * Titles are earned as you advance levels. * Player vs player combat. * Compressed time: 30 minutes playing time is 24H in the game. * Spells with timed effects. * Cursed/blessed items with effects. * Item restrictions (alignment, etc.) * Numbering of items (get 3.sword) * Varied ways to use equipment. (rings, hats cloaks, boots etc..) * Multiple area types. (mountains, cities etc.) * In-game weather. (based on barometer model) * Day cycle (night, morning, day, evening). * Alternative calendar. * Regular resetting of in-game areas. (no global reboot needed) * Automated handling of fight/ defense (reaction time rarely a factor) * Dynamic, changing alignments. * Group and follow/ grouped combat. * Bulletin boards. * Online help file. * Communication interface for easy expansion ('act'). * Expandable system for social actions. (sneeze, coung etc..) * Programmable computer controlled characters.
Envy: Contributor: Erwin Andreasen (email@example.com), Michael Quan (firstname.lastname@example.org) Server Family: DikuMud Authors: Michael “Kahn” Quan and Mitchell “Hatchet” Tse (2.x), David “Thelonius” Love, Guilherme “Kith” Arnold (1.x) Language: C Current version: 2.2 Status: Version 2.2 released March 1997. No active development.
Primary Website: http://www.envy.com/
Primary FTP site: ftp://ftp.envy.com/
Technical Details: Operating systems: All UNIX (good portability). Macintosh in console (single user) mode Memory usage: About 5 megabytes with stock areas Disk usage: About 8 megabyte after compilation with no player files. Average player file is 10 kilobytes Code size: 46000 lines of C code.
Derivatives: Greed (aka UltraEnvy/HomeCooked Envy)
History (submitted by Michael Quan):
Envy derives from MERC almost by accident. After MERC dissolving and an absense from mudding, Michael Quan wanted to play again. A part of the original MERC team (Michael Quan and Mitchell Tse) continued the development.
1.x was developed with the idea less is better. David Love joined as part of the coding and design team. Guilherme Arnold and a select core of implementors guided the idea pool.
2.x had a 60% code rewrite over 1.x with features specific to the playing population of the mud. Included were also better object handling and system performance improvements. David Love and Guilherme Arnold left the team.
Under the design guidence of Michael Quan and in a departure from how muds are normally developed, the last major release of Envy included a significant portion of contributed code and input from the public rather than an active player base or coding and design team.
Envy fixed most of the bugs that plagued MERC 2.2. The mob programs as added in MERC 2.2 caused too many problems and were removed. Races for mobs and players were added. Better management of object and character extraction was added (“deleted” variable) which makes the MUD more stable. A better string manager, SSM was contributed by Melvin Smith of mud++.
Envy is a nice and clean codebase. There aren’t many features, so Envy makes it easier for an experienced programmer to customize it. Beginner programmers may miss some of the things implemented in more feature-full bases like Smaug.
In addition, some parts of the game engine was rewritten to improve code performance over Merc 2.2.
ILAB OLC for Envy 2.x
Merc: Contributor: Erwin Andreasen (email@example.com) Server Family: DikuMud Authors: Michael “Kahn” Quan, Michael “Furey” Chastain, Mitchell “Hatchet” Tse Language: C Current version: 2.2 Status: Version 2.2 released November 1993. No active development.
Primary FTP site: ftp://ftp.game.org/pub/mud/diku/merc/
Technical Details: Operating systems: All UNIX (good portability). DOS in console (single user) mode Average player file is 10 kilobytes Code size: About 30000 lines
Derivatives: Envy, ROM, Smaug, ACK, The Isles and all their derivatives
MERC derives from the original DikuMUD. The initial 1.0 version improved incrementally over Diku, but the 2.0 version introduced a total rewrite of the code and perhaps the biggest leap in code quality of all derivatives. Gone were limiting features of DikuMUD like binary files. Portability was also greatly improved. The code became much cleaner.
ASCII pfiles allow easier expansion of player fields: rather than the fixed-size binary format, you can add any new fields without having to convert the pfile. This also helped portability: you could move your MUD from one system to another by just recompiling the code. This feature now appears in just about every modern MUD.
MERC features level-based equipment, the stats of which are based on its level. This is a controversial feature, but it’s one way of keeping objects balanced.
Memory usage and speed were reduced compared to Diku, thanks to the complete rewrite.
Of the modern Diku derivatives, MERC is the oldest one and thus the one with least features. Since it is nearly 6 years old, it has also several bugs. If you are looking for a Diku-derived base which you plan to totally overhaul, MERC might be feasible choice but Envy might be better.
There is a “sands_bugfixed” variant of MERC 2.2 which has some of the MERC bugs fixed. However, the mobprograms of MERC 2.2 contain several bugs; you might want to find the fixed version made by Markuu “Newt” Nylander for ROM.
Additionally, there is now a BeOS port for Merc 2.2 which can be found at http://www.bebits.com/app/1092/.
PennMUSH: Contributor: Alan Schwartz (firstname.lastname@example.org) Server Family: TinyMUD Authors: Derived from Larry Foard’s TinyMUSH by Lydia “Amberyl” Leong now (since 1.6.0) maintained by Alan “Javelin” Schwartz, and currently developed by Javelin, T. Alexander “Talek” Popiel, and Thorvald “Trivian” Natvig, Shawn “Raevnos” Wagner, Luuk “Halatir” de Waard. Win32 development includes Nick Gammon. Mac port by Dan Williams. Language: C Current version: 1.7.2
Status: 1.7.2 (at patchlevel 33) is being maintained for bugfixing; 1.7.3 is in active development Primary Website: http://www.pennmush.org
Primary FTP site: ftp://ftp.pennmush.org
Technical Details: Operating systems: All UNIX (highly portable, includes configure script), Win32 (with cygwin tools or VC++, runs as a service on WinNT), Mac. Memory Usage: Varies with database size. 10Mb typical for 5k-8k objects. Disk Usage: Varies with database size. 5Mb typical for 5k-8k objects. Code size: 57000 lines of C code
Derivatives: No direct derivatives that are publicly available.
History (from the README file):
PennMUSH is a TinyMUD derivative, and one of the branches along the MUSH line. “Vanilla” TinyMUSH, which added the “v” registers and functions to the basic TinyMUD building commands, was written by Larry Foard. The code was later expanded by Jin, of MicroMUSH. In January of 1991, MicroMUSH changed its name to MicroMUSE, and the code there continued to develop under the MUSE name. At that same point in time, Moonchilde took the last public release of that code and began a series of improvements and extensions.
That code was released as PernMUSH, named for the MUSH that Moonchilde was running. The last released version of that code was version 1.15, at the end of November 1991. PernMUSH itself had switched over to TinyMUSH 2.0, which Moonchilde had co-written with Glenn Crocker (Wizard of TinyCWRU); there was no longer a reason for Moonchilde to maintain this code.
In January of 1992, Amberyl began working on the PernMUSH 1.15 code release, for TinyKrynn. She took over the code, which no one was supporting, and is continuing to work on extending this code, as well as improving its compatibility with TinyMUSH 2.0. She changed the name to PennMUSH (named for her school, the University of Pennsylvania), to avoid the confusion that resulted from PernMUSH actually running TinyMUSH 2.0.
In January of 1995, Amberyl passed on her mantle to Javelin (aka Paul@Dune, Alan Schwartz), who is now the maintainer of the primary public distribution in development. He released two patchlevels numbered “dune-1” and “dune-2” before releasing PennMUSH 1.50 pl11 and later distributions. The numbering scheme changed again with PennMUSH 1.6.0 (see CHANGES.OLD).
Gradually during the early part of 1995, Alan formed the PennMUSH development team with T. Alexander Popiel (Talek) and Ralph Melton. The development process became more formalized, with official patches, a dedicated bug reporting email address, and better tracking of outstanding issues and history.
In August of 1997, Ralph Melton left the PennMUSH development team, and Thorvald Natvig joined as a new member. Many thanks go to Ralph who contributed much time, code, and good cheer to PennMUSH.
Javelin, in conjunction with Talek (T. Alexander Popiel) and Thorvald Natvig, are the current PennMUSH development team.
Like all MUSH servers, PennMUSH by default allows any user to build rooms and objects, and provides a complete (if sometimes tortuous) internal scripting language (“MUSHcode”). MUSH servers do not include built-in combat systems as a rule.
Among MUSH servers, PennMUSH is usually distinguished from TinyMUSH as being memory-based: in PennMUSH, the entire database is loaded into memory, and a copy is dump onto disk periodically. In TinyMUSH, the database is kept largely on disk, and portions are loaded into memory (and cached) as needed. Typically, this means that you want to run PennMUSH when you have plenty of memory to spare, and TinyMUSH when memory is scarce but you have plenty of disk space (and fast disks). Actually, things are a bit more complicated on modern workstations, since parts of the PennMUSH process that aren’t being used will generally be paged out of memory to disk by the operating system. In some cases, this can be more efficient than having the MUSH server do the paging, but generally, it results in more use of physical memory.
PennMUSH (like TinyMUX) also generally includes more features, functions, etc, than TinyMUSH (which may be a good or bad thing). PennMUSH has the royalty flag, powers, zones, built-in mail, built-in chat, a topology checking system, object creation/modification timestamping. It does not have @robot or @forwardlist currently.
PennMUSH 1.7.3 supports IPv6. PennMUSH 1.7.3 is internationalized, and has support for international character sets, time formats, and server messages. Server messages are being translated into many languages, and virtually complete translations are available for Hungarian and Swedish.
One of PennMUSH’s best features is its development and support team. The developers make a strong effort to provide help and support to users of the code. Javelin’s Guide for PennMUSH Gods (http://www.pennmush.org/~alansz/guide) provides extensive help for the player embarking on running their own PennMUSH. There is also a user mailing list.
Rom: Contributor: Russ Taylor (email@example.com) Server Family: DikuMud Authors: Russ Taylor Language: C Current version: 2.4b6 Status: 2.4b6 released May 1998. No active development.
Primary WWW site: http://www.hypercube.org/tess/rom/
Technical Details: Operating systems: All UNIX (good portability). Windows versions available from other sources. Memory usage: About 5 megabytes with stock areas Disk usage: About 6 megabyte after compilation with no player files. Average player file is 5 kilobytes. Code size: 46500 lines of C code.
Derivatives: EmberMUD, ROT
ROM started in early February 1993, using Merc 1.0 code. In July of 1993, ROM II was started, eventually replacing the original ROM. ROM was up for a little over a year, after which the code (version 2.3) was released, and various other ROM muds were started, including Rivers of Mud under a new management (Zump’s ROM), at rom.org 9000.
ROM 2.4 was developed during my time with Moosehead mud, and the release shares many of the features I wrote while I was there. Additional code was written by Seth Scott (the new poofin/poofout), and many contributions and ideas from the Merc list were used. Portions of Rusty’s work on Moosehead also remain.
The new features of 2.4 were largely produced in bull sessions with Gabrielle Taylor and Brian Moore, without whom this release wouldn’t have happened. In particular, the new privacy code, furniture, and wiznet are the results of Gabrielle’s ideas.
Changes to the standard diku mob and object format, as well as the changes to Merc 2.1 source code, were done by Alander over many a late night of hair-pulling. Hope you enjoy it.
The major advancements of ROM over the Merc code base are a wider skill and spell base, character races, different damage types, and a wealth of features to add depth and flavor to the world. On ROM, you can sleep on a couch, wear a ring of fire resistance, or even summon up a portable hole. Stability is a major goal of the ROM code base, a stock ROM mud should stay up weeks without crashing.
SMAUG: Contributor: Derek Snider (firstname.lastname@example.org) Server Family: DikuMud Authors: Derek Snider (Thoric), Altrag, Blodkai, Narn, Haus, Scryn, Rennard, Swordbearer, Gorog, Grishnakh, Nivek, Tricops and Fireblade Language: C Current version: 1.4a Status: Active Development.
Primary WWW site: http://www.game.org/smaug/
Technical Details: Operating systems: All UNIX (good portability). Windows versions available from other sources. Memory usage: About 4.3 megabytes with stock areas Disk usage: About 15 megabytes after compilation with no player files. Average player file is 8 kilobytes. Code size: 134100 lines of C code.
The SMAUG code started out as a Merc2.1 MUD called “Realms of Despair” in 1994. It wasn’t until 1996 that it was given its name, and the first public release wasn’t until December of 1996. The interest in the code spread like wildfire, and within a few months and a few revisions there had been over 20,000 downloads of the distribution.
SMAUG is a significant overhaul of the Merc code, as Merc was an overhaul of the original DikuMUD code. We can confidantly state that no other derivative has changed the internal workings of its parent codebase nearly as much as SMAUG.
Where Merc stripped down and simplified DikuMUD, SMAUG reintroduced a lot of the features and detail that got removed while retaining the simplicity of Merc. This is most notable when creating mobiles and objects, as by default a mobile’s stats will be auto generated by the server based on the mobile’s level, but you can override any stat to very fine detail far beyond the original DikuMUD.
The goal for SMAUG was to be the most feature rich, yet stable and consistant code base. It’s not just a pile of snippets patched together, as most every feature it has was coded by the development team, well thought out and properly integrated. SMAUG feels a little more like a SillyMUD derivative than a Merc derivative.
The code has been playtested on a very large MUD, stress-tested with serveral hundred simultaneous players, carefully optimized and debugged.
Extremely complete online building (OLC) support, extensively reworked Mobprogram code that allows room and object programs, dynamic spell system, mounts, extended exit system, levers, pullchains, switches, traps, bulletin boards, corpse saving, clans, guilds, deities, races, languages, new classes, layered equipment, and far too much to list. Additional URLs:
The (searchable) SMAUG FAQ is at http://www.co.iup.edu/~hzcg/smaug/
The SMAUG HOWTO is at http://www.cs.utk.edu/~london/smaug/SMAUGDOC
TinyMUX: Contributor: Stephen Dennis (email@example.com) Server Family: PennMUSH, TinyMUSH Maintainer: Stephen Dennis Language: C and C++ Current version: 2.0 Status: Version 2.0 in Beta 4
Primary WWW site: http://svdltd.com/TinyMUX
Primary FTP site: ftp://svdltd.com/TinyMUX
Technical Details: Operating systems: Unix (portable — some platforms still need review) Win32 (Windows 95, 98, and NT)
Code size: 73275 lines
TinyMUX forked from the TinyMUSH 2.2 codebase. The code has co-mingled over time with TinyMUSH, MUSE, and PennMUSH as well as adding it’s own features.
In October 1999, Stephen Dennis took over the maintainer role from David Passmore and Stephen’s work on the server dating back to September 1998 was folded into the codebase and brought back to Unix.
TinyMUX 2.0 is currently in Beta.
TinyMUX 2.0 has not substantially changed much that is visible to the user. The Functional Spec, if you will, of the server is the same as TinyMUX 1.6. The server has been and continues to be re-written and optimized subsection by subsection, but it supports the same flatfile, com system, and mail database formats. It just runs faster, takes up less memory, and crashes much less often.
The database of bugs and feature requests is currently at about 300 bugs with about 55 still outstanding. There are no known crashing bugs. The highest-priority bugs are related to making functions ANSI-aware and build issues.
The following subsections have been substantially re-written:
- GDBM is removed in favor of CHashFile. - htab replaced in favor of CHashTable. - Time/Dates supporting dates between -27256 BCE to 30826 AD - Scheduling/Queuing re-worked and much faster. - Networking. - Parser is over 20x faster leading to a user-perceptible speedup of a little over 2x. - Large Integer Math. - For medium large-sized database, the memory footprint of the server is a third to half of the memory footprint of TinyMUX 1.6, but the memory footprint is smaller for small games, too.
LP – CD Driver: Contributor: Troy Edwards (firstname.lastname@example.org) Server Family: LPMud Authors: Lars Pensjö with contributions by many others Language: C Current version: 4.7
Primary WWW site: http://genesis.cs.chamlers.se/
Technical Details: Operating systems: Most Unix (good portability) Memory usage: About 3.2 megabytes with barebones lib Disk usage: About 900k binary, about 30M for bare mudlib Code size: 42,332 lines, 933,714 bytes of C code (server only) Code style: Server written in C, Mudlib written in LPC
Mudlibs: Only the CD (Genesis) lib is known to work with the stock driver
History: (From the Genesis website)
Genesis is the original, interactive, ever expanding, on-line fantasy gaming experience developed using the LPMUD format. LPMUD is the invention of Lars Pensjö. The acronym stands for Lars Pensjö’s Multi User Dungeon. This format enhances the fantasy game environment by introducing the concept that the participants of the game may, if they so desire, actually contribute to it in the form of object-oriented code. Although Lars himself has long since retired work on the mud continues anon.
LP – DGD Driver: Contributor: Felix A. Croes Server Family: LPMud Authors: Felix A. Croes Language: C Current version: 1.2 patchlevel 1 Status: 1.3 is in development
Primary WWW site: http://www.dworkin.nl/dgd/
Technical Details: Operating systems: UNIX, Windows, Mac, BeOS, Amiga, OS/2 Memory usage: Varies depending on mudlib, 1M or more Disk usage: Depends on mudlib, smallest known mudlib is about 360K Code size: Approximately 64K lines of C code
Derivatives: DGDs (used by Skotos Tech, (http://www.skotos.net/)
DGD is a rewrite from scratch of LPMud, and maintains backward compatibility with LPMud 2.4.5. The first public release was in 1993. DGD continues to be actively developed.
Like other servers such as MOO, Cold and LPMud, DGD is not so much a MUD server as a platform for writing one. The internal language is called “LPC” and is mostly compatible with the other dialects in the LPMud family. The actual MUD written in LPC is called a “MUD library” or “mudlib”.
DGD was written to be small, clean, fast and highly configurable. It is being used for both small and very large MUDs (largest as of August 2002 has a dataset of almost 2 gigabytes). Alone in the LPMud family, DGD is persistent.
DGD has some unique features. Among them are a builtin yacc-like parser generator, which can be used to generate a command parser from a language grammar, and rollback of changes in case of an error (to preserve consistency).
Erwin Andreasan (Envy, Merc) – email@example.com
Michael Quan (Envy, Merc) – firstname.lastname@example.org
Russ Taylor (Rom) – email@example.com
Alan “Javelin” Schwartz – firstname.lastname@example.org
Derek Snider – email@example.com
Stephen Dennis – firstname.lastname@example.org
Michael Seifert – Seifert@Dikumud.com
Hans-Henrik Staerfeldt – God@Dikumud.com
Troy Edwards – email@example.com Felix Croes – Felix Croes
This posting has been generated as a public service, but is still copyrighted 1996-1999 by Jennifer Smith. Modifications made after August, 1999 are copyrighted 1999-2002 by Andrew Cowan. If you have any suggestions, questions, additions, comments or criticisms concerning this posting, contact Andrew Cowan (firstname.lastname@example.org). Other Frequently Asked Questions (FAQ) postings contain information dealing with clients, servers, RWHO, and FTP sites. While these items aren’t necessary, they are quite useful. I’d also like to thank cthonics (
email@example.com) for his help in writing these FAQs, ashne and Satoria for their help, and everyone else for helpful comments and suggestions. Thanks again to Alec Muffett (
firstname.lastname@example.org) of alt.security.
The most recent versions of these FAQs are archived at http://www.mudconnect.com/mudfaq/ and on rtfm.mit.edu in the news.answers archives.