Copyright (C) 1991 Mike Prudence, Simon Hunt, Floyd Moore, Kelly Larson, Al Harrington.
Copies of the electronic source for this document can be obtained using
anonymous FTP on the Internet. At the site belch.berkeley.edu the
files are pub/moo/LambdaMOO/LamdaCoreManual.*; several different
file formats are provided, including Texinfo, plain text, and Postscript.
Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies.
Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.
Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the author.
The LambdaCore database provides the facilities needed to make a LambdaMOO server useful for Multi User Adventuring. If you compare the LambdaMOO server to a piece of computer hardware, then LambdaCore is the operating system needed to allow the user to do useful work.
This document gives a rundown on the commands of the LambdaCore database, providing examples of how they are used, and some of the ideas behind them. It does not cover how the commands work, nor how they are implemented as verbs in the MOO programming language. A companion manual, The LambdaCore Programmer's Manual covers those aspects of the LambdaCore database.
The user may find it useful to read the other companion manual to this one, The LambdaMOO Programmer's Manual. An understanding of MOO concepts and the MOO language can be useful when playing the game.
A player interacts with the game using a large number of commands. Most of these commands are implemented within the database as verbs of object classes.
The following sections list the commands in the LambdaCore database,
grouped roughly by function. Some commands, such as those used for
manipulating notes, are defined by the particular class of object they
work on, in this case the Note class. Other commands are defined
for one or more classes.
This section intends to give a paper reference for the information given in the help system within the LambdaCore database, with some additional explanation of the concepts involved.
Note that, for commands that can be abbreviated, the form in which the
command is specified in the database is shown. For example, the
inventory command is written down as
i*nventory
which means that this command can be invoked by the player typing any of the following:
i in inv inven etc...
The $player class defines a number of verbs that allow the player
to change and view certain of his/her characteristics. The following
commands are available :
This command is used to print out entries from the online documentation system. The first form prints out a summary table of contents for the entire help system.
The second form prints out the documentation available on the given topic. Many help system entries contain references to other entries accessible in this way. The topic name may be abbreviated in either of two ways: you may give only a prefix of the complete topic name (e.g., `bui' instead of `building') and you may omit an initial `@' character (e.g., `who' instead of `@who'). If the abbreviation you give is ambiguous, you will be presented with a list of the matching complete topic names.
The `help index' commands prints out a complete list of all help topic names, arranged alphabetically. It is sometimes easier to find the topics you're interested in this way, rather than tracing through the chain of cross references.
Finally, we have two addtional forms that are likely to be only of use to programmers:
help object:verbname
This is used to print any documentation strings that are present at the beginning of the program for that verb.
help $foo_utils
prints general information about one of the $..._utils objects
(e.g., $string_utils, $list_utils, etc...), which are all
libraries of generally used verbs.
The commands `?' and `information' (usually abbreviated `info') are synonyms for `help'.
The first form, with an argument, defines your player to have the gender gender. If gender is one of the standard genders (e.g., `male', `female', `neuter',...), your various pronouns will also be set appropriately, making exits and certain other objects behave more pleasantly for you.
The second form tells you the current definition of your player's gender, your current pronouns, and the complete list of standard genders.
Changes your player's password (as typed in the `connect' command when you log in to the MOO) to new-password. For security reasons, you are required to type your current (soon to be old) password as the first argument.
Your password is stored in an encrypted form in the MOO database; in principle, not even the wizards can tell what it is, though they can change it, of course.
Sets your designated home (see `help home') to be the room you're in now. If the current room wouldn't allow you to teleport in, then the `@sethome' command nicely refuses to set your home there. This avoids later, perhaps unpleasant, surprises.
The main purpose of the core classes in the LambdaCore database is to
allow players to construct and explore a virtual world. This involves
moving from one room to another, using designated pathways or
exits and looking at objects and locations along the way. The
command given in this section are used for exploring the virtual world,
and interacting with the game administrators, using news and
@gripe. These verbs are defined by a variety of different
classes.
The descriptions of most rooms outline the directions in which exits exist. Typical directions include the eight compass points (`north', `south', `east', `west', `northeast', `southeast', `northwest', and `southwest'), `up', `down', and `out'.
To go in a particular direction, simply type the name of that direction (e.g, `north', `up'). The name of the direction can usually be abbreviated to one or two characters (e.g., `n', `sw'). You can also type `go direction' to move; this is particularly useful if you know you're going to type several movement commands in a row.
In addition to such vanilla movement, some areas may contain objects allowing teleportation and almost all areas permit the use of the `home' command to teleport you to your designated home.
A couple of other commands are available to allow movement from one place to another.
Invokes the named exits in the named order, moving through many rooms in a single command.
blip types: > go n e e u e e s e
and moves quite rapidly north, east, east, up, east, east south and east, all in one command.
Instantly teleports you to your designated home room. Initially, this
room is the $player_start room. You can change your designated
home using the @sethome command.
Objects usually have verbs defined on them that allow players to manipulate and use them in various ways. Standard ones are:
get
drop
put
give
look
You can see what objects you're carrying with the `inventory' command.
Some specialized objects will have other commands. The programmer of the object will usually provide some way for you to find out what the commands are. One way that works for most objects is the `examine' command.
The first two forms pick up the named object and place it in your inventory. Sometimes the owner of the object won't allow it to be picked up for some reason.
The remaining forms move the named object from inside the named container into your inventory. As before, sometimes the owner of an object will not allow you to do this.
The second form lets you look at a specific object. Most objects have descriptions that may be read this way. You can look at your own description using `look me'. You can set the description for an object or room, including yourself, with the `describe' command.
The third form shows you the description of an object that is inside some other object, including objects being carried by another player.
Prints several useful pieces of information about the named object, including the following:
The obvious verbs are those that are readable and that can be
invoked as commands. To keep a verb off this list, either make it
unreadable using `@chmod'or, if it shouldn't be used as a
command, give it args of `this none this'.
There are several commands available to allow you to communicate with your fellow players. Other commands are available to affect the way communication occurs. The following list shows the commands used for these functions:
say
whisper
page
emote
@gag, @listgag, @ungag
news
@gripe
@typo @bug @idea @suggest
whereis
@who
mail
@paranoid, @check, @sweep
Several commands are available for communicating with other players in the way you might do in real life.
Says anything out loud, so that everyone in the same room hears it. This is so commonly used that there's a special abbreviation for it: any command-line beginning with a double-quote (`"') is treated as a `say' command.
For example, suppose that blip types the following command:
"This is a great MOO!
He would see this printed on his terminal screen:
You say, "This is a great MOO!"
Others in the same room see this:
blip says, "This is a great MOO!"
whisper "Hello there" to blip
sends the following message to blip:
Ezeke whispers, "hello there" to blip.
You sense that blip is looking for you in The Venue Hallway.
is sent to the recipient of the page. If an argument is given, it is treated as a message to send to the other player. This results in the recipient getting a message like
You sense that blip is looking for you in The Hallway He pages, "Hello - are you busy ?"
Paging is used primarily to attract the attention of a player, or to pass short messages between players in different locations. It is not intended to be used for conversation.
The following commands can be used to set messages referred to by `@page':
All of these undergo the usual pronoun substitutions except that in both cases the direct object `%d' refers to the recipent of the page and the indirect object `%i' refers to the sender.
Announces anything to everyone in the same room, prepending your name. This is commonly used to express various non-verbal forms of communication. In fact, it is so commonly used that there's a special abbreviation for it: any command-line beginning with `:' is treated as an `emote' command.
For example, if blip types the following:
:wishes he were much taller...
Everyone in the same room would see the following message:
blip wishes he were much taller...
Occasionally, you may run into a situation in which you'd rather not hear from certain other players. It might be that they're being annoying, or just that whatever they're doing makes a lot of noise. Gagging a player will stop you from hearing the results of any task initiated by that player. You can also gag a specific object, if you want to hear what the owner of that object says, but not the output from their noisy robot. The commands to use gagging are described below:
For example, if blip types in the following command:
@gag geezer
and no longer hears anything that geezer says. (1)
If you specify an object, then any text originating from that object will not be printed.
For example, suppose Noisy Robot prints `Hi there' every 15
seconds. In order to avoid seeing that, blip types the following
command:
@gag Noisy
and no longer hears that robot! Note that blip must be in the same room
as Noisy Robot for this to work, or know its object number.
Remove the given player or object (or, in the second form, everyone) from your `gag list'. You will once again see any messages that result from actions initiated by the ungagged player(s) or objects. In particular, you will once again be able to hear them if they speak, emote, or whisper to you.
For example, suppose that blip types the following:
@ungag geezer
and is once again able to hear geezer's witty remarks. (2)
Shows you a list of the players and objects currently on your gag list. You don't see any messages that result from actions initiated by the players or objects on this list. In particular, you will not hear them if they try to speak, emote, or whisper to you.
Several commands are provided for communicating with the people that run
the game. The news command is used by the wizards to let players
know of anything that is globally interesting. Players can use
`@grip' to complain to the wizards, and commands like
`@typo' to report defects to builders and programmers.
The following section describes these commands in detail.
You may hear back from the wizards eventually. For example:
>@gripe The Fruitbat >"How come I can't ever see the fruitbat in the Venue Clock? >" -- A frustrated player
sends it, and, somewhat later, the wizards reply with a note about being sure to look while the Clock is chiming.
If text is given, a one-line message is sent to the owner of the room, presumably about something that you've noticed. If text is not given, we assume you have more to say than can fit comfortably on a single line; the usual mail editor is invoked. The convention is that @typo is for typographical errors on the room or objects found therein, @bug is for anomalous or nonintuitive behaviour of some sort, and @idea/@suggest for anything else.
The usual mail editor is only invoked for this command when in rooms that allow free entry, i.e., rooms that are likely to allow you back after you are done editing your message. Otherwise these commands will require text and only let you do one-line messages. Most adventuring scenario rooms fall into this latter category.
Two commands are available for finding out where other players are hiding in the virtual world, as follows:
"%N (%#) is in %l (%[#l])."
and the usual pronoun substitutions are done.
For example the default message could expand to
"blip (#42) is in The Venue Manager's Office (#47)
The second form, in which a list of player names is given, shows information for just those players. For any listed players that are not connected, we show the last login time instead of the connect/idle times.
`@who' refers to the `@who_location' on each of the players
to be listed in order to determine what should be printed in the
location column. Pronoun substitutions are done on this string in the
usual manner. The default value is "%l" (i.e., player.location).
There are several commands available that allow you to check that your communications with other players are secure. The following commands are available:
@sweep tries to list the avenues by which
information may be leaving the room. In a manner analogous to @check,
it assumes that you don't want to hear about your own verbs, or those
belonging to wizards, who presumably wouldn't stoop to bugging.
In immediate mode, the monitor prepends everything you hear with the name of the character it considers responsible for the message. Otherwise, it keeps records of the last number (defaults to 20) lines you have heard. These records can be accessed by the @check command.
Output from @check is in columns that contain, in order, the monitor's best guess as to:
`@check' operates by examining the list of verbs that were involved in delivering the message, and assigning responsibility to the first owner it sees who is not trusted. By default, it trusts you and all the wizards. It uses the records maintained by `@paranoid', so you must have used that command before you received the message.
Some kinds of messages are not printed directly to players; they are allowed to contain special characters marking places to include the appropriate pronoun for some player. For example, a builder might have a doorway that's very short, so that people have to crawl to get through it. When they do so, the builder wants a little message like this to be printed:
Zaphod crawls through the little doorway, bruising his knee.
The problem is the use of `his' in the message; what if the player in question is female? The correct setting of the `oleave' message on that doorway is as follows:
crawls through the little doorway, bruising %p knee.
The `%p' in the message will be replaced by either `his', `her', or `its', depending upon the gender of the player.
As it happens, you can also refer to elements of the command line (e.g., direct and indirect objects) the object issuing the message, and the location where this is all happening. In addition one can refer to arbitrary string properties on these objects, or get the object numbers themselves.
The complete set of substitutions is as follows:
%%
%n
%t
%d
%i
%l
%s
%o
%p
%q
%r
%(foo)
%[tfoo], %[dfoo], %[ifoo], %[lfoo]
%#
%[#t], %[#d], %[#i], %[#l]
In addition there is a set of capitalized substitutions for use at the beginning of sentences. These are, respectively,
Note that there is a special exception for player name's (the
.name propertywhich are assumed to already be capitalized as
desired.
There may be situations where the standard algorithm, i.e., upcasing the
first letter, yields something incorrect, in which case a
capitalization for a particular string property can be specified
explicitly. If your object has a .foo property that is like
this, you need merely add a .fooc (in general
.(propertyname+"c")) specifying the correct capitalization.
This will also work for player .name's if you want to specify a
capitalization that is different from your usual .name
For example, Phantom makes a hand-grenade with a customizable explode
message. Suppose someone sets grenade.explode_msg to:
"%N(%#) drops %t on %p foot. %T explodes. %L is engulfed in flames."
If the current location happens to be #1234("blip's house"), the resulting substitution may produce, eg.,
Phantom(#42) drops grenade on his foot. Grenade explodes. Blip's house is engulfed in flames.
which contains an incorrect capitalization (The name `blip' cannot be capitalized. blip may remedy this by setting
#1234.namec="blip's house".
A special nore for programmers: in programs, use
$string_utils:pronoun_sub(). Using the substitution %n
actually calls player:title() while %(name) refers to
player.name directly.
The MOO email system allows you to send and receive messages to and from
other players. Whilst not approaching the complexity of a fully fledged
email system, it does allow players to send short messages between
themselves, normally on game related topics. The Mail Room class
defines a set of verbs that can be used by other MOO programs to send
mail. This is used, for example, by the @gripe command, which
uses the MOO Mail system to deliver gripes to the game administrators.
The following commands are used to activate portions of the MOO mail system:
@mail
@read
@next
@prev
@send
@answer
@rmmail
@renumber
Shows a table of contents for your MOO email message collection. You are notified when you connect to the MOO if there are any such messages. A little arrow indicates the mail system's notion of your current message. The first form lists all of your messages; the second form lists all messages after your current message.
If you have a large number of mail messages, you can give arguments so that @mail only lists the messages you're interested in. The general format is
@mail message-sequence
where message-sequence is some combination of the following
cur
new
#
#-#
last:#
-#
You may use as many of these at once as sanity permits, e.g.,
@mail 1 4 7 last:10 2-3 15 cur
Prints the contents of the indicated messages from your MOO email collection. You get the message numbers for use here by typing the `@mail' command, which prints a table of contents for your entire MOO email collection. If no arguments are given to `@read', then the current message in your collection is printed. In any case, the current message after `@read' finishes is the last one printed.
When the `@send' command is typed, the usual line editor is
invoked. The `subject' command is used to set a Subject:
line. Use `say' (`"') to insert lines in the body of your
message.
Giving this command without arguments resumes editing the previous unsent draft message if one exists.
Prepares for you to compose a MOO email message to the players who either received or composed the indicated message from your collection. The usual editor is invoked. The subject line for the new message will be initialized from that of the indicated message. If you leave off the message number, the reply will be to your current message, if that exists.
If there is a Reply-to: field in the message you are answering,
its contents will be used to initialize the To: line of your
reply. Otherwise, a To: line is determined depending on whether
you specified `sender' or `all' in the command line (or your
.mail_options).
`incl' includes the text of the original message in your reply, `noincl' does not.
Defaults are `sender' and `noincl', but you can change this by
setting your .mail-options property.
You may specify cur in place of a number to specify your current message. `@rmm' with no arguments deletes your current message.
There are 3 personal properties that you can use to customize how your mail is composed and forwarded
This property is a list of people (object reference numbers) who will
receive any mail that gets sent to you. This list may include
non-person recipients (i.e.,descendants of $mail_recipient). If
this list is nonempty, you will not receive any mail yourself unless you
are on it. E.g., if blip is #42 and ur-blip is #43
#43.mail_forward={} -- usual case; ur-blip gets his own mail.
#43.mail_forward={#42} -- blip gets ur-blip's mail instead.
#43.mail_forward={#43,#42} -- ur-blip gets mail and blip gets a copy.
#43.mail_forward={#-1} -- ur-blip's mail disappears without a trace.
This property is a list of people (object reference numbers) to be
notified whenever mail is sent to you. This list may include anything
that has a :tell() verb. Notification will take place regardless
of whether or how your mail is forwarded. Thus, in the previous example
#42.mail_notify={#43}
means that ur-blip will be told whenever blip is sent new mail.
This property is a list of options that is consulted by @send and @answer to determine how messages should initially be composed
The following options are available for @answer:
sender
From: line).
all
From: + To:
lines)
incl
noincl
The following option affects the behaviour of @send and @answer:
replyto
Reply-to: field will be added containing these people.
So, for example, if ur-blip usually wants his replies to go to everyone and always start out with the text of the original included, he should do
;#43.mail_options = {"all", "incl"};
There are a number of commands available to players for building new parts of the MOO. The primary means for players to extend the MOO is for them to create new objects with interesting behavior. There are convenient commands for creating and recycling objects and for keeping track of the objects you've created.
The following commands are used in the creation of objects:
@dig
@create
@recycle
@quota
@count
@audit
@classes
@move
They are described in detail in the following paragraphs.
The main command for creating objects other than rooms and exits, for which `@dig' is more convenient.
The first argument specifies the parent of the new object: loosely speaking, the kind of object you're creating. class-name is one of the four standard classes of objects:
As time goes on, more standard classes may be added. If the parent you have in mind for your new object isn't one of these, you may use the parent's name (if it's in the same room as you) or else its object number (e.g., #1234).
The names are given in the same format as in the `@rename' command, as follows:
name:alias,...,alias
or alternatively
name-and-alias,alias,...,alias
For example, if blip types the following:
@describe me as "A very fine fellow, if a bit on the short side."
People who type `look blip' now see this:
A very fine fellow, if a bit on the short side.
The description of an object is kept in its .description
property. For multi-line descriptions, .description can be a
list of strings.
For example, if blip names his dog using the following command:
@rename #4237 to "Rover the Wonder Dog":Rover,dog
Now we'll see `Rover the Wonder Dog' if we're in the same room as him and we can refer to him as either `Rover' or just `dog' in our commands, like `pet dog'.
The third form of the @rename command is for use by programmers, to change the name of a verb they own. If the new-verb-name contains spaces, the verb will have multiple names, one for each space-separated word.
The `@quota' command prints out your current quota.
To get a larger quota, talk to a wizard. They will take a look at what you've done with the objects you've built so far and make a determination about whether or not it would be a net gain for the MOO community if you were to build some more things. If so, they will increase your quota; if not, they will try to explain some ways in which you could build things that were more useful, entertaining, or otherwise interesting to other players.
The quota mechanism is intended to solve a long-standing problem in many MUDs: database bloat. The problem is that a large number of people build a large number of dull objects and areas that are subsequently never used or visited. The database becomes quite large and difficult to manage without getting substantially more interesting. With the quota system, we can make it possible for players to experiment and learn while simultaneously keeping random building to acceptable levels.
It is expected that some will find the quota system distasteful or otherwise controversial. It was invented by Haakon and he is always interested in hearing your constructive comments, suggestions and protests.
The second form does the same for the named player.
The third form does the same for the named player, but begins searching the database with the numbered object. player may be replaced by "me" to restrict the audit of yourself. This can be useful if you know the player does not own any objects below a certain number (typically the player's number itself).
Interestingly, due to a quirk of the code, "@audit me from me" will show you objects owned by you starting with your object number, an unexpected shorthand.
The first form simply lists all of the defined classes along with short descriptions of the membership of each.
The second form prints an indented listing of that subset of the object parent/child hierarchy containing the objects in the class(es) you specify.
If @move doesn't work and you own the room where the object is located, try using `@eject' instead.
This command is used to remove unwanted objects from places you own.
Players thus removed are unceremoniously dumped in the default player
starting place. Other kinds of objects get thrown into #-1 or
$nothing. Unlike `@move', `@eject' does not
check to see if the object wants to be moved, and with the destination
being what it is, there is no question of the destination refusing the
move, either. Generally, you should only resort to `@eject' if
`@move' doesn't work.
The first form of the command removes the object from the current room. The second form removes the object from the specified place (which, in most cases, you'll have to specify as an object number). In either case, this command only works if you own the room/entity from which the object is being ejected.
The form of the command
@eject ... from me
suffices to get rid of some unwanted object in your inventory.
On any given room, one may user the following commands to set the messages used for ejection:
Rooms and exits are the stuff from which the landscape of the virtual
world is created. A room is generally an instance of the generic
room class, also referred to as $room. An exit is an instance of
the generic exit class, $exit. An exit can be thought of as a
one way tunnel leading from one room to another. If you wish to have a
two way exit, you have to use two exits: one going from the source
to the destination and one going from the destination to
the source.
The following commands are used for creating and managing rooms and exits:
The second form of the command not only creates the room, but one or two exits linking your current location to (and possibly from) the new room. An exit-spec has one of the following two forms:
names names|names
where the first form is used when you only want to create one exit, from your current room to the new room, and the second form when you also want an exit back, from the new room to your current room. In any case, the names piece is just a list of names for the exit, separated by commas; these are the names of the commands players can type to use the exit. It is usually a good idea to include explicitly the standard abbreviations for direction names (e.g., `n' for `north', `se' for `southeast', etc.). DO NOT put spaces in the names of exits; they are useless in MOO.
The third form of the command is just like the second form except that no new room is created; you instead specify by object number the other room to/from which the new exits will connect.
NOTE: You must own the room at one end or the other of the exits you create. If you own both, everything is hunky-dorey. If you own only one end, then after creating the exits you should write down their object numbers. You must then get the owner of the other room to use `@add-exit' and `@add-entrance' to link your new exits to their room.
For example,
@dig "The Conservatory"
creates a new room named "The Conservatory" and prints out its object number.
@dig north,n to "The North Pole"
creates a new room and also an exit linking the player's current location to the new room; players would say either `north' or `n' to get from here to the new room. No way to get back from that room is created.
@dig west,w|east,e,out to "The Department of Auto-Musicology"
creates a new room and two exits, one taking players from here to the new room (via the commands `west' or `w') and one taking them from the new room to here (via `east', `e', or `out').
@dig up,u to #7164
creates an exit leading from the player's current room to #7164, which must be an existing room.
Notes and letters are objects that can have text written on them to be read later. They are useful for leaving messages to people, or for documenting your creations.
Note that, like most objects, only the owner of a note can recycle it.
If you'd like to make it possible for a reader of your note to destroy
it (this is a common desire for notes to other individual players), then
you might want to look at using a $letter instead.
You can make a note by creating a child of the standard note,
$note. The following commands are available for interacting with
notes:
The standard MOO editor is used to perform editing operations.
A letter is a special kind of note with the added feature that it can be
recycled by anyone who can read it. This is often useful for notes from
one player to another. You create the letter as a child of the generic
letter, $letter, encrypt it so that only you and the other player
can read it and then either give it to the player
in question or leave it where they will find it. Once they've read it,
they can use the `burn' command to recycle the letter.
The following command is available for letters, in addition to those used for notes.
Containers are objects that allow you to store other objects inside
them. Containers may be open or closed, using the verbs `open' and
`close' on the container. Containers have a separate lock to
determine if a player may open them. You can make a container by
creating a child of the standard container, $container.
Containers have a large number of messages which get printed when players act upon them.
Containers have opacity. This is manipulated using the following command :
0
1
2
The default opacity is `1' - the container is opaque.
Most objects have messages that are printed when a player succeeds or fails in manipulating the object in some way. Of course, the kinds of messages printed are specific to the kinds of manipulations and those, in turn, are specific to the kind of object. Regardless of the kind of object, though, there is a uniform means for listing the kinds of messages that can be set and then for setting them.
The `@messages' command prints out all of the messages you can set on any object you own.
To set a particular message on one of your objects use a command with this form:
@message-name object is "message"
where `message-name' is the name of the message being set, object is the name or number of the object on which you want to set that message, and message is the actual text.
For example, consider the `leave' message on an exit; it is printed to a player when they successfully use the exit to leave a room. To set the `leave' message on the exit `north' from the current room, use the command
@leave north is "You wander in a northerly way out of the room."
This class of commands automatically applies to any property whose name ends in `_msg'. Thus, in the example above, the command is setting the `leave_msg' property of the named exit. You can get such a command to work on new kinds of objects simply by giving the appropriate properties names that end in `_msg'.
Messages of this type are used on the following objects:
Several kinds of messages can be set on an exit object ; they are printed to various audiences at certain times whenever an attempt is made to go through the exit. The ones whose names begin with `o' are always shown prefixed with the name of the player making the attempt and a single space character. The standard pronoun substitutions (with respect to the player) are made on each message before it is printed.
The following commands can be used to set the corresponding messages on an exit:
Several kinds of messages can be set on things, that is, objects
that have $thing as an ancestor. They are printed to various
audiences under various circumstances when an attempt is made to
`take' or `drop' a thing. The ones whose names begin with
`o' are always shown prefixed with the name of the player making
the attempt and a single space character. The standard pronoun
substitutions (with respect to the player) are made on each message
before it is printed.
The following commands can be used to set the corresponding messages on things:
Several kinds of messages can be set on a container object; they are printed to various audiences at certain times whenever an attempt is made to use the container. The ones whose names begin with 'o' are always shown prefixed with the name of the player making the attempt and a single space character. The standard pronoun substitutions (with respect to the player) are made on each message before it is printed.
The following commands can be used to set the corresponding messages used with containers.
It is frequently useful to restrict the use of some object. For example, one might want to keep people from using a particular exit unless they're carrying a bell, a book, and a candle. Alternatively, one might allow anyone to use the exit unless they're carrying that huge golden coffin in the corner. LambdaMOO supports a general locking mechanism designed to make such restrictions easy to implement, usually without any programming.
Every object supports a notion of being locked with respect to certain other objects. For example, the exit above might be locked for any object that was carrying the coffin object but unlocked for all other objects. In general, if some object `A' is locked for another object, `B', then `B' is usually prevented from using `A'. Of course, the meaning of use in this context depends upon the kind of object.
The various standard classes of objects use locking as follows:
There are two sides to locking:
Note that these two questions are entirely independent: one could invent a brand-new way to specify locking, but the effect of an exit being locked would be unchanged.
Programmers should note that the interface between these two sides is the verb
x:is_unlocked_for(y)
which is called by x to determine if it
is locked for the object y. The way in which
:is_unlocked_for is implemented is entirely independent of the
ways in which x uses its results. Note that you can play on
either side of this interface with your own objects, either defining new
implementations of :is_unlocked_for that match your particular
circumstances or having your objects interpret their being locked in new
ways.
The following commands are used to specify locks on objects.
LambdaMOO supports a simple but powerful notation for specifying locks on objects, encryption on notes, and other applications. The idea is to describe a constraint that must be satisfied concerning what some object must be or contain in order to use some other object.
The constraint is given in the form of a logical expression, made up of object numbers connected with the operators `and', `or', and `not' (written `&&', `||', and `!', for compatibility with the MOO programming language). When writing such expressions, though, one usually does not use object numbers directly, but rather gives their names, as with most MOO commands.
These logical expressions (called key expressions) are always evaluated in the context of some particular candidate object, to see if that object meets the constraint. To do so, we consider the candidate object, along with every object it contains (and the ones those objects contain, and so on), to be `true' and all other objects to be `false'.
As an example, suppose the player blip wanted to lock the exit leading to his home so that only he and the holder of his magic wand could use it. Further, suppose that blip was object #999 and the wand was #1001. blip would use the '@lock' command to lock the exit with the following key expression:
me || magic wand
and the system would understand this to mean
#999 || #1001
That is, players could only use the exit if they were (or were carrying) either #999 or #1001.
To encrypt a note so that it could only be read by blip or someone carrying his book, his bell, and his candle, blip would use the `encrypt' command with the key expression
me || (bell && book && candle)
Finally, to keep players from taking a large gold coffin through a particularly narrow exit, blip would use this key expression:
! coffin
That is, the expression would be false for any object that was or was carrying the coffin.
There is one other kind of clause that can appear in a key expression:
? object
This is evaluated by testing whether the given object is unlocked for the candidate object; if so, this clause is true, and otherwise, it is false. This allows you to have several locks all sharing some single other one; when the other one is changed, all of the locks change their behavior simultaneously.
The internal representation of key expressions, as stored in .key on every object, for example, is very simple and easy to construct on the fly.
The representation of key expressions is very simple and makes it easy to construct new keys on the fly.
Objects are represented by their object numbers and all other kinds of key expressions are represented by lists. These lists have as their first element a string drawn from the following set:
"&&" "||" "!" "?"
For the first two of these, the list should be three elements long; the second and third elements are the representations of the key expressions on the left- and right-hand sides of the appropriate operator. In the third case, `!', the list should be two elements long; the second element is again a representation of the operand. Finally, in the `?' case, the list is also two elements long but the second element must be an object number.
As an example, the key expression
#45 && ?#46 && (#47 || !#48)
would be represented as follows:
{"&&", {"&&", #45, {"?", #46}}, {"||", #47, {"!", #48}}}
One can always enter an editor by teleporting to it, or you can use one of the commands provided
@edit object:verb
@notedit note_object
@notedit object.prop
@send list of recipients
@answer [msg_number] [flags...]
This will transport you to one of several special rooms that have editing commands available. These editors are admittedly not as good as EMACS, but for those with no other editing capability on their host systems, it is better than nothing.
In addition to the commands provided by the generic editor, individual editors provide their own additional commands for loading text from places, saving text to places, and various specialized functions.
Note that a given editor only allows you one session at a time (ie. one verb, one note, or one mail message). If you leave an editor without either aborting or compiling/saving/sending the item you're working on, that editor remembers what you are doing next time you enter it, whether you enter it by teleporting or by using the appropriate command. Note that editors are periodically flushed so if you leave stuff there for sufficiently long, it will go away.
A player may have his own .edit_options property which is a list
containing one or more (string) flags from the following list
quiet_insert
There will be more options, some day.
Most editor commands act upon a particular range of lines. Essentially, one needs to specify a first line and a last line. Line numbers may be given in any of the following forms
n
n^
n_
n$
In the latter three, n defaults to 1, so that `^' by itself refers to the line below the current (i.e., the line that gets `^' printed before it), and likewise for `_' while `$' refers to the last line. Note that the usage depends on whether you are specifying a line or an insertion point (space between lines). `^5' is the space above/before line 5, while `5^' is the fifth line after/below the current insertion point.
Ranges of lines may be specified in any of the following ways:
line
from line to line
line-line line line
With the `from l to l' form, either the from or the to can be left off and it will default to whatever is usual for that command (usually a line above or below the insertion point).
The following commands are provided by the editor classes. Those that are not generic are specifically marked so.
The added text appears as a new line at the insertion point. The insertion point, in turn, gets moved so as to be after the added text. For example:
>"first line -|Line 1 added. >" second line" -|Line 2 added. >list -|1: first line -|__2_ second line" -|^^^^
Appends text to the end of the line before the insertion point. The second form is equivalent to the first except that it doesn't strip leading blanks off of text (just as with the normal `emote' and `:' commands). The insertion point is left unmoved.
>list . -|_37_ Hello there -|^38^ Oh, I'm fine. >:, how are you -|Appended to line 37. >:? -|Appended to line 37. >list . -|_37_ Hello there, how are you? -|^38^ Oh, I'm fine.
The `insert' command, when given an argument, sets the insertion point. If text is provided, a new line will be created and inserted as with `say'. ins, both here and in other commands that require specifying an insertion point (e.g., copy/move), can be one of
^n
n
_n
$
^$
n^$
.
+n
-n
For the truly perverse, there are other combinations that also work due to artifacts of the parsing process, but these might go away...
A single dot `.' is the same as `insert' without any arguments ie, start insertion at the current insertion point.
Normally, only one substitution is done per line in the specified range, but if the `g' flag is given, *all* instances of str1 are replaced. The `c' flag indicates that case is not significant when searching for substitution instances. range defaults to the line *before* the insertion point.
You do not need a space between the verb and the delimiter before str1. [Bug: If you omit the space and the first whitespace in str1 is a run of more than one space, those spaces get treated as one.]
Reply-to: field of your message. With arguments, adds (or
changes) the Reply-to: field.
When someone `@answers' a message, the Reply-to: field is checked first
when determining to whom the reply should be sent.
To clear the Reply-to: field, enter the command
reply-to ""
@edit object:verb.
@notedit note
or
@notedit object.property
respectively.
For both the verb-editor and note-editor commands, object will match on the room you came from, though if the room you came from was another editor, then all bets are off...
Subject:
line for your message. If text is "", the Subject: line is
removed.
To: line) for your message. Recipient names not beginning with * are
matched against the list of players. Recipient names beginning with *
are interpreted as mailing-lists/archives/other types of non-person
addresses and are matched against all such publically available objects.
If the list you want to use isn't in the database (i.e., isn't located
in the database ($mail_agent)) you need to refer to it by object id.
To: line, the message
will not be sent. It may be, however, that valid addresses on your
To: line will forward to other addresses that are bogus; you'll
receive warnings about these, but in this case your message will still
be delivered to those addresses that are valid.
$mail_agent's
mail-forwarding tracer and determines who (or what) is actually going to
receive your message. The resulting list will not include destinations
that will simply forward the message without
:receive_message()'ing a copy for themselves.
The second form expands an arbitrary list of recipients, for if e.g., you're curious about the members of particular mailing list.
You can use the `who' command to determine if you are on a given mailing list.
Verbs and properties are the elements of objects that make them useful. A verb allows you to define things to do with an object, and properties are used to store state information about the object. A verb can be thought of as a MOO code program, executed when the verb on the object is invoked. This can happen if the LambdaMOO parser matches the user input with the verb on an object, or when another MOO code program explicitly calls the verb.
Several commands are available to allow manipulation of properties and verbs.
object-permissions
property-permissions
verb-permissions
See the LambdaMOO Programmer's Manual for their meanings.
To clear all of the permissions for an object, verb, or property, use "" as the second argument.
The following commands are used for creating and manipulating verbs.
Adds a new verb with the given name(s) to the named object. If there are multiple names, they should be separated by spaces and all enclosed in quotes:
@verb foo:"bar baz mum*ble"
The direct and indirect object specifiers (dobj and iobj) must be either `none', `this', or `any'; their meaning is discussed in the LambdaMOO Programmer's Manual. The preposition specifier (prep) must be either `none', `any', or one of the prepositional phrases possible. (a prepositional phrase with more than one word must be enclosed in quotes ("")). All three specifiers default to `none'.
It is also possible to specify the new verb's permissions and owner as part of the same command (rather than having to issue separate `@chmod/@chown' commands), using the third and fourth forms above.
permissions are as with @chmod, i.e., must be some subset of `rwxd'. They default to `rxd' (specifying `w' for a verb is highly inadvisable). The owner defaults to the player typing the command; only wizards can create verbs with owners other than themselves.
This command works differently from all other MOO commands, in that it actually changes how the server will interpret later lines that you type to it. After typing the `.program' line, you are in programming mode. All lines that you type in this mode are simply saved away in the server until you type a line containing only a single period (`.'). At that point, those lines are interpreted as a MOO program and are checked for syntax errors. If none are found, a message to that effect is printed and the code you typed is installed as the program for the verb in question. In any case, after typing the `.' line, you are returned to the normal input-handling mode.
For example,
@list $room:@move
to see the code for the `@move' command, or even
@list $prog:@list
to see the code implementing @list itself.
For programmers, this is such a mind-bogglingly useful thing to do that there is a simple abbreviation for this command; any command beginning with a semicolon (`;') is treated as a use of `eval'.
For example:
>eval 3 + 4
-|7
>;3+4
-|7
>;for x in (player.aliases) player:tell(x); endfor
-|Haakon
-|Wizard
-|ArchWizard
-|0
;;l = {}; for i in [1..10] l = {@l, i}; endfor return l
-|{1, 2, 3, 4, 5, 6, 7, 8, 9, 10}
The complete list of prepositions recognized by the command-line parser is shown in the list below:
The following commands are used for dealing with properties.
Normally, a property is created with permissions `rc' and owned by whoever types the command. However, you may also specify these explicitly, using the third and fourth forms. Only wizards can create properties with owners other than themselves.
`@property' can be abbreviated as `@prop'.
A task is an execution of a MOO program. There are three ways for tasks to be created in LambdaMOO:
fork() statement in the programming language creates a task
whose execution is delayed for at least some given number of seconds;
these are forked tasks.
To prevent a maliciously- or incorrectly-written MOO program from running forever and monopolizing the server, limits are placed on the running time of every task. One limit is that no task is allowed to run longer than one minute; this limit is, in practice, never reached. The reason is that there is a second limit on the number of operations a task may execute.
Every task has an associated clock that counts down ticks as the task executes. The server counts one tick for every expression evaluation (other than variables and literals) and one for every time through the body of a loop. If a task's clock winds all the way down to zero, the task is immediately and unceremoniously aborted.
Command and server tasks are given brand-new clocks with an initial store of 20,000 ticks; this is enough for almost all normal uses.
A forked task inherits the clock of the task that forked it, with however many ticks remain on it. To allow objects like cuckoo clocks and other recurring tasks that do a little bit of work every once in a while forever, clocks also regain ticks at the rate of 25 ticks per second, up to the maximum of 20,000 ticks. The seconds are counted from the end of the time that one task was counting down that clock to the time when the next user of that clock actually begins execution.
Because forked tasks may exist for long periods of time before they begin execution, there are commands to list the ones that you own and to kill them before they execute. These commands are covered in the following section.
Queue ID:
Start Time:
Owner:
Clock:
Clock ID:
Verb:
Line:
The following verbs are useful, but not easily categorisable.
The second form only shows the last-connection time for the named player.
This document was generated on 3 November 1996 using the texi2html translator version 1.51.