MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]
[FAQ] MOO-Cows FAQ
It's been quite a while since a post (or update) of this, so here it
is. Some of the resources have been removed because they no longer
worked and I was unable to find a working replacement. I'm looking
for a MOO-Cows archive available on the web.
A few questions relating to really old items were removed.
---
MOO-Cows FAQ
Ken Fox
Last updated Thursday, February 27, 1997
The "MOO Frequently Asked Question List" is maintained by Ken Fox
(fox@ccs.neu.edu). Direct all questions or comments concerning this
FAQ to him. Submissions and questions are welcome and appreciated.
Ken Fox makes no warranty regarding the fitness of any of the informa-
tion in this FAQ.
______________________________________________________________________
Table of Contents:
1. Server Related
1.1. Who invented MOO?
1.2. What are the minimum requirements for running a MOO?
1.3. Location of LambdaMOO server source.
1.4. Location of core databases.
1.5. Non-UNIX MOO ports.
1.6. What kind of security risk is running a MOO server?
1.7. When is the next release due out?
1.8. Is disk based MOO going to be part of the next release?
1.9. Why won't my MOO send email with new character's passwords?
1.10. How does the MOO pick a verb to run when someone types a
command?
2. Database and Programming
2.1. Where can I get the Programmer's Manual?
2.2. Is there a way to incorporate new features of LambdaCore into
my MOO's DB?
2.3. Objects like $room and $player are part of the `core' of the
MOO. How do I add new ones?
2.4. $spell is HUGE. How can I recycle it without running out of
ticks or seconds?
2.5. How do I do execute a verb automatically each time the server
starts?
2.6. How can I make an object in a room "listen" to everything
that's being said?
2.7. My MOO checkpoints every hour. I want to change this but I
don't know where to look.
3. Miscellaneous
3.1. Where can I find the answer to...
3.2. I'm new to UNIX, and I need to ..
3.3. I want to port something from one MOO to another. Who do I
ask for permission?
3.4. What are some good clients to use with MOO?
3.5. How do I change my MOO password? I've forgotten or lost the
password to #2! How do I log into my MOO?
3.6. Is anybody else (besides Pavel) developing a public server
that runs MOO dbs?
3.7. How do I subscribe to/unsubscribe from this list?
3.8. How can I obtain additional copies of this list?
4. Other Resources
4.1. Information
4.2. Archives
______________________________________________________________________
1. Server Related
1.1. Who invented MOO?
Stephen White (ghond) wrote the first MOO server. Pavel Curtis took
the basic design, language, and code, fixed bugs and added features to
release the first LambdaMOO version. He maintained the server for
several years. The MOO server is currently maintained by Erik Ostrom
(eostrom@research.att.com).
1.2. 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.3. Location of LambdaMOO server 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 `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.
In addition to the server, you will need a core database. A core
database provides functionality augmenting that of the server. Every
MOO needs to start from some kind of core database.
1.4. Location of core databases.
Until recently, the only core database available was LambdaCore.
LambdaCore is still what most people use. You can get it from the
same directory that the MOO source is available in.
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.
Core databases available:
LambdaCore
The original. Retrieve it from
ftp://parcftp.xerox.com/MOO/LambdaCore-latest.db. To contact
the maintainers, send mail to *core-db-issues (if you have a
character) or *wizard-list (as a guest) on LambdaMOO
(lambda.xerox.com 8888).
JHCore
A LambdaCore based db that adds significant enhancements. It
features a hypertext help system, administration groups, MCP
fancy client support, enhanced English presentation tools, and
lots of other features. See Why JHCore
<http://jhm.ccs.neu.edu:7043/note/name!why-jhcore> for more
information about the enhancements. JHCore is available from
JHM's FTP site
<ftp://ftp.ccs.neu.edu/pub/mud/muds/jhm/database>. Connect to
JHM <telnet://jhm.ccs.neu.edu:1709/> and send mail to *jhcore.
1.5. Non-UNIX MOO ports.
There are some non-UNIX ports of MOO, including ports to MacOS and
Win32 (Win95/WinNT). See the resources section for the latest list.
1.6. What kind of security risk is running a MOO server?
(Most of the facts for the below answer come from thread on MOO-Cows
about this subject. Most of the text, too. Thanks to Jay Carlson
(nop@nop.com) and Ian Macintosh (siman@ihug.co.nz).)
Disclaimer: Everything said here is an identification of a risk I am
aware of. I am not a security expert. There may be other risks or
the risks I mention below may be of other forms. As with any other
answer in this FAQ, I would welcome submissions on this subject.
One of the first things to keep in mind with computer security is
``what are we trying to protect from whom?''. The threat that the
unmodified MOO server poses to the server machine is limited to denial
of service attacks. A MOO programmer could use all the memory, CPU,
or disk on the partition that MOO is dumping to. The server itself
provides no access to the filesystem (though there are patches that
do) or other operating system services.
If you have OUTBOUND_NETWORK turned on, there are a few threats to
machines on your local net if they use some sort of ill-configured IP-
address-based trust mechanism. Very few sites will care about this,
because everyone knows that address-based trust is a really bad idea
these days. Your network admins will know if they have such an
assumption built into your network, and can remedy this by taking your
server machine out of the trust list. (BTW, now that MOO can speak
binary data, the number of services you could potentially attack
through it has increased. I still do not think it is a problem unless
you use, say, address-based authentication for X, aka xhost.)
If you have OUTBOUND_NETWORK turned on, your machine could be a threat
to the Internet as a whole by laundering connections---an attacker
connects to your server, and then connects through it to the machine
they're really after, to make tracing their connections more
difficult. The chance of this is vanishingly small; there are far
more convenient anonymous sites out there that are perfectly able to
launder connections for the cracker community.
By running any sort of visible and popular network service, you become
more of a target for conventional cracking attacks. This risk is not
exclusive to MOO; hosting a popular web page will make it more
attractive for people to attack you. Depending on your level of
visibility, you may want to tighten up general security on your
machine or site.
Some organizations have other concerns. A MOO server may allow
organizational mapping, or accidental disclosure of proprietary
information, or whatever. If you're a company that has issues like
this, you already understand these things or have people at your site
that do. Go talk to them. Feel free to ask them how the MOO server
is more dangerous than existing communications mechanisms such as
email.
1.7. When is the next release due out?
It is unpredictable when each new version of the server will be
released. The latest version of the server is 1.8.0p5. This is the
last release by Pavel.
1.8.0p5 <ftp://ftp.parc.xerox.com/pub/MOO/LambdaMOO-1.8.0p5.tar.Z> is
available on the Parc FTP Site.
1.8. Is disk based MOO going to be part of the next release?
No. No disk based version of MOO is planned.
1.9. Why won't my MOO send email with new character's passwords?
Using outbound mail requires 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 README file in the MOO
distribution for more info on compiling the MOO. It is a good idea to
look over options.h as there are several important options set there.
Andy Bakun (abakun@rci.ripco.com)
1.10. How does the MOO pick a verb to run when someone types a com-
mand?
The first thing the MOO does is look for a verb named #0:do_command.
If it finds that, it runs it with argstr set to whatever was typed on
the command line and the arguments the words on the command line. For
example, if a player typing "foo bar baz" would result in a verb call
#0:do_command(``foo'', ``bar'', ``baz'') and argstr would be set to
``foo bar baz''.
If this verb returns true, the the parser stops there and assumes
#0:do_command handled the command. If it returns false, then the
parser uses the built in parser on the command.
The command parser splits the command up into verb dobj prep iobj and
looks for verbs on the player, the room (player's location), dobj, and
iobj (in that order). If it finds no matches, it calls room:huh.
Most available MOO cores do specialized extended parsing and matching
in room:huh.
For a more detailed explanation of command parsing, see the LambdaMOO
Programmer's Manual section titled ``Command Parsing''. Note that the
section is several revisions out of date, but the new behavior
(searching for and calling #0:do_command) is documented above.
2. Database and Programming
2.1. Where can I get the Programmer's Manual?
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 available on PARC's FTP server
<ftp://parcftp.xerox.com/pub/MOO> The file name is
`ProgrammersManual.*' where `*' is the format tag. It is available in
DVI, PostScript, TeXInfo, and plain text formats.
2.2. 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.)
2.3. 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
referencing #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 releases 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.
2.4. $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.
2.5. 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.)
2.6. 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.
2.7. 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.
3. Miscellaneous
3.1. Where can I find the answer to...
Always try the FAQ and the MOO-Cows archives, and FAQs about other
subjects if they apply. Pointers to the archives and sources to get
other forms of this FAQ are in the Resources section. The next
question has some pointers to UNIX resources for UNIX questions.
3.2. I'm new to UNIX, and I need to ..
You might be interested in reading one or more comp.unix.question FAQs
<http://www.cis.ohio-
state.edu/hypertext/faq/bngusenet/comp/unix/questions/top.html>.
Reading other comp.unix.* FAQs <http://www.cis.ohio-
state.edu/hypertext/faq/bngusenet/comp/unix/top.html> might give you
more information about your particular flavor of UNIX. Another good
source of answers is rtfm.mit.edu.
3.3. I want to port something from one MOO to another. Who do I ask
for permission?
The owner of the object. If you can't get in touch with the owner and
the object's description doesn't explicitly grant permission to port,
assume you can't port the object. If the owner of the object is not a
real player (e.g. hacker), then contact the administrators of the MOO.
The USENET Copyright FAQ <http://www.cis.ohio-
state.edu/hypertext/faq/usenet/Copyright-FAQ/top.html> is a good
source for information about copyrights. Note that an object being on
a MOO and readable by everyone isn't sufficient permission to port it
to another MOO. Finally, If the object isn't a generic object, ask
yourself if you really want to port it or if you instead want to make
an original object.
3.4. What are some good clients to use with MOO?
Most people prefer to use TinyFugue or the emacs client, mud.el.
mud.el is available 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.
3.5. 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 using LambdaMOO 1.8.0 or later, run the MOO server in
emergency wizard mode, eval #2.password = crypt("new-password"), and
quit saving the database. Once you do this, #2's password should be
set to "new-password".
unix:~> moo -e yourdb.db yourdb.new
MOO (#2): eval #2.password = crypt("new-password")
MOO (#2): quit
If you are using an older version of the server and 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'.
3.6. 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.
3.7. How do I subscribe to/unsubscribe from this list?
Send a message to MOO-Cows-request@parc.xerox.com with an empty
subject and either
subscribe
or
unsubscribe
in the body.
3.8. How can I obtain additional copies of this list?
The MOO-Cows FAQ is available 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/.
4. Other Resources
4.1. Information
Sources of information
o rec.games.mud.* FAQs <
http://www.math.okstate.edu/~jds/mudfaqs.html>
o New Archwizard FAQ
<gopher://gsep.pepperdine.edu/00/gsep/technical/mud-moo/new-
archwiz-faq.txt>
o Lost Library of MOO <http://lucien.berkeley.edu/moo.html>
o LPMOO <http://www.ccs.neu.edu/home/rob/lpmoo.html>
o WinMOO FAQ <http://www-
personal.engin.umich.edu/~cunkel/WinMOO/winmoo-faq.html>
o Upgrading LambdaCore to 1.8.0 <http://flake.org:8989/742>
4.2. Archives
Archives of patches, messages, etc.
o MOO-Cows list <ftp://parcftp.xerox.com/pub/MOO/mail/>
o MOO FTP <ftp://parcftp.xerox.com/pub/MOO/>
o MOO server patches <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>
Follow-Ups:
Home |
Subject Index |
Thread Index