![[ nwe help ]](/writing/help/images/nwe-help.GIF)
| Search | Help » General » MOO » JHC » Main Help |
Main MOO help page
! " ' @911 : :: ? _ @add-entrance @add-exit @add-feature @add-owned @addalias admin admin-policy administrator-policy administrators @administrators @admins alias aliases @aliases @answer @audit @auditdb @boot @boot! @bug builder-policy building burn cg character characters @check @co commands @comment common_quota communication communications community-group container-messages containers @contents copyright core-copyright @count creation current-object @current-object @currentobject db-group decrypt delete @describe descriptions doing drop @dump @edit @edit-options @edito @editoptions editors @eject email emote encrypt @entrances erase examine @examine exit-messages @exits features @features following @forward @forward-me full-index @gag @gag! @gag-announce @gagged gagging @gaglist gen-index gender @gender get getting-started give go @go @grant @gripe hand help help-format @helpme home @idea idle idling index information insert introduction inventory join @join key-representation keys @lastlog letters @linelength @listgag @listgag! @locations @lock @lock_for_open locking look mail @mail mail-forwarding @mail-options @mailoptions manipulation manners me @memory message-sequences messages @messages miscellaneous @more @move movement name @netforward news @next @notedit notes objective @opacity @options page @pagelength @paranoid @parents @password @peek point @popo @popobject @prev privacy programming programming-policy project-policy pronouns @pusho @pushobject put @qsend @quicksend @quit @quota quota-policy read @read @recycle @register registration reidle remove @remove-entrance @remove-exit @remove-feature @rename @renumber @reply @request @resident @rmalias @rmmail @rn room-messages rooms say sc security @send @sethome sex @skip @sort-owned spoofing steering-committee @subscribe @subscribed @suggest summary @swapo @swapobject @sweep take tech-group teleportation thing-messages throw time-stamping time-stamps timestamping timestamps topics topology tstamp @tutorial two-letter-spec @typo @ungag @ungag! unix-group @unlock @unlock_for_open @unrmmail @unsubscribe @unsubscribed @uptime @verify-owned @version walk whereis whisper @who @who-options @whooptions wizard-list wizards @wrap write zombie-messages
This is the polite spoof verb. `!<string>' announces an arbitrary string to the current location, except that if the string doesn't contain the player name somewhere as a distinct word, the player's .spoof_attribution property (with the usual pronoun substitutions) is appended and if the resulting strings *still* doesn't contain player:name(), we append it.
Syntax: say <anything> ...
"<anything> ...
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.
Example:
Munchkin types this:
"This is a great MOO!
Munchkin sees this:
You say, "This is a great MOO!"
Others in the same room see this:
Munchkin says, "This is a great MOO!"
Syntax: page <someone> [[with] <text>]
'<someone> [text]
' text
Sends a message to a connected user, telling them your location and,
optionally, <text>.
Example:
Munchkin types:
page Frebble with "Where are you?"
Frebble sees:
Munchkin pages, "Where are you?"
Munchkin sees:
Your message has been sent to Frebble.
The "'" command is just an abbreviation for "page"; it also aids
repeated paging. If you use "'" without specifying who you want to
send the message to, it will be sent to the last person you paged with
"'".
Advanced Features
=================
Page refers to the following messages on the players involved (see `help messages'[1]):
@page_origin []
Determines how the recipient is told of your location.
@page_echo [Your message has been sent to %td.]
Determines the response received by anyone who pages you.
@page_absent [%Nd %n:(is) not currently logged in.]
Determines the response received by anyone who tries to page you when you aren't connected.
All of these undergo the usual pronoun substitutions (see `help
pronouns'[2]) except that in both cases the direct object ({list})
refers to the recipent of the page and the indirect object ({list})
refers to the sender.
Page all the currently connected members of the appropriate group(s). Use the @admins command (`@admins <group> [all]') to list the connected [and disconnected] members.
Syntax: emote <anything> ...
:<anything> ...
::<anything> ...
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.
The alternate form, '::' (less commonly 'emote :'), does not insert
the space between the player name and the text.
Examples:
Munchkin types this:
:wishes he were much taller...
Everyone in the same room sees this:
Munchkin wishes he were much taller...
Munchkin types this:
::'s eyes are green.
Everyone in the same room sees this:
Munchkin's eyes are green.
Syntax: emote <anything> ...
:<anything> ...
::<anything> ...
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.
The alternate form, '::' (less commonly 'emote :'), does not insert
the space between the player name and the text.
Examples:
Munchkin types this:
:wishes he were much taller...
Everyone in the same room sees this:
Munchkin wishes he were much taller...
Munchkin types this:
::'s eyes are green.
Everyone in the same room sees this:
Munchkin's eyes are green.
Syntax: help
help <topic>
help index
Print out entries from the online documentation system. The commands
`?' and `information' (usually abbreviated `info') are synonyms for
`help'.
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; if there
is no topic exactly matching the name you give, the help system checks
for topics for which the name is a prefix, perhaps with the addition
or omission of an initial `@', or perhaps with some confusion beween
dashes (-) and underscores (_), e.g.,
`bui' instead of `building',
`who' instead of `@who',
`@wri' instead of `write',
`add_ent' instead of `@add-entrance',
`unlock-' instead of `@unlock_for_open'
If the abbreviation you give is ambiguous, you will be presented with
a list of the matching complete topic names.
The `help index'[1] commands prints out a list of indices for the
various help databases. Each index gives a list of topics available
on that database. It is sometimes easier to find the topics you're
interested in this way, rather than tracing through the chain of cross
references.
Your `current object' is an object that you can refer to in most
commands without using its name, just by using the symbol "_". It's
intended primarily for programming.
For example, you can type
@co $jtext.link
@d _:
and get a list of verbs defined on the link dispatcher tag.
In addition, if your .eval_env property (see `help eval'[1]) sets _ to
player.current_object, you can use it in evaluations. The default
.eval_env includes this binding. So, to continue the example:
>;_:dname()
=> "the link dispatcher tag"
A stack is kept of the current objects you've been using, so you can
change your current object for a while and then switch back to the
previous one without needing to identify it again.
To find out how to set or view your current object, read the following
help topics:
@currentobject[2]
Set current object, or find out what it is.
@pushobject[3]
Push a current object onto the stack.
@popobject[4]
Return to the previous current object.
@swapobject[5]
Switch between current and previous object.
Syntax: @add-entrance <exit-object-number> Add the exit with the given object number as a recognized entrance to the current room (that is, one whose use is not considered teleportation). Usually, @dig does this for you, but it doesn't if you don't own the room in question. Instead, it tells you the object number of the new exit and you have to find the owner of the room and get them to use the @add-entrance command to link it up.
Syntax: @add-exit <exit-object-number> Add the exit with the given object number as a conventional exit from the current room (that is, an exit that can be invoked simply by uttering its name, like 'east'). Usually, @dig does this for you, but it doesn't if you don't own the room in question. Instead, it tells you the object number of the new exit and you have to find the owner of the room and get them to use the @add-exit command to link it up.
Usage: @add-feature <object>
@remove-feature <object>
Add or remove a feature from your list. A feature is an object which
provides additional commands you can use. For more information, see
`help features'[1].
Note to programmers: @add-feature and @remove-feature are front-ends
for player:add_feature and :remove_feature.
:add_feature returns
o E_PERM unless caller == this || $perm_utils:controls(caller_perms())
o E_INVARG if feature is not an object or is invalid
o E_PERM if the object is not feature_ok
o a true value otherwise
and calls feature:feature_add, if the verb exists.
:remove_feature returns
o E_PERM unless caller == this || $perm_utils:controls(caller_perms()) || caller_perms() == feature.owner
o a true value otherwise
and calls feature:feature_remove, if the verb exists.
Syntax: @add-owned <object> Adds an object to your .owned_objects property in case it managed not to get updated properly upon creation of that object. Checks to ensure that the object is really owned by you and otherwise belongs in your .owned_objects property. See `help @audit'[1] for more information.
Syntax: @addalias <alias>[,...,<alias>] to <object>
@addalias <alias>[,...,<alias>] to <object>:<verb>
The first form is used to add aliases to an object's list of aliases.
You can separate multiple aliases with commas. The aliases will be
checked against the object's current aliases and all aliases not
already in the object's list of aliases will be added.
Example:
Muchkin wants to add new aliases to Rover the Wonder Dog:
@addalias Dog,Wonder Dog to Rover
Since Rover the Wonder Dog already has the alias "Dog" but does not
have the alias "Wonder Dog", Munchkin sees:
Rover the Wonder Dog(#4237) already has the alias Dog.
Alias Wonder Dog added to Rover the Wonder Dog(#4237).
If the object is a player, each alias will be checked against the
Player Name Database to make sure no one else is using it. Any already
used aliases will be identified.
Example:
Munchkin wants to add his nicknames to his own list of aliases:
@addalias Foobar Davey to me
@Addalias recognizes that Munchkin is trying to add an alias to a
valid player and checks the aliases against the Player Name Database.
Unfortunately, DaveTheMan is already using the alias "Davey" so
Munchkin sees:
DaveTheMan(#5432) is already using the alias Davey
Alias Foobar added to Munchkin(#1523).
The second form of the @addalias command is for use by programmers, to
add aliases to a verb they own. All commas and spaces are assumed to
be separations between aliases.
There are three separate (but not necessarily disjoint) groups of
administrators, with different roles and responsibilities. You can
get help about each of the following groups, listed here with a brief
explanation of what it is they're responsible for.
steering-committee[1]
defining and maintaining the MOO's goals and objectives
tech-group[2]
technical development and maintenance of the MOO
community-group[3]
handling social problems and promoting a sense of community
By defining the responsibilities of the various types of
administrators, we hope to clear up any confusion about what a person
`in charge' is supposed to be doing, and what authority that person
has.
@administrators/@admins group [all] List all connected [all] members of the administrative group. See `help admin' for information about the admin groups on JaysHouseMOO.
Every object (including players, rooms, exits) has a name and a set of aliases. The object name is commonly used to display an object in various contexts. The object aliases are used to refer to an object when players type commands. Help is available on the following commands: @rename -- change the names or aliases of an object or yourself. @addalias, @rmalias -- add and remove aliases.
Every object on the MOO (players included) has a list of aliases, or
names by which it can be referred. This is useful when an object has
a nice long descriptive name that you don't want to have to type every
time you refer to it.
Typing `examine object' (see `help examine') will show you its
aliases. If you are a programmer, you can type
`#<object>.aliases', using an object's number, or
`#Munchkin.aliases p'. (The `p' indicates that the prefix is a
player's name.)
For information about setting aliases, see help on the following topics:
@rename[1]
setting an object's name and all aliases
@addalias[2]
adding an alias to an object
@rmalias[3]
removing an alias from an object
@aliases [object] Lists your aliases, or the aliases of the given object.
Syntax: @answer [<message-number>] [sender] [all] [include] [noinclude] Synonym: @reply 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 (see `help editors'[1] for details). 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. In fact you may give a general message-sequence (see `help message-sequences'[2]) argument here, provided that it indicates only a single message (e.g., `@answer last:1') If there is a Reply-to: field in the message you are @answer'ing, 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). `include' includes the text of the original message in your reply, `noinclude' does not. `sender', `all', `include', and `noinclude' can each be abbreviated (e.g., `@answer i'). Defaults are `sender' and `noinclude', but you can change this by setting your .mail-options (see `help mail-options').
Syntax: @audit
@audit <player>
@audit [<player>] [from <number>] [to <number>] [for <string>]
The first form prints out a list of every object you own, giving each
one's name and object number.
The second form does the same for the named player.
The third form shows the full blown syntax. It prints out objects
owned by the named player (defaulting to yourself if not supplied),
but begins searching the database with the `from' numbered object
(defaulting to #0), and stops searching with the `to' numbered object
(defaulting to the highest numbered object in the database). The
`for' string restricts the search to objects whose names begin with
that string. These search restrictors can be useful if you know the
player does not own any objects below or above a certain number, or if
the player owns so many things as to be confounding.
All forms of @audit print out two kinds of numbers, for example:
#2450 ...
#5582 ...
My First Thing (#7884)
The first two numbers are just to let you know @audit is still
working--you do not own them. The third number is an object you own.
See also `help @prospectus'[1], a slightly different brand of @audit.
Note: The current implementation of @audit uses a property
.owned_objects on the player, for speed. This property is updated at
the time of each object creation and destruction and ownership change.
The verb @auditdb (same args as @audit) actually searches through the
entire database for objects.
See also `help @verify-owned'[2], `help @sort-owned'[3], and
`help @add-owned'[4] for information on maintaining the .owned_objects list.
Usage: @boot[!] <someone> for <reason>
@boot[!] <someone>
If a guest is really bothering you, you can use this command (e.g.,
`@boot Maverick_guest for harassing me in the living room') to
disconnect the guest. If you're in a great hurry, you can omit the
reason, and you'll be prompted for it after the guest is booted.
If you use `@boot!' instead, the guest will be disconnected and no
guest connections from that site will be allowed for one hour.
You should be aware that guest bootings are logged and monitored;
DON'T use this frivolously.
Members of the community group (see `help cg'[1]) are able to boot
non-guest users who are overly disruptive. The same rules apply.
Syntax: @typo [<text>]
@bug [<text>]
@suggest [<text>]
@idea [<text>]
@comment [<text>]
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, @idea/@suggest for any particular brainstorms or
criticisms you might happen to have, and @comment 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.
This MOO apparently has no quota policy. You should talk to an admin to get someone to write a quota policy.
There are a number of commands available to players for building new
parts of the MOO. Help on them is available under the following
topics:
creation[1]
making, unmaking, and listing your rooms, exits, and other objects
topology[2]
making and listing the connections between rooms and exits
descriptions[3]
setting the names and descriptive texts for new objects
locking[4]
controlling use of and access to your objects
Syntax: burn <letter> Destroy the named letter irretrievably. Only players who can read the letter can do this.
Members of the community group handle any social problems that may arise, mediate disputes, assist new players in becoming acclimated to JH, and promote community harmony. They have the ability to boot characters from the MOO, limit access from remote sites, check network connections, and use related commands that may be useful when dealing with problematic situations. They can also help if you forget your password, need to change your email address, or have a problem using the MOO. @911 (also called @helpme) pages members of the CG who are on-line. Please use this when problems occur. (There is help on this command.) If you have a complaint about a member of the CG and don't feel comfortable bringing it directly to that person or to the group as a whole yourself, please talk to another member of the CG. If even that would be uncomfortable, speak to one of the steering committee members. If there are no members of the CG on-line, you can send mail to the *Community-Group mailing list (*cg). Current members: Wizard.
Your `character' is you, for most intents and purposes; it represents
your presence here at JHM. Use it wisely; see `help user-policy' for
some information on what's expected of you.
CUSTOMIZING CHARACTERS
----------------------
There are a number of commands for modifying various characteristics
of the object representing you in the MOO. Help on them is available
in the following topics:
@describe[1]
setting what others see when they look at you
@gender[2]
changing your character's gender
@password[3]
changing your password
@rename[4]
changing your name and/or aliases
@linelength[5]
adding word-wrap to the lines you see
Syntax: @check <options>
where <options> is one or more of:
o the number of lines to be displayed
o a player's name, someone to be "trusted" during the assignment
of responsibility for the message.
o a player's named prefixed by !, someone not to be "trusted".
Used when you are suspicious about the origin of some of the messages
your character has just heard.
Output from @check is in columns that contain, in order, the monitor's
best guess as to:
o what object the message came from,
o what verb on that object that was responsible,
o whose permissions that verb was running with, and
o the beginning of the actual message.
@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.
Usage: @current-object
@current-object <ref>[..]
@current-object <base>[<ref>[..]]
The @current-object (@co) command is used to set your current
object--an object referred to as _ in commands. For more information
on how to use the current object, see `help current-object'[1].
With no arguments, the command just tells you what your current object
is.
If an argument is given, it indicates the object to go to, beginning
with an optional `base object' and continuing with a series of
references. (If a base is given, no references need follow.) The
base object, if present, is matched as an ordinary object. For
example, "@co $jtext" would set your current object to the Jtext
Dispatcher.
The <ref> segments are mostly properties. For example, "@co
$jtext.link" would set your object to the Link Dispatcher Tag.
If no base is identified, the current object you're already using is
used as the base. For example, after typing the previous command, you
could type "@co .preceding" to change your current object to
$jtext.link.root, the generic preceding link tag.
In addition to property references, there are two special kinds of
<ref> segments for navigation through the object hierarchy. One
of them is ".<", and it works by retracing the steps by which your
current object was determined. For example, again following the
preceding commands, "@co .<" would take you back to the Link
Dispatcher Tag.
Finally, the ".^" <ref> segment gets you the parent of the
current object. Continuing the example, "@co .^" would bring you to
the root class, the parent of the link dispatcher tag.
As indicated, any number of references can be combined; for example,
"@co $jtext.link.preceding.<.<.<.string_utils.^" would be an
exceedingly complicated way to get your current object to be the
generic utilities.
Help is available on the following general topics:
introduction[1]
what's going on here and some basic commands
index[2]
index into the help system
characters[3]
setting characteristics of yourself
movement[4]
moving yourself between rooms
communication[5]
communicating with other players
manipulation[6]
moving or using other objects
miscellaneous[7]
commands that don't fit anywhere else
building[8]
extending the MOO
programming[9]
writing code in the MOO programming language
editors[10]
editing text and code in the MOO
@options[11]
customizing your MOO environment
@pagelength[12]
what to do if lines scroll off your screen too fast
@linelength[13]
what to do if lines are truncated
Type 'help <topic>' for information on a particular topic.
Syntax: @typo [<text>]
@bug [<text>]
@suggest [<text>]
@idea [<text>]
@comment [<text>]
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, @idea/@suggest for any particular brainstorms or
criticisms you might happen to have, and @comment 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.
Usage: @quota [<someone>] Each player has a limit as to how much database disk space e may consume with their objects, properties, and verbs. Objects are periodically measured (and can have their measurement forced---see help @measure). If a player is over quota after a measurement, e will not be able to @create any objects, use @copy, @verb, or @property to grow any objects. Existing properties and verbs may be edited/changed at will, even while over quota. The @quota command prints out your current quota and measured usage. If you have more than one character, it will summarize all your other characters' usage as well. @quota <player> will print out the quota and usage of another player. [Note: you will not be able to obtain second character information for another player; whether primary or secondary character, the @quota display will only show one character's quota.] @quota prints a time of measurement in its display. This is the time of the oldest measurement out of all your objects. For example, if you @measure three of your objects right now, those individual times get updated, but if you still have a couple of objects with older measurements, that older time will be the time printed by @quota. This is confusing to many people.
There are several commands available to allow you to communicate with
your fellow MOOers. Help is available on the following
communication-related topics:
say[1]
talking to the other connected players in the room
whisper[2]
talking privately to someone in the same room
page[3]
yelling to someone anywhere in the MOO
emote[4]
non-verbal communication with others in the same room
gagging[5]
screening out noise generated by certain other players
news[6]
reading the most recent set of general announcements
@gripe[7]
sending complaints to the admins
@typo/@bug/@idea/@suggest[8]
sending complaints/ideas to the owner of the current room
whereis[9]
locating other players
@who[10]
finding out who is currently logged in
mail[11]
the MOO email system
security[12]
the facilities for detecting forged messages and eavesdropping.
Members of the community group handle any social problems that may arise, mediate disputes, assist new players in becoming acclimated to JH, and promote community harmony. They have the ability to boot characters from the MOO, limit access from remote sites, check network connections, and use related commands that may be useful when dealing with problematic situations. They can also help if you forget your password, need to change your email address, or have a problem using the MOO. @911 (also called @helpme) pages members of the CG who are on-line. Please use this when problems occur. (There is help on this command.) If you have a complaint about a member of the CG and don't feel comfortable bringing it directly to that person or to the group as a whole yourself, please talk to another member of the CG. If even that would be uncomfortable, speak to one of the steering committee members. If there are no members of the CG on-line, you can send mail to the *Community-Group mailing list (*cg). Current members: Wizard.
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 standard pronoun substitutions (with respect to the player) are made on each message before it is printed; see `help pronouns'[1] for details. The default message is given in brackets after each name below: @empty [%Ts %t:(is) empty.] Printed in place of the contents list when the container is empty. @put [%Nd %n:(puts) %dd in %id.] Printed to the player and the room when an object is successfully placed in a container. @put_fail [You can't put %dd in that.] Printed when the player fails to put an object in a container. @remove [%Nd %n:(removes) %di from %id.] Printed to the player and the room when the player succeeds in removing an object from a container. @remove_fail [You can't remove that.] Printed to the player when the player fails to remove an object from a container. The following messages only apply to openable containers (descendants of $openable_container): @open [%Nd %n:(opens) %td.] Printed to the player and the room if the player successfully opens the container. @open_fail [You can't open that.] Printed to the player who cannot open the container. @close [%Nd %n:(closes) %dd.] Printed to the player who closes a container.
Containers are objects that allow you to store other objects inside
them. The following help topics cover verbs that can be used with
containers:
put[1]
putting an object into a container
remove[2]
taking an object out of a container
You can make a container by creating a child of the standard
container, $container (see `help @create'[3]).
Openable containers may be open or closed, using the verbs `open
container' and `close container'. Openable containers have a separate
lock to determine if a player may open them. See the following help
topics:
@lock_for_open[4]
setting the lock for opening a container
@unlock_for_open[5]
clearing the lock
You can make an openable container by creating a child of
$openable_container.
Containers have a large number of messages which get printed when
players act upon them. See `help container-messages'[6] for more
information.
Openable containers have opacity. See `help @opacity'[7] for more
information.
Syntax: @contents object A quick way to find out the contents of an object. Prints out the names and object numbers of all direct contents. This can be useful when you need to refer to something by object number because something is wrong with its aliases. Example: @contents here The Entrance Hall(#19) contains: Strasbourg Clock(#71) mirror at about head height(#7444)
Portions of this database are derived from the LambdaCore
distribution, available for anonymous ftp at parcftp.xerox.com. The
following copyright notice applies to new and derived works within
this database.
Copyright 1991, 1992, 1993, 1994, 1995 by Ken Fox.
All Rights Reserved
Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted,
provided that the above copyright notice appear in all copies and that
both that copyright notice and this permission notice appear in
supporting documentation.
KEN FOX DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING
ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL
KEN FOX BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR
ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS,
WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
SOFTWARE.
Portions of this database are derived from the LambdaCore
distribution, available for anonymous ftp at parcftp.xerox.com. The
following copyright notice applies to new and derived works within
this database.
Copyright 1991, 1992, 1993, 1994, 1995 by Ken Fox.
All Rights Reserved
Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted,
provided that the above copyright notice appear in all copies and that
both that copyright notice and this permission notice appear in
supporting documentation.
KEN FOX DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING
ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL
KEN FOX BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR
ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS,
WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
SOFTWARE.
Syntax: @count Prints out the number of objects you own. Do not be surprised if this is one larger than you think it should be: remember that your player object is owned by you as well, even though you didn't create it in the usual way.
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. Help is available on these commands in the
following topics:
@dig[1]
conveniently building new rooms and exits
@create[2]
making other kinds of objects
@recycle[3]
destroying objects you no longer want
@quota[4]
determining how many more objects you can build
@count[5]
determining how many objects you already own
@audit[6]
listing all of your objects
@move[7]
moving your objects from place to place
Your `current object' is an object that you can refer to in most
commands without using its name, just by using the symbol "_". It's
intended primarily for programming.
For example, you can type
@co $jtext.link
@d _:
and get a list of verbs defined on the link dispatcher tag.
In addition, if your .eval_env property (see `help eval'[1]) sets _ to
player.current_object, you can use it in evaluations. The default
.eval_env includes this binding. So, to continue the example:
>;_:dname()
=> "the link dispatcher tag"
A stack is kept of the current objects you've been using, so you can
change your current object for a while and then switch back to the
previous one without needing to identify it again.
To find out how to set or view your current object, read the following
help topics:
@currentobject[2]
Set current object, or find out what it is.
@pushobject[3]
Push a current object onto the stack.
@popobject[4]
Return to the previous current object.
@swapobject[5]
Switch between current and previous object.
Usage: @current-object
@current-object <ref>[..]
@current-object <base>[<ref>[..]]
The @current-object (@co) command is used to set your current
object--an object referred to as _ in commands. For more information
on how to use the current object, see `help current-object'[1].
With no arguments, the command just tells you what your current object
is.
If an argument is given, it indicates the object to go to, beginning
with an optional `base object' and continuing with a series of
references. (If a base is given, no references need follow.) The
base object, if present, is matched as an ordinary object. For
example, "@co $jtext" would set your current object to the Jtext
Dispatcher.
The <ref> segments are mostly properties. For example, "@co
$jtext.link" would set your object to the Link Dispatcher Tag.
If no base is identified, the current object you're already using is
used as the base. For example, after typing the previous command, you
could type "@co .preceding" to change your current object to
$jtext.link.root, the generic preceding link tag.
In addition to property references, there are two special kinds of
<ref> segments for navigation through the object hierarchy. One
of them is ".<", and it works by retracing the steps by which your
current object was determined. For example, again following the
preceding commands, "@co .<" would take you back to the Link
Dispatcher Tag.
Finally, the ".^" <ref> segment gets you the parent of the
current object. Continuing the example, "@co .^" would bring you to
the root class, the parent of the link dispatcher tag.
As indicated, any number of references can be combined; for example,
"@co $jtext.link.preceding.<.<.<.string_utils.^" would be an
exceedingly complicated way to get your current object to be the
generic utilities.
People who have superuser (wheel) access to the MOO database for maintenance purposes. This is to be used for hacking on core objects, fixing bugs, or making global changes related to programming projects, and should not be used for non-technical purposes. If you have questions, comments, or suggestions about the core database, send mail to the *DB-Issues mailing list. If you think you've found a bug in the core database, send mail to the *Bug-Reports mailing list. If you think you've found a security hole, send mail to the *Security mailing list, which is only readable to members of the DB group. Current members: Wizard.
Syntax: decrypt <note> Removes any restriction on who may read the named note or letter. Only the owner of a note may do this.
Syntax: delete <line-number> from <note> Removes a single line of text from a note. The first line of text is numbered 1, the second is 2, and so on. Only the owner of a note may do this.
Syntax: @describe <object> as <description> Sets the description string of <object> to <description>. This is the string that is printed out whenever someone uses the 'look' command on <object>. To describe yourself, use 'me' as the <object>. Example: Munchkin types this: @describe me as "A very fine fellow, if a bit on the short side." People who type 'look Munchkin' now see this: A very fine fellow, if a bit on the short side. Note for programmers ==================== The description of an object is kept in its .description property. For descriptions of more than one paragraph, .description can be a list of strings.
Most objects have one or more descriptive pieces of text associated
with them; these texts are printed under various circumstances
depending on the kind of text. For example, every object has a
'description' text that is printed whenever a player looks at the
object. The following help topics discuss the commands for
manipulating these descriptive texts on your objects:
@rename[1]
setting the name and aliases of your objects
@describe[2]
setting what others see when they look at your objects
messages[3]
listing and setting the other descriptive texts on an object
The doing message is used to tell others what you are doing (logical enough). You have a default doing message and a temporary doing message. They are set in different ways. Your doing message shows up in @who under the `Doing/Idling' column, except when you've idled. TEMPORARY DOING MESSAGE ----------------------- Your temporary doing message is set using the `doing' verb. For example: >doing hacking [doing: hacking] In this example, your doing message is set to "hacking." To clear the message, just use `undoing'. Your doing message is superceded by your idle message (see `help idle') when you are idle. DEFAULT DOING MESSAGE --------------------- Your default doing message is `@doing', and is used like other messages (see `help messages'). If you have no temporary doing message, this message will show up wherever doing messages do.
Syntax: drop <object>
throw <object>
Remove an object you are carrying from your inventory and put it in
your current room. Occasionally you may find that the owner of the
room won't allow you to do this.
Syntax: @dump <object> [with [id=#<id>] [noprops] [noverbs] [create]]
This spills out all the properties and verbs on an object, calling
suspend at appropriate intervals.
o id=#<id> -- specifies an idnumber to use in place of the
object's actual id (for porting to another MOO)
o noprops -- don't show properties.
o noverbs -- don't show verbs.
o create -- indicates that a @create command should be generated and
all of the verbs be introduced with @verb rather than
@args; the default assumption is that the object
already exists and you're just doing this to have a
look at it.
Usage: @edit <object>:<verb-name> [<args>]
@edit <object>.<prop-name>
@edit <object>
Enter the appropriate editor for the specified target. The first form
is handled by the verb editor (and is available only to programmers);
the second is handled by either the note editor or the list editor;
and the third is handled in an object-dependent way. (For notes, this
translates to editing <object>.text; for most other objects, it
translates to editing <object>.description.)
One can always enter an editor by teleporting to it, or you can use
one of the commands provided
@edit <object>:<verb> invokes the Verb Editor (edits verb code)
@notedit <note_object> invokes the Note Editor (edits note text)
@notedit <object>.<prop> invokes the Note Editor (edits text property)
@send <list of recipients> invokes the Mailer (edits a mail msg)
@answer [<msg_number>] [<flags>...] invokes the Mailer (edits a reply)
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, they are better than nothing.
There is a generic editor that provides basic editing commands that
are applicable to all editors. Documentation for these commands can
be obtained by typing `help <topic>' within the editor:
abort emote/: pause send (M)
also-to (M) fill prev showlists (M)
compile (V) insert print (M) subject (M)
copy join quit subst
delete list ranges to (M)
done move save (N) what
edit (V,N) next say/" who (M)
In addition, individual editors provide their own additional commands
for loading text from places, saving text to places, and various other
specialized functions which are denoted in the above list with
(M),(N),(V) according as they apply to the mail editor, the note
editor, or the verb editor, respectively.
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
anything left there for sufficiently long will eventually 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
suppresses those annoying "Line n added." or "Appended..." messages
that one gets in response to 'say' or 'emote'. This is useful if you're
entering a long list of lines, perhaps via some macro on your client,
and you don't want to see an equally long list of "Line n added..."
messages. What you do want, however is some indication that this all
got through, which is why the "." command is an abbreviation for insert.
eval_subs
Enables the verb editor to process your eval_subs property when
compiling your verb. See `help eval' for more information about
the eval_subs property.
There will be more options, some day.
Syntax: @eject <object>
@eject <object> from <place>
This command is used to remove unwanted objects from places you own.
Players thus removed are unceremoniously dumped in their homes (unless
that's this room, in which case they are dumped in the default player
starting place). Other kinds of objects are checked for a .home
property and sent there if possible, otherwise they get thrown into
#-1. 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.
"@eject ... from me" suffices to get rid of some unwanted object in
your inventory.
See `help room-messages'[1] for a list of messages one can set
regarding the @eject command.
The MOO email system allows you to send and receive messages to and
from other players. It provides commands to view and manage your own
collection of saved messages and, in addition, to browse through other
collections that may be available (e.g.,archives of public mailing
lists). Help is available on the following commands:
@mail [1]
seeing a table of contents for a collection of email messages
@read [2]
reading individual messages
@next [3]
reading the 'next' message
@prev [4]
reading the 'previous' message
@send [5]
composing and sending a message to other players
@answer [6]
replying to one of the messages in a collection
@forward [7]
resending one of the messages in a collection somewhere else
@forward-me [8]
resending a message to your email address
@rmmail [9]
discarding some subset of a collection
@unrmmail [10]
undoing the most recent @rmm on a collection
@renumber [11]
renumbering the messages in a collection
@mail-options[12]
describing and setting various customization flags
For viewing collections other from your own, the following commands
are useful:
@rn [13]
list those collections that have new messages on them
@subscribe [14]
indicate that you want @rn to report on a given collection
and add yourself to its .mail_notify list
@skip [15]
ignore any remaining new messages in a given collection
@unsubscribe[16]
ignore a given collection entirely from now on and remove
yourself from its .mail_notify list
Two other related topics:
mail-forwarding[17]
describes mail forwarding
message-sequences[18]
describes message-sequences arguments to @mail, @read, @rmm, and @answer.
Syntax: emote <anything> ...
:<anything> ...
::<anything> ...
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.
The alternate form, '::' (less commonly 'emote :'), does not insert
the space between the player name and the text.
Examples:
Munchkin types this:
:wishes he were much taller...
Everyone in the same room sees this:
Munchkin wishes he were much taller...
Munchkin types this:
::'s eyes are green.
Everyone in the same room sees this:
Munchkin's eyes are green.
Syntax: encrypt <note> with <key-expression> Restricts the set of players who can read the named note or letter to those for whom the given key expression is true. See `help keys'[1] for information on the syntax and semantics of key expressions. Only the owner of a note may do this.
Syntax: @entrances Prints a list of all recognized entrances to the current room (but only if you own the room). A recognized entrance is one whose use is not considered to be teleportation.
Syntax: erase <note> Deletes all of the text written on a note or letter. Only the owner of a note may do this.
Syntax: examine <object>
exam <object>
Prints several useful pieces of information about the named object,
including the following:
o its full name, object number, and aliases
o its owner's name
o its description
o its key expression (if it is locked and if you own it)
o its contents
o the 'obvious' verbs defined on it
[Note to programmers: the 'obvious' verbs are those that can be
invoked as commands and are not specified by the :hidden_verbs verb.
The default definition of "hidden" is "not readable". You can
override this definition with a :hidden_verbs verb that gets the
default list with pass(@args) and then alters that list.]
Syntax: @examine <object>
@exam <object>
Prints several useful pieces of information about the named object,
including the following:
o its full name, aliases, and object number
o its owner's name and object number
o its description
o its key expression (if it is locked and if you own it)
o its contents and their object numbers
o the 'obvious' verbs defined on it
[Note to programmers: 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 (see `help @chmod'[1]) or, if it shouldn't
be used as a command, give it 'args' of 'this none this' (see `help @args'[2]).]
Several kinds of messages can be set on an exit object (see `help messages'[1] for instructions on doing so); 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; see `help pronouns'[2] for details. The default message is given in brackets after each name below: @leave [] Printed to the player just before they successfully use the exit. @oleave [has left.] Printed to others in the source room when a player successfully uses the exit. @arrive [] Printed to the player just after they successfully use the exit. @oarrive [has arrived.] Printed to others in the destination room when a player successfully uses the exit. @nogo [You can't go that way.] Printed to the player when they fail in using the exit. @onogo [] Printed to others when a player fails in using the exit.
Syntax: @exits Prints a list of all conventional exits from the current room (but only if you own the room). A conventional exit is one that can be used simply by uttering its name, like 'east'.
Features are objects that provide you with commands not covered by the ordinary player objects. The advantage of using features is that you can mix and match the things you like; whereas if you like a command that's defined on a player class, you have to also get all the commands it defines, and all the commands its ancestors define. You can list your features (see `help @features'[1]), and add or remove features from your list (`help @add-feature'[2] and `help @remove-feature'[3]). Note to programmers: In order to be available for general use as a feature, an object must have a verb or property named "feature_ok" which returns a true value. When a feature is added to a player's features list, feature:feature_add is called, if it exists, with the player in question as its argument. Likewise, when a feature is removed, feature:feature_remove is called.
Usage: @features [<name>] [for <player>] List all of <player>'s features matching <name>, or all of <player>'s features if <name> is not supplied. <player> defaults to you. See `help features' for more information.
"follow <player>" will cause you to follow <player> everywhere <player> goes, as long as you can go there too, and <player> uses a valid exit. "unfollow <player>" will stop you from following <player> if <player> is in the room. "lose <player>" will stop a player from following you, if you're in the same room. "following" will show you who you are currently following, should they be in the room, or happen to come into the room. "followers" will tell you who's following you, and if you can be followed. "followers on" will allow others to follow you, and announce it to the room. "followers off" will not allow others to follow you, and announce it to the room.
Syntax: @forward <msg> [on *<collection>] to <recipient> [<recipient>...] Syntax: @resend <msg> [on *<collection>] to <recipient> [<recipient>...] Both of these commands take the indicated message in your (or some other) message collection, and sends it on to the indicated recipients in some form. @forward sends an entirely new message whose body is the original message (both headers and body). @resend sends the original message, but with a header containing the lines From: original-sender To: original-recipients... Resent-By: you Resent-To: new-recipients... If you prefer to have yourself in the From: line of messages you @resend, set the mail option `resend_forw (see `help @mail-options'). In this case, the message will instead have a header containing the lines From: you To: new-recipients... Original-From: original-sender
Syntax: @forward-me <msg> [on *<collection>] Takes the indicated message in your (or some other) message collection, creates a new message whose body is the original message (both headers and body) and sends it to your registered email address.
Syntax: @gag <player or object> [<player or object>...] Add the given players to your 'gag list'. You will no longer see any messages that result from actions initiated by these players. In particular, you will not hear them if they try to speak, emote, or whisper to you. See `help gagging'[1] for an explanation of gagging in general. Example: Munchkin types: @gag Grover and no longer hears anything that Grover says. What a relief! If you specify an object, then any text originating from that object will not be printed. Example: Noisy Robot prints "Hi there" every 15 seconds. In order to avoid seeing that, Munchkin types: @gag Noisy and no longer hears that robot! (Munchkin must be in the same room as Noisy Robot for this to work, or know its object number.)
Syntax: @gag! <player> [<player>...] This is just like @gag, except that the players in question are added to your `NOISY gag list'. You will no longer see any messages that result from actions initiated by these players and, moreover, announcements will appear to other players in the room indicating that you have these players gagged. Example: Munchkin types: @gag Grover Grover types: "Munchkin is a <expletive deleted> Other players see: Grover says, "Munchkin is a <expletive deleted>" **GAG: Grover is gagged by Munchkin.
Syntax: @gag-announce [default] [disable|
enable|
minwait is <number>|
suspend is <number>]
@gag-announce use default
This command displays/sets the parameters for announcements of `noisy
gags' for this room. See `help gagging' for a description of noisy
gags.
Without arguments this simply gives the current parameters for gag
announcements for this room.
Specifying `disable' entirely disables gag announcements.
Specifying `enable' enables gag announcements.
`minwait' is the minimum interval (seconds) before a
particular announcement can be repreated.
`suspend' is how long the gag announcer suspends
between announcements.
Specifying `default' displays/changes the parameters for the generic
room instead.
Specifying `use default' indicates that this room should use the
parameters for the generic room.
Syntax: @listgag
@gaglist
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. See `help
gagging'[1] for an explanation of gagging in general.
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 listed below;
detailed help is available on each of them:
@gag[1]
add one or more players to your gag list
@ungag[2]
remove a player from your gag list
@listgag[3]
list the players you currently have gagged
The following commands are identical to the foregoing except that they
concern your "noisy gag" list:
@gag![4]
add one or more players to your NOISY gag list
@ungag![5]
remove a player from your NOISY gag list
@listgag![6]
list the players you currently have NOISY-gagged
The noisy gaglist is for those situations where you feel it necessary
NOT ONLY to gag a player but to also make it apparent to others in the
room that you indeed have this player gagged. If a player you have
noisy-gagged makes an utterance in your presence, those in the room
who do not already have this player gagged will see an announcement to
the effect that you have him/her gagged.
Syntax: @listgag
@gaglist
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. See `help
gagging'[1] for an explanation of gagging in general.
Every object on the MOO has a "gender" that determines certain
grammatical properties of the object, such as what pronouns to use
when referring to the object. "Gender" on this MOO is slightly
different than the normal definition of gender; it encompasses gender
(male, female, neuter, etc), number (singular or plural), and person
(first, second, or third). Here are the genders available to users
(to examine or change your gender, see `help @gender'[1]):
Spivak -- e, em, eir, eirs, emself.
male -- he, him, his, himself.
female -- she, her, hers, herself.
either -- s/he, him/her, his/her, his/hers, (him/her)self.
splat -- *e, h*, h*s, h*self.
none -- No pronouns; your name is always used.
The above are all singular, third person genders. Here are the other
genders:
egotistical -- First person singular: I, me, my, mine, myself.
royal -- First person plural: we, us, our, ours, ourself.
second -- Second person singular: you, your, yours, yourself.
second_plural -- Second person plural: you, your, yours, yourself.
neuter -- Third person singular: it, its, itself.
plural -- Third person, plural: they, them, their, theirs, themselves.
Syntax: @gender <gender>
@gender
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.
Syntax: take <object>
get <object>
take <object> from <container>
get <object> from <container>
remove <object> from <container>
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 (see `help containers'[1]) into your inventory. As before,
sometimes the owner of an object will not allow you to do this.
This document is intended to help you get started running a new MOO
with a JHCore database. It doesn't cover everything, but it should be
enough to keep you occupied for a while.
Note that this document assumes you have some knowledge of MOO use and
programming, or at least setting properties. Without it, you will
lose horribly.
BEFORE YOU START
----------------
For a JHCore database to work well, you'll need a higher tick limit
than the default. If you're still running a server version earlier
than 1.7.7, you'll need to set this in options.h before compiling; in
newer versions you can just set properties on $server_options in the
database. (See the LambdaMOO programmer's manual for more on this.)
The values we use at JHM are:
Max ticks (foreground): 50000
Max ticks (background): 30000
You may also need a higher seconds limit.
We also recommend compiling with OUTBOUND_NETWORK if you can; besides
enabling mail sending (which allows autoregistration), it allows for
access to various other network services we think are cool. In
addition, we should eventually provide server patches to allow
listening on multiple ports, and database code to use it.
STARTING THE DATABASE
---------------------
Once you have a MOO compiled and a JHCore database, you can start it
up. You probably want to fetch JHCore.db and rename it to something
else; we'll call it `MyMOO.db' for now. Assuming you have the MOO
executable (moo) and your database file (MyMOO.db) in your current
directory, you can type `./restart MyMOO 1234' to start it up on port
1234. For more detail, see the `README' file in the LambdaMOO source
distribution.
Once it's finished loading the database (you can watch `tail -f
MyMOO.log' if you're anxious), you should telnet or otherwise connect
to your host and port, and `connect Wizard' to log in.
Since the database doesn't initially require a password to log in as
Wizard, you should set your password immediately; just type `@password
<new-password>'. Then you may want to @rename and @describe
yourself.
LETTING PEOPLE LOG IN
---------------------
It takes a surprising amount of setup before other people can log in,
but most of it is just setting values for properties.
First, you almost certainly want to change the message people see when
logging in. Just `@edit $login.welcome_message'. (If your client
supports local editing, you probably want to do `@editoption +local'
first.)
You have four options for letting people log in:
o (semi-)anonymous guest characters (can be used with any of the others)
o autocreation at login
o registration (requires guests)
o manual player creation by wizards
Each of them requires a separate piece of setup.
Guests
======
If you want people to be able to log in as guests, you need to create
at least one:
>@make-guest guest
Created the guest (#415).
(Before doing that, you may want to set $guest.default_gender; we use
"spivak", but "neuter" is a popular choice.)
Once you have a guest, you can make additional guests with specific
adjectives--for example,
>@make-guest example
Created an example guest (#416). Now don't forget to @describe em as
something.
There are three more things you may well want to change about guests.
First, by default, guests' sites will be shown to anyone who looks at
them. To turn this off, set $guest.show_site to 0.
Second, $country_db optionally provides the following behavior: When
people log in as "guest", the connection system can try to match their
connect domain using $country_db, and for example connect ".uk" users
to "the British guest". (Guests of this type are created
automatically.) To turn this on, just set $login.sitematch_guests to
1. For more information about customizing this, see `help
$country_db'[1].
Finally, guests are descendants of $prog, the generic programmer, so
they can read code and list properties and such (although they can't
create anything). To change this, just @chparent $guest to a
different parent, like $player.
Autocreation
============
If you set $login.create_enabled to 1, people will be able to create
new characters from the login screen, with no registration address.
We don't recommend this at all, but if you're bent on anonymity, this
is your option.
AutoRegistration
================
If you have guest characters and outbound network connections, you can
allow people logged in as guests to register automatically for
characters. If you want to allow this, you need to set up $network
for outgoing mail (see below), and set $guest.registration_ok to 1.
If not, you may want to set the @noregister message on $guest to
something more specific than the default.
If you use autoregistration, you may want to maintain a list of sites
from which automatic registration is not allowed. (For example, some
schools provide their students with one account for each computer
science class they take.) Use the `@spooflist' command to add a
domain to this list, which is stored in $login.spooflist.
@Make-player
============
If you have no registration and no autocreation, the only way to make
new characters will be the @make-player command (on $wiz and
$feature->community group). Setting up $network for outgoing mail
(see below) will make this easier, as mail can be sent automatically
to the new user.
In addition, you'll probably want to change $login.registration_string
so it doesn't make false claims. If you want to include an address to
send to for characters, set $login.registration_address to that
address, and use "%e" in the registration string to refer to that
address. For example:
>;$login.registration_address = "mymoo-registration@mymoo.mydomain.net"
>;$login.registration_string = "Automatic registration is not allowed.
Send mail to %e explaining why you want a character."
THE NETWORK
-----------
The $network object provides various facilities related to networking;
most importantly for your initial setup, it handles outgoing mail
(through $network:sendmail). Here are some properties you should set
before going much of anywhere:
.MOO_name
-- your moo's name--for example, "MyMOO"
.site
-- your moo's site--for example, "mymoo.mydomain.net"
.port
-- your moo's port--for example, 1234
.postmaster
-- someone who will handle bounced mail and such
.mail_domain
-- a mail domain to give for reply addresses (used in
$network:reply_address, which see). If you don't have incoming
mail (we don't either), you might as well leave this as is.
And finally:
.active
-- signals that $network is set up and (hopefully) usable for mail
ADMINISTRATION
--------------
The JHCore admin system is a way to make certain
tasks/responsibilities/privileges available to groups of people
without requiring that those people be wizards. The philosophy is
that there are several roles that wizards have traditionally been
required to play, and that those people who are best suited to some of
the roles are not interested in performing all of them. Allocating
permissions to administrative groups by their functions provides a way
to specify the role(s) people hold.
Our administration system divides into three main groups:
o The Steering Committee, which makes decisions about broad goals and such;
o The Community Group, which tries to avoid or resolve social conflicts;
o The Tech Group, composed of three subgroups that handle technical issues.
This is a gross oversimplification; you can look at each of them
(@kids $admin) to get more description.
You'll probably want to customize this. Simple customizations include
changing the descriptions and the names (don't forget to describe the
associated mailing lists!); you might go on to moving commands around
(between $wiz and $feature->community, most likely); or you might
just want to get rid of this complex system. It should be fairly
simple to reduce the administration system to a simple wizard-rule
system a la LambdaCore, by recycling admin groups, changing $admin,
and probably hacking some code.
QUOTA
-----
MOO Quota is a person's usage quota. The system defaults to using
byte quota. That is, a person has a specific number of bytes that he
or she can use on the MOO. The person cannot create objects, add
verbs, or add properties he or she is over quota.
@quota (see `help @quota'[2]) is the command used to display or set a
person's quota. @measure is used to measure objects (in bytes). The
verb you use to start the measurement task (which measures objects in
the background) is $quota_utils.byte:measurement_task(). However,
since the default quota system is byte, this verb should already be
running.
In order to switch to object quota (which is not recommended), you can
kill the measurement task and set $quota_utils to $quota_utils.object.
Then you have to run $quota_utils:initialize_quota().
Please note that, for whichever system you use, the default quota is 0
(bytes or objects). You can set this by setting
$quota_utils.default_player_quota and running
$quota_utils:initialize_quota (which sets everyone's total quota to
the value in .default_player_quota, so don't do this on a MOO that has
players). Setting .default_player_quota without running
$quota_utils:initialize_quota simply sets the default quota for all
players created from that point.
Also, you will want to edit `help quota-policy'[3] to reflect your
MOO's quota policy. @add-feature the documentation feature and use
@helpedit to edit help.
PORTING
-------
There's a lot in JHM and elsewhere that you might want but that JHCore
doesn't provide. For general information about porting, you should
check the MOO-Cows "Newbie Arch-Wizard FAQ". However, the site from
which you retrieved JHCore should also have a set of code modules that
are easily ported into a JHCore database; be sure to check these out.
MISCELLANEOUS
-------------
You probably want to change the name of the newspaper. Just `@edit
$news.description'. If you like, you can `@edit $help.news', too.
By default, JHCore allows only a small set of "genders" (which
actually cover person, number, and gender) for players. The set of
defined genders is in $gender_utils.genders;
$gender_utils.player_genders holds the list allowed for players. You
may want to expand (or contract!) this list.
IN CLOSING
----------
If you're using JHCore, we'd like to hear from you. JHM is at
jhm.ccs.neu.edu, port 1709; you can log in as a guest and request a
character if you don't have one already. Please feel free to send
mail to the *jhcore list--report bugs, provide fixes, ask for help, or
just tell us about your MOO.
Syntax: give <object> to <player>
hand <object> to <player>
Move an object from your contents to that of another player. This
doesn't change the ownership of the object. Some players may refuse
to accept gifts and some objects may refuse to be given.
Usage: go <direction> ...
go to <location>
The first form moves in the given directions in order, taking you
through many rooms in a single command. The second form will try to
figure out a path that will bring you to your desired destination.
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>' or 'go to <location>' to move;
this is particularly useful if you know you're going to type several
movement commands in a row (see `help go').
Other commands for moving about include:
walk[1]
going to a particular place
join[2]
joining a particular person
home[3]
returning to the place you live
Usage: @grant <object> to <recipient> (used by owner)
@grant <object> to me (used by recipient)
Change the ownership of an object, including all properties and verbs
owned by the owner. This is a two-step process: First the owner
offers it to the recipient, then the recipient accepts it.
All properties and verbs on the object that are owned by its owner
will be given to the recipient. This means you should probably be
careful in accepting an object. In addition, !c verbs owned by this
object's owner will change hands on all descendants.
Wizards can @grant objects in one step.
Syntax: @gripe <anything> ... Puts you into the MOO mail system to register a complaint (or, conceivably, a compliment) with the wizards. The rest of the command line (the <anything> ... part) is used as the subject line for the message. More information on using the MOO mail system is given once you're in it. You may hear back from the wizards eventually; see `help @mail'[1] for how to read their reply. Example: Munchkin types: @gripe The little bird "How come I can't ever see the little bird in the cuckoo clock? " -- A frustrated player send and, somewhat later, the wizards reply with a note about being sure to look while the clock is chiming.
Syntax: give <object> to <player>
hand <object> to <player>
Move an object from your contents to that of another player. This
doesn't change the ownership of the object. Some players may refuse
to accept gifts and some objects may refuse to be given.
Syntax: help
help <topic>
help index
Print out entries from the online documentation system. The commands
`?' and `information' (usually abbreviated `info') are synonyms for
`help'.
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; if there
is no topic exactly matching the name you give, the help system checks
for topics for which the name is a prefix, perhaps with the addition
or omission of an initial `@', or perhaps with some confusion beween
dashes (-) and underscores (_), e.g.,
`bui' instead of `building',
`who' instead of `@who',
`@wri' instead of `write',
`add_ent' instead of `@add-entrance',
`unlock-' instead of `@unlock_for_open'
If the abbreviation you give is ambiguous, you will be presented with
a list of the matching complete topic names.
The `help index'[1] commands prints out a list of indices for the
various help databases. Each index gives a list of topics available
on that database. It is sometimes easier to find the topics you're
interested in this way, rather than tracing through the chain of cross
references.
For programmers, the help system provides the following additional forms:
help object:verbname -- prints any documentation strings that are present
at the beginning of the program for that verb.
help $<whatever>_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.
help builtin() -- prints documentation from the programmers manual
about the named primitive, for example length()
For information about how the help system itself works and about how
to associate local help databases with specific rooms or player
classes, see `help $help'[2].
The JaysHouse help system attempts automatic conversion of help texts
written in a certain format into jtext, the rich/hypertext format
under development here. The format is heavily based on certain
conventions found in LambdaCore help documents, so most of them could
be automatically converted. This document details the expected
format.
HELP TEXT ELEMENTS
------------------
The JaysHouse help format is designed to be highly readable in raw
format--it is derived from the texts that are presented verbatim to
users on other MOOs. However, it also includes (or more rigorously
defines) constructs that a machine can translate into paragraphs,
headers, itemized lists, definition lists, hypertext links, and
plaintext.
Blank Lines
===========
Blank lines separate paragraphs from headers from definition lists
from itemized lists from plaintext. The term "blank line" means a
completely empty line; a line composed entirely of whitespace doesn't
count. This is mostly for efficiency.
At some point there may be a "help text compiler", which will attempt
to parse a text written in this format, show you the result, and point
out common problems. A good use of this would be checking for
whitespace lines. Meanwhile, we're just converting help texts on the
fly, and don't want to be printing error messages and such.
Paragraphs
==========
The most common help text element is the paragraph. A paragraph (like
this one) is a single line of text, preceded and followed by blank
lines. Paragraphs should _not_ be linewrapped text. The help system
makes no assumptions about screen width, and you shouldn't either; if
the help text converter finds more than one line of text with no blank
lines in between, it assumes that there's some special formatting
going on. (It will try to recognize headers, definition lists, and
itemized links; if this fails, it formats as plaintext and hopes for
the best.)
Note that a lot of MOO text manipulation systems--for example, the
linewrapping (see `help @wrap'[1]) done for people without special
clients, and the algorithm used to include text in mail replies--make
the same assumption that a line is equivalent to a paragraph, so this
is a good skill to develop even if you're not writing help texts
regularly. And including blank lines between paragraphs in some of
these contexts improves readability.
Hypertext Links
===============
It is possible to embed hypertext links to other help topics within
help text (paragraphs, itemized lists, or definition list
descriptions). A link is marked with a single quote (either
direction), the word "help", a single space, a word containing no
spaces, and a single closing quote. For an example, see this sentence
in the middle of `help help-format'[2]. (If you saw a boxed number
after that link, please note that it was an artifact of jtext output,
rather than a part of the hypertext link format.)
The word after "help" is the name of the help topic to link to. If
the word is enclosed in angle brackets (actually, if it begins with
the "<" character), this piece of text will not be considered a
hypertext link. This is so we can include instructions to type `help
<topic-name>' for more information.
You can also include a similar reference to a project--for example,
`@proj info jtext' or `@proj usa doc' are both relevant to this
document.
Headers
=======
Just above this sentence is a header. A header consists of two lines,
preceded and followed by blank lines. The first line is the text of
the header. The second line should be a string of equals ("=") or
hyphen ("-") characters, of the same length as the header text.
There are four levels of headers available through the help format:
o Level 1: All caps, equals signs (see "standard help text format").
o Level 2: All caps, hyphens (see "help text elements").
o Level 3: Normal text, equals signs (see "headers").
o Level 4: Normal text, hyphens (no example here).
They may, of course, be formatted differently by different clients
that understand jtext.
Sometimes you don't want your first- or second-level header to be in
all caps. You can also indicate header level by replacing the first
"=" or "-" with a numeral between 1 and 6. For example, one of the
headers in this document is represented as:
Help Text Elements
2-----------------
Warning: Many output formats (for example, the in-db line-mode client
and most ASCII HTML displayers) will turn headers into all caps
anyway.
If there is not a header of level 1 at the beginning of a help text,
it will be given a top-level header based on the name of the help
topic.
Itemized Lists
==============
An itemized list is a series of bulleted lines preceded and followed
by blank lines. A "bullet" is recognized by the presence of several
elements at the beginning of a line: more than one space, followed by
one of several bullet characters (currently "-", "o", and "*"),
followed by one or more spaces.
Each line of an itemized list must use the same bullet character and
the same number of spaces before and after.
No nesting of lists is allowed; an item contains only a line of simple
text. It should be possible to include hypertext links (see above)
soon.
Numbered lists are planned for the future.
Definition Lists
================
The definition list gets its name from its use in glossaries. Each
element of a definition list consists of a term (something to be
defined) and a definition (what it means). In practice, it's used for
much more than that, but the help format currently provides only one
use of it: lists of related help texts.
The help format allows an author to provide a list of links to other
help texts and a brief description of each one. For an example, see
`help summary'[3], which contains four separate definition lists.
The format for one of these definition lists places each element on a
line, with blank lines preceding and following the whole list. There
must be at least two elements for a definition list to be recognized.
Each line contains the name of a help topic; the string " -- " (a
dash); and some text, usually describing the help topic or its
relation to the current one.
example -- This is an example of the format for a definition list entry.
It wasn't converted into definition list form because there's only one line.
Horizontal Rule
===============
A line consisting only of twenty or more hyphens in a row, with blank
lines immediately before and after, will be represented as a
horizontal line across the page. Here's an example:
(paragraph (text "-------------------------------------------------------------------------------"))
Plaintext
=========
The help converter breaks text into chunks separated by blank lines.
If a chunk is only one line long, it's considered a paragraph. If
not, an attempt is made to recognize it as header, itemized list, or
definition list. If none of these match, the converter assumes that
the author has done some kind of formatting, and it shouldn't mess
with it.
In this situation, the chunk of text is considered preformatted
"plaintext", and will generally be output in a fixed-width font with
the formatting provided.
In most cases, plaintext is the result of either a help text inherited
from LambdaCore which didn't conform to the format defined here, or an
author needing some kind of formatting not currently provided by the
help format (e.g., nested lists). It usually represents a failure of
some sort on the part of the help system; for this reason, the system
maintains a list of help texts that required plaintext formatting.
This list should be (but isn't) checked periodically, and help texts
should be fixed or new capacities added to the converter.
Page all the currently connected members of the appropriate group(s). Use the @admins command (`@admins <group> [all]') to list the connected [and disconnected] members.
Syntax: home Instantly teleports you to your designated home room. Initially, this is the first room, but you can change that; see `help @sethome'[1] for details.
Syntax: @typo [<text>]
@bug [<text>]
@suggest [<text>]
@idea [<text>]
@comment [<text>]
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, @idea/@suggest for any particular brainstorms or
criticisms you might happen to have, and @comment 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.
Syntax: idle
idle message
idle (dozing message) message
reidle
reidle message
reidle (dozing message) message
The idle command lets you notify people that you are idling for some
kind of activity. You set an idle message by doing something like:
idle to go the bathroom Then, when someone looks at you, they'll
see, appended to your description, the fact that you have idled to go
to the bathroom.
In addition, people may see your idle message in @who listings or in
other as yet undetermined locations.
As soon as you enter another command on the moo, you are no longer
idle, so your idle message won't show up.
You can set how you are described when someone looks in a room as well
(often referred to as your 'dozing' message). If you do:
idle (cooking dinner)
This will replace the usual (dozing), (sleeping) or related message,
and will indiciate to people when they walk in the room why you've
idled.
You can combine both methods at the same time:
idle (eating ice cream) going to the mall for a snack
If you don't set either message, the default will be printed. The
default idle message is "real life intrusion", while the default short
description method is (idling).
You may set your default idle message to something else:
@idle me is <new default message>
And your default dozing message:
@dozing me is <new dozing message>
(Don't use parenthesis on your default dozing message... they're added
automatically by the room description.)
Normally, when you idle, the fact that you're idling is announced to
the room, along with the reason that you're idling. If you would like
to idle quietly, you can use the 'reidle' command instead. This is
often used when you've idled, then said something anyway, and want to
reidle but not bother the other members of the room.
wiz-index[1]
Wizard Help Topics
prog-index[2]
Programmer Help Topics
builtin-index[3]
Server Built-in Functions
core-index[4]
Core Utility Help Topics
jtext-index[5]
Jtext Help Topics
gen-index[6]
General Help Topics
full-index[7]
EVERYTHING
Syntax: help
help <topic>
help index
Print out entries from the online documentation system. The commands
`?' and `information' (usually abbreviated `info') are synonyms for
`help'.
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; if there
is no topic exactly matching the name you give, the help system checks
for topics for which the name is a prefix, perhaps with the addition
or omission of an initial `@', or perhaps with some confusion beween
dashes (-) and underscores (_), e.g.,
`bui' instead of `building',
`who' instead of `@who',
`@wri' instead of `write',
`add_ent' instead of `@add-entrance',
`unlock-' instead of `@unlock_for_open'
If the abbreviation you give is ambiguous, you will be presented with
a list of the matching complete topic names.
The `help index'[1] commands prints out a list of indices for the
various help databases. Each index gives a list of topics available
on that database. It is sometimes easier to find the topics you're
interested in this way, rather than tracing through the chain of cross
references.
Syntax: put <object> into <container>
insert <object> in <container>
Moves the named object into the named container (see `help
containers'[1]). Sometimes the owners of the object and/or the
container will not allow you to do this.
A MOO is a kind of virtual reality, in which players move about from
place to place manipulating their environment in what we hope are
amusing, entertaining, or enlightening ways.
This is just a simple introduction to how to get around; more
introductory texts are being written and will be listed here as we
finish them.
Most commands have the form of simple English sentences:
<verb>
<verb> <direct object>
<verb> <direct object> <preposition> <indirect object>
Don't use English articles (e.g. 'a', 'an', or 'the') in your
commands; the MOO won't understand them. You can refer to yourself as
'me' and the room you're in as 'here'.
The first five kinds of commands you'll want to know are listed below.
Type 'help <topic-name>' for details on any of them:
look[1]
getting a description of the current room or any other object
say[2]
speaking to the other players in the same room as you
@who[3]
showing which players are currently connected to the MOO
movement[4]
how to move around in the MOO, from room to room
@quit[5]
disconnecting from the MOO
Syntax: inventory
i
Prints a list showing every object you're carrying.
Usage: walk to <location>
go to <location>
join <person>
These commands attempt to find a walkable path from where you are to
where you want to be. The first two require you to name your
destination; the last requires the name of someone you want to join.
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>' or 'go to <location>' to move;
this is particularly useful if you know you're going to type several
movement commands in a row (see `help go').
Other commands for moving about include:
walk[1]
going to a particular place
join[2]
joining a particular person
home[3]
returning to the place you live
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}}}
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 Munchkin 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 Munchkin was object #999 and the
wand was #1001. Munchkin 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 Munchkin or someone
carrying his book, his bell, and his candle, Munchkin 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, Munchkin 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.
[Note to programmers: 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. For details, see `help
key-representation'[1].]
Syntax: @lastlog
@lastlog <player>
The first form prints out a list of all players, roughly sorted by how
long it's been since that player last connected to the MOO. For each
player, the precise time of their last connection is printed.
The second form only shows the last-connection time for the named player.
A letters is a special kind of note (see `help notes'[1]) 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 (see `help @create'[2] and `help write'[3]), encrypt it so that only you and the other player can read it (see `help encrypt'[4]) 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; see `help burn'[5] for details.
Syntax: @wrap <on|off>
@wrap
@linelength <number>
@linelength
If the lines you see get cut off at the edge of your screen (you don't
have word-wrap), you can get the MOO to split lines for you. The
@linelength command tells the MOO how many columns you have on your
screen--you probably want @linelength 79--and "@wrap on" tells the MOO
you want it to do word- wrap.
It's better if you can fix this problem without the MOO's help,
though, because the MOO's solution will be slower than a local
solution, and because not all MUDs are willing to do word-wrap.
If you don't want the MOO to split lines for you, there might still be
some use for the @linelength command. Certain commands, like @who and
@check, print truncated lines so they can print in neat columns. The
default for these is generally about 79 columns, which looks fine if
you have an eighty-column screen. If your screen is a different
width, though, you can set @linelength and some of these commands will
react accordingly.
Syntax: @listgag
@gaglist
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. See `help
gagging'[1] for an explanation of gagging in general.
Syntax: @listgag! Shows you a list of the players and objects currently on your `noisy gag list'. See `help gagging'[1] for an explanation of gagging in general.
Syntax: @locations object Prints out the names and object numbers of all containing objects. Example: @locations ur-Rog ur-Rog(#6349) ur-Rog's Display Case(#6355) Editorial Boardroom(#5747)
Syntax: @lock <object> with <key expression> Set a lock on <object> to restrict its use. See `help locking'[1] for general information about locking and `help keys'[2] for the syntax and semantics of key expressions. N.B. In the case of rooms, you are actually better off setting room.free_entry to 0 thus preventing teleportation and then @locking the various entrances. The problem with @locking the room itself is that this can make it impossible to drop objects in the room.
Syntax: @lock_for_open <container> with <key expression> Set the lock on <container> which restricts who can open it. See `help locking'[1] for general information about locking and `help keys'[2] for the syntax and semantics of key expressions. See `help containers'[3] for information on 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: o rooms[1] and containers[2] refuse to allow any object inside them if they're locked for it. o exits[3] refuse to transport any object that they're locked for. o things[4] (including notes[5] and letters[6]) cannot be moved to locations that they're locked for. There are two sides to locking: o How is it specified whether one object is locked for another one? o What is the effect of an object being locked? 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. [Note to programmers: 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. T