MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]
MOO-Cows FAQ: Sep 01 1995
-
Date: Thu, 31 Aug 1995 21:02:14 PDT
-
From: "Kenneth R. Fox" <fox@ccs.neu.edu>
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.
Home |
Subject Index |
Thread Index