# MOO-Cows FAQ: Oct 01 1995

"Kenneth R. Fox" (fox@ccs.neu.edu)
Sun, 1 Oct 1995 16:59:07 PDT

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

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

      The "MOO Frequently Asked Question List" is maintained by Kenneth Fox
      (fox@ccs.neu.edu).  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
      system.

      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
      <ftp://parcftp.xerox.com/pub/MOO>.

      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 JHM's FTP site
      <ftp://ftp.ccs.neu.edu/pub/mud/muds/jhm/database> 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
      <http://jhm.ccs.neu.edu:7043/note/name!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
      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 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
      out?

      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:

        #define OUTBOUND_NETWORK

      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 (abakun@rci.ripco.com)

      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
      TYPE_LIST.

      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
      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 (pavel@parc.xerox.com)

      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
      <ftp://parcftp.xerox.com/pub/MOO> 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
      LambdaMOO.)

      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 #0.room.  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
      object.

      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:

         ;recycle($spell)
         @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:

        ;$recycler:_recycle(renumber(create(#1)));
        ;reset_max_object()

      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:

        ;$news:_fix_last_msg_date()
        ;$news.last_news_time=0
        ;$news:set_current_news($news.current_news)

      Roger Crew (crew@cs.stanford.edu)

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

      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
      <ftp://parcftp.xerox.com/pub/MOO/clients/>.

      Other clients are available at
      ftp://ftp.math.okstate.edu/pub/muds/clients

      VMS users might be interested in the port of tinyfugue 2.x by Mike
      Shiminok.  It's available from
      ftp://ftp.math.okstate.edu/pub/muds/clients/tfvms.

      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

         ;crypt("foo")

      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 (rob@ccs.neu.edu) is working on running MOO db's on an
      LPmud based server (DGD).  He calls it LPMOO and you can read about it
      at http://www.ccs.neu.edu/home/rob/lpmoo.html.  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
      ftp://ftp.ccs.neu.edu/pub/mud/mudlibs/lpmoo.

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

      Send an email message to MOO-Cows-request.PARC@Xerox.com 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
      ftp://ftp.ccs.neu.edu/pub/mud/docs/faqs/ It is also available via the
      WWW at http://www.ccs.neu.edu/home/fox/moo/.

      5.  Other Resources

      5.1.  Information

      Sources of information

      o  New Archwizard FAQ
         <gopher://gsep.pepperdine.edu/00/gsep/technical/mud-moo/new-
         archwiz-faq.txt>

      o  MOOs with WWW <http://www.ccs.neu.edu/home/fox/moo/www.html>

      o  Public MOOs <http://www.ccs.neu.edu/home/fox/moo/moo-list.html>

      o  MPL Information <http://www.ccs.neu.edu/home/ivan/mpl/MPL.html>

      o  LPMOO <http://www.ccs.neu.edu/home/rob/lpmoo.html>

      o  MacMOO FAQ <http://uts.cc.utexas.edu/~grgcombs/htmls/moo.html>

      5.2.  Archives

      Archives of patches, messages, etc.

      o  MOO-Cows list <ftp://parcftp.xerox.com/pub/MOO/mail/>

      o  MOO-Cows list (WWW) <http://shrike.depaul.edu/~abakun/moomail/>

      o  MOO FTP <ftp://parcftp.xerox.com/pub/MOO/>

      o  MOO server patchs <ftp://ftp.crl.com//users/ro/riche/MOO/patches>

      o  MUD clients <ftp://ftp.math.okstate.edu/pub/muds/clients>

      o  More MUD clients <ftp://ftp.tcp.com/pub/mud/Clients>