MOO-cows Mailing List Archive


MOO-Cows FAQ: Oct 01 1995

  MOO-Cows FAQ
  Ken Fox
  Last updated Sunday, October 01, 1995

  The "MOO Frequently Asked Question List" is maintained by Kenneth Fox
  (  Direct all questions or comments concerning this
  FAQ to him.  Submissions and questions are welcome and appreciated.
  This FAQ will be posted again on the first of next month.  Kenneth Fox
  makes no warrenty regarding the fitness of any of the information in
  this FAQ.

  1.  Server Related

  1.1.  What are the minimum requirements for running a MOO?

  The LambdaCore database is approximately 2 megabytes in size. The
  source and executable for MOO will likely occupy another 1-2 Megs. In
  its current state, MOO resides entirely in resident memory when
  running. The process size is going to be roughly 2-3 times the size of
  the database file on disk. Your mileage will vary from system to

  1.2.  I want to start my own MOO. Where do I get the source?

  The standard MOO archive is Xerox PARC's FTP site

  The file `LambdaMOO-X.Y.Z.tar.Z' (for a current server version of
  X.Y.Z) is a compressed tar file containing the complete source code,
  installation instructions, and a copy of the `Minimal' LambdaMOO

  The file `LambdaCore-DDMMMYY.db' (for some date DDMMMYY) is a
  LambdaMOO database file containing the `core' of the running LambdaMOO
  database as of the specified date.  This is almost certainly the
  easiest place for you to start from in creating your own MOO, since
  this includes such useful things as the various generics (room,
  player, exit, thing, container, note, etc.), the MOO text editors, the
  MOO mail system, etc.

  In addition to LambdaCore, you could also start from JHCore, which is
  available from JHM's FTP site
  <> There is the core db
  (JHCore.db-DDMMMYYYY.gz) and there are some modules in subdirectories
  of that one.  You can find a note about some of the difference between
  JHCore and LambdaCore in the document Why JHCore

  The `binaries' subdirectory contains already-compiled executables of
  the current release for various machines.

  MOO has been compiled and run successfully on several different
  operating systems including AIX, BSD UNIX, SunOS 4.x, Linux, Sys V R4,
  Ultrix, OSF, FreeBSD386, Solaris, and NeXT.  Major MOOs are currently
  running on almost all of them.

  1.3.  I have heard there are problems running MOO on BSDi 1.0 and 1.1
  machines.  Is there a fix to this problem?

  Pavel reports that he has found the bug and a workaround for it (in a
  message dated 16 May 1995 to MOO-Cows):

  I have, at long last, gotten around to tracking down the cause of the
  problem many folks have reported in using the MOO server on a BSDi 1.1
  machine.  To refresh folks' memories, it manifests itself as a `syntax
  error' reported when reading in just about any DB file, including

  The next layer of the problem is that the MOO compiler's parser is
  failing to recognize *any* MOO keywords (e.g., `return', `if', etc.).
  This started happening after I changed the server to use a so-called
  `perfect hash table' for keyword lookup; this is a specially-built
  table allowing the server to simply add together the length of a
  string and a couple of the characters in that string, and look up the
  result in a table to see if that string matches one of the keywords.
  The table is built using a tool I run once, before making the
  distribution tar file.

  In order to make the table work case-insensitively, the table-lookup
  code calls the C function `tolower' on every string character it uses,
  to canonicalize the case.  Well, it turns out that BSDi 1.1 has a
  little bug in its version of `tolower': `tolower' does the intended
  job of `toupper' and vice-versa!

  (Note to BSDi hackers: this only happens if, as I do in the server for
  good but complicated reasons, you use the true function versions of
  these, not the macros in ctype.h.)

  The simplest fix for BSDi 1.1 users is to add this line to the very
  top of the file `keywords.c':

     #define tolower toupper

  I have reason to believe that this bug does not exist in BSDi 2.0, so
  I'm going to hold off on trying to incorporate any workaround for it
  in the official MOO release.

  1.4.  It is unpredictable when each new version of the server will be
  released. Pavel Curtis (The maintainer of LambdaMOO) has estimated
  that 1.8.0 might well be out sometime, but no specific date can be
  relied upon.  I've heard a lot about the next release. When is it due

  1.5.  Is disk based MOO going to be part of the next release?

  No, disk basing has been in the works for a while. However, it is not
  due to be released until 1.9.0. There is currently no estimate of a
  time for this release.  However, you might be interested in LPMOO.

  1.6.  How can I make my MOO serve WWW pages?

  There are several ways to make a MOO act as an HTTP server.  Take a
  look at the MOOs with WWW gateways <http:www.html> list.  Most of them
  include some info about how it was done.

  1.7.  Why won't my MOO send email with new character's passwords?

  Using outbound mail requiries that the moo be able to open up network
  connections.  This is a compile time option in the options.h file.
  There is a line that looks like this:

    /* #define OUTBOUND_NETWORK */

  /* and */ are C comment markers so define is commented out.  If the
  MOO server is compiled without OUTBOUND_NETWORK being defined, then
  calls to open_network_connection() will fail with E_PERM.  Since
  outbound mail depends on open_network_connection(), outbound mail
  doesn't work without OUTBOUND_NETWORK.

  To enable outbound network connections, recompile the MOO server after
  editing options.h so it includes the line:


  See also help open_network_connection() in lambdacore for more
  information on open_network_connection and the file named README in
  the MOO distribution tar for more info on compiling the MOO.  It's a
  really good idea to look at options.h even if you are not interested
  in network because there are other important options set in there.

  Andy Bakun (

  1.8.  How does the MOO pass arguments to builtin functions?

  The argument list is represented in the same way as all MOO values; in
  this case, it is a MOO list containing all of the arguments passed to
  the built-in function by the MOO programmer.  First, I'll describe MOO
  value representation in general; after that I'll get back to built-in
  function argument lists in particular.

  MOO values are represented by C structures of type `Var'.  There are
  two members of such a structure, the `type' and the value, `v'.  The
  `type' member is one of TYPE_NUM, TYPE_OBJ, TYPE_ERR, TYPE_STR, or

  This type corresponds exactly to the MOO programmer's idea of the
  standard five MOO data types.  The particular `type' value used in
  each instance determines the form of the `v' or value member of the
  structure; `v' is a union of a number of different representations,
  one for each type.

  If x.type == TYPE_NUM, then x represents a MOO number, the value of
  which is found in x.v.num (a C integer).  The TYPE_OBJ and TYPE_ERR
  cases are handled similarly, representing MOO object numbers and error
  codes; their respective values are found in x.v.obj (a C integer) and
  x.v.err (an element of the C enumeration type `enum error').

  If x.type == TYPE_STR, then x represents a MOO string, the characters
  of which are found in x.v.str (a C `const char *' value).  NOTE the
  use of `const' here.  You should never modify a MOO string value,
  since all MOO values are immutable and you can't easily tell if maybe
  some other part of the MOO is also holding onto a pointer to that
  string.  Instead, use `str_dup()' to make a copy of the string and
  modify that instead.

  If x.type == TYPE_LIST, then x represents a MOO list value, the most
  complicated case; the value part of x is found in x.v.list (a C `Var
  *' value, a pointer to an array of Var structures).  The first
  (zeroth) element of x.v.list always has type TYPE_NUM (i.e.,
  x.v.list0.type == TYPE_NUM); its value (i.e., x.v.list0.v.num) is the
  length of the list (and also one less than the length of the x.v.list
  array).  The rest of the elements of the list are in the succeeding
  elements of the x.v.list array, in the same order as in the MOO list.
  For example, if x represented the MOO list value {17, #3}, then all of
  the following would be true:

          x.type == TYPE_LIST             /* x represents a list */
          x.v.list[0].type == TYPE_NUM    /* the zeroth elt is the list length */
          x.v.list[0].v.num == 2
          x.v.list[1].type == TYPE_NUM    /* the first elt of the MOO list: 17 */
          x.v.list[1].v.num == 17
          x.v.list[2].type == TYPE_OBJ    /* the second elt of the list: #3 */
          x.v.list[2].v.obj == 3

  Brand new list values are *always* allocated using the C function
  `new_list()'.  The other kinds are always created manually, using a
  local C variable of type Var and filling in the members one by one.
  Even for lists, only the actual allocation and setting up of the
  length field are done by `new_list()'; filling in the elements is done

  A new reference to any existing MOO value can be created with
  `var_ref()' and a top-level copy can be made with `var_dup()'; an
  existing reference can be discarded by calling `free_var()'.

  Getting back to built-in function argument lists now, they are simply
  normal MOO lists, containing just exactly the arguments passed by the
  MOO programmer.  Pavel Curtis (

  2.  Database and Programming

  2.1.  What is this programmer's manual everybody talks about and where
  can I get it?

  The LambdaMOO Programmer's Manual is a complete reference for all
  database-independent aspects of the LambdaMOO system, including the
  programming language, built-in functions, and command parser.

  The Programmer's Manual is availible on PARC's FTP server
  <> The file name is
  `ProgrammersManual.*' where `*' is the format tag.  It is availible in
  DVI, PostScript, TeXInfo, and plain text formats.

  3.  Is there a way to incorporate new features of LambdaCore into my
  MOO's DB?

  There is no easy way to merge databases. The easiest thing to do is
  just snag the code from LambdaMOO or somewhere and build/rebuild the
  objects by hand. (For information on how to do so, see `help @dump' on

  3.1.  Objects like $room and $player are part of the `core' of the
  MOO. How do I add new ones?

  As documented in the LambdaMOO Programmer's Manual, `$' object
  references such as `$player' are created by adding a property of that
  name to the system object (#0) and storing the appropriate object's
  number in that property. For example, referencing $room is the same as
  refferencing  When the verb `make_core_database' is run, it
  searches the system object for these links in order to determine which
  objects belong in the core. Newer releasess of the LambdaMOO core
  include the wizard verb `@corify' which will add the specified object
  to the core in the manner illustrated  as well as checking additional
  features such as an `init_for_core' verb being programmed on the

  3.2.  $spell is HUGE.  How can I recycle it without running out of
  ticks or seconds?

  Mr. Spell is so large that he can't be deleted in the conventional
  manner. What you need to do is this:

     @rmprop #0.spell

  This leaves a hole in the database however. You can easily live with
  it but if you find that you can't, just fill it by doing this:


  Another option is to call $spell:clearall() and recycle the object as
  usual.  This takes longer, but it does leave you the option of using
  $spell later, or with a smaller dictionary (by not recycling it).
  $spell without the dictionary is not very big.

  3.3.  How do I fix $news in Oct94 LambdaCore?

  Make $news readable by all players by doing:

    ; $news.readers=1

  If you are bothered by spurious "there is new news" messages, do:


  Roger Crew (

  3.4.  How do I do execute a verb automatically each time the server

  When the server starts, it calls the verb #0:server_started.
  Create/alter that verb to have it call the verb you want to execute.

  (NOTE: If a task has suspended or forked, and its execution is still
  pending when the server checkpoints or is shutdown, that task is saved
  along with the rest of the database. Thus, when the server is
  restarted, that task will be resumed.)

  3.5.  How can I make an object in a room "listen" to everything that's
  being said?

  When something is said in a room, each object in that room is sent
  that text via the verb `tell'. You can hack this verb to do whatever
  you want it to whenever anything is said or done in a room.

  My MOO checkpoints every hour. I want to change this but I don't know
  where to look.

  Change the value of the property #0.dump_interval to the desired
  number of seconds between dumps; the change will take effect after the
  next checkpoint.

  This is documented in the LambdaMOO Programmer's Manual, section
  4.2.2, Database Checkpointing Frequency.

  4.  Miscellaneous

  4.1.  What are some good clients to use with MOO?

  Most people prefer to use TinyFugue or the emacs client, mud.el.
  mud.el is availible at PARC's FTP site

  Other clients are available at

  VMS users might be interested in the port of tinyfugue 2.x by Mike
  Shiminok.  It's available from

  4.2.  How do I change my MOO password?  I've forgotten or lost the
  password to #2!  How do I log into my MOO?

  If you are still capable of connecting as the wizard (i.e., you either
  haven't yet given the wizard a password or you know the current one),
  then the command

     @password (old-password) (new-password)

  will do it (where (old-password) is just omitted if this is the first
  time you're giving the wizard a password).

  If, on the other hand, you cannot currently connect as that wizard,
  but you can connect as some other wizard, then the somewhat more
  arcane command

     ;#2.password = crypt("new-password")

  will do it (where `new-password' is the new password).

  Finally, if you're completely locked out of all available wizard
  accounts, then you're down to the nitty-gritty task of hand-editing
  the database file.  First, while the MOO is running, connect as some
  programmer and type


  It will give you back a random-looking string.  Write it down *very*
  precisely, making sure to match upper/lower case, etc.  Then, bring
  the database file into your favorite text editor and search for the
  string ``#2'' all alone on a line.  It should be followed, on the next
  line, by the name of the wizard (probably `Wizard' if it hasn't been
  changed since the MOO was started).  Scroll down a ways (perhaps quite
  a ways, but not past the place that has `#3' all alone on a line)
  until you find another random-looking string the same length as the
  one crypt() returned above.  Replace that string with the one you
  wrote down and save the file.  You should now be able to log in as the
  wizard using the password `foo'.

  4.3.  Is anybody else (besides Pavel) developing a public server that
  runs MOO dbs?

  Yes, Rob Leslie ( is working on running MOO db's on an
  LPmud based server (DGD).  He calls it LPMOO and you can read about it
  at  He's running a MOO on
  this server.  It is called MirrorMOO and is on the public MOO list.
  You can get this server at

  4.4.  How do I subscribe to/unsubscribe from this list?

  Send an email message to with your
  request to be added to or deleted from the MOO-Cows mailing list.

  4.5.  How can I obtain additional copies of this list?

  The MOO-Cows FAQ is availible via anonymous FTP from It is also available via the
  WWW at

  5.  Other Resources

  5.1.  Information

  Sources of information

  o  New Archwizard FAQ

  o  MOOs with WWW <>

  o  Public MOOs <>

  o  MPL Information <>

  o  LPMOO <>

  o  MacMOO FAQ <>

  5.2.  Archives

  Archives of patches, messages, etc.

  o  MOO-Cows list <>

  o  MOO-Cows list (WWW) <>

  o  MOO FTP <>

  o  MOO server patchs <>

  o  MUD clients <>

  o  More MUD clients <>

Home | Subject Index | Thread Index