[Prev][Next][Index][Thread]

# MOO-Cows FAQ: Sep 01 1995

- Date: Thu, 31 Aug 1995 21:02:14 PDT
- From:

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

        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?

           A:

           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>

        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
           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 the following:

           TYPE_NUM, TYPE_OBJ, TYPE_ERR, TYPE_STR, TYPE_LIST

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

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

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

        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:

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

        5. Q: How do I fix $news in Oct94 LambdaCore?

           A:
             1. Make $news readable by all players by doing:

      ;$news.readers=1
             2. If you are bothered by spurious "there is new news" messages,
                either do:

      ;$news:_fix_last_msg_date()
      ;$news.last_news_time=0
      ;$news:set_current_news($news.current_news)
            or send a message to $news and @rmm it.

           Roger Crew <rfc@soda.microsoft.com>

        6. Q: How do I do execute a verb automatically each time the server
           starts?

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

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

        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.

    Miscellaneous

        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
           ftp://parcftp.xerox.com/pub/MOO/clients/". As for other clients,
           you might try poking around at
           ftp://ftp.math.okstate.edu/pub/muds/clients.

        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
           ftp://hacks.arizona.edu/games/mud/clients/tfvms/. 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

       ;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. 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           lambda.parc.xerox.com 8888
               BayMOO                 baymoo.sfsu.edu 8888
          LucidityMOO            dsharp.campus.vt.edu 6666
             MOOsaico                moo.di.uminho.pt 7777
              PMC-MOO       hero.village.virginia.edu 7777
                  JHM                 jhm.ccs.neu.edu 1709
            MirrorMOO              mirror.ccs.neu.edu 8889
        schMOOze Uni.              arthur.rutgers.edu 8888
          LittleItaly           ipo.tesi.dsi.unimi.it 4444
          FredNet MOO                        fred.net 8888
             Dhalgren dhalgren.english.washington.edu 7777
               Sprawl           sprawl.sensemedia.net 7777
               Meadow                meadow.iglou.com 7777
             MiamiMOO              moo.cas.muohio.edu 7777
              MOOtiny                spsyc.nott.ac.uk 8888
             RiverMOO        river.honors.indiana.edu 8888
                MuMOO               chestnut.enmu.edu 7777
                Donut           donut.stark.k12.oh.us 7777
               ZenMOO                cheshire.oxy.edu 7777
      Butterfly's MOO              iron.butterfly.net 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, 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.

        5. Q: How do I subscribe to/unsubscribe from this list?

           A: 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.

        6. Q: How can I obtain additional copies of this list?

           A: The MOO-Cows FAQ is availible via anonymous FTP from
           ftp://ftp.ccs.neu.edu/pub/mud/docs/faqs/MOOCows.txt It is also
           available via the WWW at http://www.ccs.neu.edu/home/fox/moo/.

    Other Resources

      INFORMATION
         * New Archwizard FAQ:
           gopher://gsep.pepperdine.edu/00/gsep/technical/mud-moo/new-archw
           iz-faq.txt
         * MOOs with WWW: http://www.ccs.neu.edu/home/fox/moo/www.html
         * Public MOOs: http://www.ccs.neu.edu/home/fox/moo/moo-list.html
         * MPL Information: http://www.ccs.neu.edu/home/ivan/mpl/MPL.html
         * LPMOO: http://www.ccs.neu.edu/home/rob/lpmoo.html
         * MacMOO FAQ: http://uts.cc.utexas.edu/~grgcombs/htmls/moo.html

      ARCHIVES
         * MOO-Cows list: ftp://parcftp.xerox.com/pub/MOO/mail/
         * MOO-Cows list (WWW): http://shrike.depaul.edu/~abakun/moomail/
         * MOO FTP: ftp://parcftp.xerox.com/pub/MOO/
         * MOO server patchs: ftp://ftp.crl.com//users/ro/riche/MOO/patches
         * MUD clients: ftp://ftp.math.okstate.edu/pub/muds/clients
         * More MUD clients: ftp://ftp.tcp.com/pub/mud/Clients

         _________________________________________________________________

       The "MOO Frequently Asked Question List" is maintained by Kenneth R.
       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.

- Prev: MOO wiz needed for interesting project...
- Next: moving object w/in a verb
- Index: MOO-cows
- Thread: MOO-cows

Home | Subject Index | Thread Index