MOO-cows Mailing List Archive


MOO-Cows FAQ: Sep 01 1995

                                 MOO-COWS FAQ
   Last updated August 15, 1995
Server Related

    1. Q: What are the minimum requirements for running a MOO?
       A: 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 system.
    2. Q: I want to start my own MOO. Where do I get the source?
       A: The standard MOO archive is
       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 database.
       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
       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 at!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.
    3. Q: I have heard there are problems running MOO on BSDi 1.0 and 1.1
       machines. Is there a fix to this problem?
       A: 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 Minimal.db.
       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 .)
       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.
    4. Q: I've heard a lot about the next release. When is it due out?
       A: 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
       confidently be relied upon.
    5. Q: There's been a lot of talk about a disk based server. Is this
       going to be part of the next release?
       A: 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.
    6. Q: I've heard about MOOs that can serve WWW pages. Can you tell me
       how to make my MOO do this?
       A: There are several ways to make a MOO act as an HTTP server.
       Take a look at the MOOs with WWW gateways list. Most of them
       include some info about how it was done. One way is to use MPL MPL
       and make a "service object" on the MOO that listens on a port and
       knows how to speak HTTP. The only example of this that I have is
       JHM with its web gateway.
    7. Q: I can't get my MOO to send email with new character passwords.
       What's wrong?
       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 <>
    8. Q: I'm trying to add builtins to the server but I can't find any
       documentation about how arguments are passed to them. How does
       this work?
       A: 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
       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 the following:
       (or, in some corners of the server, one of a few other more
       obscure types that need not concern us here); 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.list[0].type == TYPE_NUM); its value (i.e., x.v.list[0].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 manually.
       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 <>
Database & Programming

    1. Q: What is this programmer's manual everybody talks about and
       where can I get it?
       A: 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 at The file name is
       `ProgrammersManual.*' where `*' is the format tag. It is availible
       in DVI, PostScript, TeXInfo, and plain text formats.
    2. Q: Is there a way to incorporate new features of LambdaCore into
       my MOO's DB?
       A: 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 LambdaMOO.)
    3. Q: Objects like $room and $player are part of the `core' of the
       MOO. How do I add new ones?
       A: As documented in section 3.1.10 of 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
    4. Q: Okay, I just started a new MOO and discovered that $spell is
       HUGE. I don't use this for anything so I tried to @recycle it but
       it ran out of ticks. How do I delete this object?
       A: Yes, 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

       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.
    5. Q: How do I fix $news in Oct94 LambdaCore?
         1. Make $news readable by all players by doing:

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

        or send a message to $news and @rmm it.
       Roger Crew <>
    6. Q: How do I do execute a verb automatically each time the server
       A: When the server starts, it calls the verb #0:server_started.
       Create/alter that verb to have it call the verb you want to
       (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.)
    7. Q: How can I make an object in a room "listen" to everything
       that's being said?
       A: 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
    8. Q: My MOO checkpoints every hour. I want to change this but I
       don't know where to look.
       A: 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.

    1. Q: What are some good clients to use with MOO?
       A: Most people prefer to use TinyFugue or the emacs client,
       mud.el. mud.el is availible at". As for other clients,
       you might try poking around at
    2. Q: I'm MOOing from my VMS account and I can't find any good
       clients. Got any ideas?
       A: Yes, version 2.x of tinyfugue was ported to VMS by Mike
       Shimniok and is availible via FTP from Full source is
       availible and soon various binaries as well.
    3. Q: How do I change my MOO password? I've forgotten or lost the
       password to #2! How do I log into my MOO?
       A: 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. Q: What are all the MOOs currently out there?
       A: Its hard to keep an accurate list of all public MOOs.

             Name                         Address Port
----------------- ------------------------------- ----
        LambdaMOO  8888
           BayMOO        8888
      LucidityMOO   6666
         MOOsaico       7777
          PMC-MOO 7777
              JHM        1709
        MirrorMOO     8889
    schMOOze Uni.     8888
      LittleItaly  4444
      FredNet MOO               8888
         Dhalgren 7777
           Sprawl  7777
           Meadow       7777
         MiamiMOO     7777
          MOOtiny       8888
         RiverMOO 8888
            MuMOO      7777
            Donut  7777
           ZenMOO       7777
  Butterfly's MOO     7777
        GopherMOO              Reality.CS.UMN.Edu 6464

   [ EDITOR'S NOTE: Some MOOs have been purposely omitted at the request  ]
   [ of their administrators. If you wish to add _your_ MOO to this list, ]
   [ please send mail to the address listed below. Third party requests   ]
   [ will not be accepted.                                                ]
   [ Requests for additions or changes should include the following info  ]
   [   Name, Address, Numerical Address, Port, WWW Gateway (if any)       ]
       Is anybody else (besides Pavel) developing a public server that
       runs MOO dbs?
       Yes, 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
    5. Q: How do I subscribe to/unsubscribe from this list?
       A: Send an email message to with
       your request to be added to or deleted from the MOO-Cows mailing
    6. Q: How can I obtain additional copies of this list?
       A: The MOO-Cows FAQ is availible via anonymous FTP from It is also
       available via the WWW at
Other Resources

     * New Archwizard FAQ:
     * MOOs with WWW:
     * Public MOOs:
     * MPL Information:
     * LPMOO:
     * MacMOO FAQ:
     * MOO-Cows list:
     * MOO-Cows list (WWW):
     * MOO FTP:
     * MOO server patchs:
     * MUD clients:
     * More MUD clients:
   The "MOO Frequently Asked Question List" is maintained by Kenneth R.
   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.

Home | Subject Index | Thread Index