MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]
MOO-Cows FAQ: Oct 01 1995
-
Date: Sun, 1 Oct 1995 16:59:07 PDT
-
From: "Kenneth R. Fox" <fox@ccs.neu.edu>
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>
Home |
Subject Index |
Thread Index