Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
faqs.org - Internet FAQ Archives

[rec.games.mud]: FAQ #4/4: Servers at a glance

( Part1 - Part2 - Part3 - Part4 )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Forum ]

See reader questions & answers on this topic! - Help others by sharing your knowledge
    FREQUENTLY ASKED QUESTIONS: Detailed information about mud server types
                                       
   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

     * 4.1. What is a mud server
     * 4.2. What does this section cover?
     * 4.3. What is [server type]
          + 4.3.1. CircleMUD
          + 4.3.2. Crimson2
          + 4.3.3. Dikumud
          + 4.3.4. Envy
          + 4.3.5. Merc
          + 4.3.6. PennMUSH
          + 4.3.7. Rom
          + 4.3.8. Smaug
          + 4.3.9. TinyMUX
       
  MUD Servers at a Glance
  
   4.1. What is a mud server
   
   Please see section #3 of the MUD FAQ "Clients and Servers", a basic
   overview is presented on mud servers in general.
   
   4.2. What does this section cover?
   
   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.
   
   4.2. What is [server type]
   
   This section will describe the mud server types that we currently have
   data for.
     _________________________________________________________________
   
   CircleMUD:
   Contributor: Daniel A. Koepke (dkoepke@circlemud.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.
   Derivatives: LexiMUD
   
   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.
   
   Features:
   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.
   
   Additional URLs:
   Ceramic Mouse
   CircleMUD Community Network
   CircleMUD Mailing List Site
     _________________________________________________________________
   
   Crimson2:
   Contributor: Ryan "Cryogen" Haksi (Cryogen@infoserve.net)
   Server Family: 100% custom, DikuMud style interface
   Authors: Ryan "Cryogen" Haksi (cryogen@infoserve.net) Cam "Corbin"
   Lesiuk (clesiuk@engr.uvic.ca)
   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.
   Derivatives: None
   
   History:
   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.
   
   Features:
   - 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.

   Additional URLs:
   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/
   
   Technical Details:
   Operating systems: Ported to most UNIX systems. Derivatives: All DIKU
   derivatives.
   
   History:
   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.
   
   Features:
   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 (erwin@andreasen.org), Michael Quan
   (michael@envy.com)
   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.
   
   Features:
   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.
   
   Additional URLs:
   ILAB OLC for Envy 2.x
     _________________________________________________________________
   
   Merc:
   Contributor: Erwin Andreasen (erwin@andreasen.org)
   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
   
   History:
   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.
   
   Features:
   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 (dunemush@pennmush.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.
   
   Features:
   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 (rtaylor@cmc.net)
   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
   
   History:
   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.
   
   Features:
   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.
   
   Additional URLs:
   The ROM FAQ is at http://www.hypercube.org/tess/rom/
   Alander's home page is at http://www.cmc.net/~rtaylor/
     _________________________________________________________________
   
   SMAUG:
   Contributor: Derek Snider (derek@idirect.com)
   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.
   Derivatives: SmaugWiz
   
   History:
   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.
   
   Features:
   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 (sdennis@svdltd.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
   
   History:
   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.
   
   Features:
   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.
     _________________________________________________________________
   
                                  Credits
                                      
   Erwin Andreasan (Envy, Merc) - erwin@andreasen.org
   Michael Quan (Envy, Merc) - michael@envy.com
   Russ Taylor (Rom) - rtaylor@cmc.net
   Alan "Javelin" Schwartz - dunemush@pennmush.org
   Derek Snider - derek@idirect.com
   Stephen Dennis - sdennis@svdltd.com
   Michael Seifert - Seifert@Dikumud.com
   Hans-Henrik Staerfeldt - God@Dikumud.com
     _________________________________________________________________
   
     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 by Andrew Cowan. If you have any
     suggestions, questions, additions, comments or criticisms
     concerning this posting, contact Andrew Cowan
     (admin@mudconnect.com). 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 (felixg@coop.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 (aem@aberystwyth.ac.uk) 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.
     _________________________________________________________________
   
   Andrew Cowan / admin@mudconnect.com

User Contributions:

Comment about this article, ask questions, or add new information about this topic:

CAPTCHA




Part1 - Part2 - Part3 - Part4

[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer:
admin@mudconnect.com





Last Update March 27 2014 @ 02:11 PM