[ nwe help ]
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.


@911

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.


@add-entrance

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.


@add-exit

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.


@add-feature

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.


@add-owned

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.


@addalias

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.


admin, admin-policy, administrator-policy, administrators

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

@administrators/@admins group [all]

List all connected [all] members of the administrative group.
See `help admin' for information about the admin groups on JaysHouseMOO.


alias

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.


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

@aliases [object]
Lists your aliases, or the aliases of the given object.


@answer

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').


@audit,@auditdb

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.


@boot, @boot!

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.


@bug

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.


builder-policy

This MOO apparently has no quota policy.  You should talk to an admin
to get someone to write a quota policy.


building

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


burn

Syntax:  burn <letter>

Destroy the named letter irretrievably.  Only players who can read the
letter can do this.


the community group

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.


characters

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


@check

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.


@co

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.


commands

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.


@comment

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.


common_quota

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.


communication, communications

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.

the community group

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.


container-messages

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

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.


@contents

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)


copyright

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.


core-copyright

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.


@count

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.


creation

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


current-object

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.


@current-object, @currentobject

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.


the db group

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.


decrypt

Syntax:  decrypt <note>

Removes any restriction on who may read the named note or letter.
Only the owner of a note may do this.


delete

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.


@describe

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.


descriptions

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


doing

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.


drop

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.


@dump

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.


@edit, @edito, @editoptions, @edit-options

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.)


editors

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.


@eject

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.


email

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.


emote

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.


encrypt

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.


@entrances

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.


erase

Syntax:  erase <note>

Deletes all of the text written on a note or letter.  Only the owner
of a note may do this.


examine

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.]


@examine

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]).]


exit-messages

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.


@exits

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

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.


@features

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.


following

"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.


@forward

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


@forward-me

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.


@gag

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.)



@gag!

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.


@gag-announce

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.


@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.




gagging


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.


@gaglist

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.


gender

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.


@gender

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.


get

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.


Getting Started With Your New Moo

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.


give

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.


go

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.


@go

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


@grant

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.


@gripe

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.


hand

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.


help

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].


Standard Help Text Format

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.


@helpme

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.


home

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.


@idea

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.


idle,idling

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.


Available Help Indices

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

Information

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.


insert

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.


Introduction

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


inventory

Syntax:  inventory
         i

Prints a list showing every object you're carrying.


join

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.


@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


key-representation

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}}}


keys

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].]


@lastlog

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.


letters

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.


@linelength

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.


@listgag

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.


@listgag!

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.


@locations

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)


@lock

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.


@lock_for_open

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.


locking

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.  The way in which 'is_unlocked_for' is
implemented is entirely independent of the ways in which x uses its
results.  Note that you can play on either side of this interface with
your own objects, either defining new implementations of
'is_unlocked_for' that match your particular circumstances or having
your objects interpret their being locked in new ways.]

There is a default way to specify locks on objects; the following help
topics cover the relevant commands:

@lock[7]
      setting a lock on an object
@unlock[8]
      clearing the lock on an object


look

Syntax: look
        look <object>
        look <object> in <container>

Show a description of something.

The first form, with no arguments, shows you the name and description
of the room you're in, along with a list of the other objects that are
there.

The second form lets you look at a specific object.  Most objects have
descriptions that may be read this way.  You can look at your own
description using 'look me'.  You can set the description for an
object or room, including yourself, with the 'describe' command (see
`help @describe'[1]).

The third form shows you the description of an object that is inside
some other object, including objects being carried by another player.


mail

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.


@mail

Syntax:  @mail
         @mail new            (to see recent messages)
         @mail 1-$            (to see *all* messages)

Shows a table of contents for your MOO email message collection.  You
are notified when you connect to the MOO if there are any such
messages.  A little arrow indicates the mail system's notion of your
'current message'.

The first form lists all of your messages or the last 15 if you have
more than that many; the second form lists only those messages after
your `current message'.  The third form shows your entire collection.

If you have a large number of mail messages, you can give arguments so
that @mail only lists the messages you're interested in.  You can also
list messages residing on mail recipients which are public or for
which you have read access.  The general format is

         @mail <message-sequence> [on *<recipient>]

where <recipient> names some child of $mail_recipient (e.g., a
mailing list) and <message-sequence> is either a sequence of
message numbers or one of the other possibilites described in `help
message-sequences'[1].

Note that if you view mail on some other recipient and have "sticky"
in your .mail_options (see `help mail-options'[2]), all further mail
commands (e.g., @read, @next, @rmm,...) will apply to that recipient.
In this case use `@mail on me' to go back to looking at your own mail.


mail-forwarding

There are 3 personal properties that you can use to customize how your
mail is composed and forwarded.

.mail_forward
=============

A list of objects that will receive any mail that gets sent to
you. Objects on this list should either be players or descendants of
$mail_recipient. If this list is nonempty, you will not receive any
mail yourself unless you are on it.  E.g., if Rog is #4292 and ur-Rog
is #6349

  #6349.mail_forward={}            -- usual case; ur-Rog gets his own mail.
  #6349.mail_forward={#4292}       -- Rog gets ur-Rog's mail instead.
  #6349.mail_forward={#6349,#4292} -- ur-Rog gets mail and Rog gets a copy.
  #6349.mail_forward={#-1}         -- ur-Rog's mail disappears without a trace.

.mail_notify
============

A list of objects to be notified whenever mail is sent to you. This
list may include anything that has a :notify_mail() verb. Notification
will take place regardless of whether or how your mail is forwarded.

Thus, in the previous example

  #4292.mail_notify={#6349} --- means that ur-Rog will be told
                                whenever Rog is sent new mail.

.mail_options
=============

This controls lots of miscellaneous things.  Use the @mail-option
command to view and set these options (see `help @mail-options'[1]).

See `help mail-resolve'[2] for more detail on how mail forwarding and
mail notification work.  See `help MR-subscribing'[3] for information
on how to change .mail_forward and .mail_notify on $mail_recipient
children, where they are !c properties.


@mail-options,@mailoptions

Syntax:  @mail-option
         @mail-option <option>

Synonym:  @mailoption

The first form displays all of your mail options.

The second displays just that one option, which may be either `@mail',
`replyto', or one of the flags listed below.  The mail options control
various annoying details of your mail reading and mail editing
commands.

The remaining forms of this command are for setting your mail options:

         @mail-option +<flag>
         @mail-option -<flag>
         @mail-option !<flag>           (equivalent to -<flag>)

These respectively set and reset the specified flag.

 -include      @replys start out with a blank message body
 +include      @replys start with original message included
 -all          @replys go to sender only
 +all          @replys go to sender and all original recipients
 -nosubject    @send forces you to provide a Subject: line
 +nosubject    allow entering the mail editor without giving a subject line
 -enter        start each mail editing session in the usual command mode
 +enter        start each mail editing session with an implicit `enter' command
 -expert       novice mail user (various annoying messages will be printed)
 +expert       expert mail user (suppress printing of annoying messages)
 -sticky       each mail command applies by default to one's own collection
 +sticky       each mail command applies by default to the same message 
                 collection that the previous successful command did
 -netmail      mail to you accumulates in your MOO mailbox
 +netmail      mail to you is actually forwarded to your registered email
                address, if you have one.
 -resend_forw  @resend puts player in Resent-By: header
 +resend_forw  @resend puts player in From: header (like @forward)

For "sticky", `mail command' is one of @mail, @read, @prev, @next, @answer.

All flags default to the `-' settings.  

Next, we have

         @mail-option  manymsgs [is] <number>
         @mail-option  manymsgs=<number>
         @mail-option -manymsgs

The first two forms specify that if you give a @mail or @read command
asking for <number> or more messages, you will first be given a
yes-or-no prompt to continue, the idea being that you many not
actually have wanted to see that many messages.  The third form turns
off this behavior.

         @mail-option  @mail [is] <message-sequence>

The "@mail" option determines what message-sequence the @mail command
uses by default.  Initially, this is "last:15", but other reasonable
choices include "new" and "1-last"

         @mail-option  replyto [is] <recipient> [<recipient>...]
         @mail-option -replyto

The first form specifies that a Reply-To: field is to be placed in all
messages constructed by @send or @answer.  Note this can still be
changed before sending via the mail room's reply-to command.

The second form resets this option so that no Reply-to: is initially
inserted.

        @mail-option rn_order=<order>

controls the order in which folders listed by @rn and @subscribed will
appear.  <order> can be one of

 read    folders are sorted by last read date. (default)
 send    folders are sorted by last send date.
 fixed   folders are not sorted


manipulation

Objects usually have verbs defined on them that allow players to
manipulate and use them in various ways. Standard ones are:

get[1]
      pick an object up and place it in your inventory
drop[2]
      remove an object from your inventory and place it in the room
put[3]
      take an object from your inventory and place it in a container
give[4]
      hand an object to some other player
look[5]
      see what an object looks like

You can see what objects you're carrying with the 'inventory' command;
see `help inventory'[6] for details.

Some specialized objects will have other commands. The programmer of
the object will usually provide some way for you to find out what the
commands are.  One way that works for most objects is the 'examine'
command; see `help examine'[7] for details.

The following specialized objects have help entries you should consult:

notes[8]
      objects that allow text to be written on them and read later
letters[9]
      notes that a recipient can burn after reading
containers[10]
      objects that may contain other objects


manners

JHM, like other MUDs, is a social community; it is populated by real
people interacting via a computer network.  Like members of other
communities, the inhabitants of JHM have certain expectations about
the behavior of its members and visitors.  Thus, the Community Group
(CG) provides this general outline for social conduct here; please
familiarize yourself with and observe these guidelines when you log
into JHM.

In general:

    Behavior that would be considered rude in
    face-to-face interaction is rude here, too.

Some ways to interpret that:

Be nice.  Don't be rude or annoy other people.  If someone requests
that you stop a particular behavior or action, please respect eir
wishes.

Avoid interrupting other people who are working or conversing with
their friends.  You're welcome to explore the public places and ask
for advice if you're stuck, but please try to read the online
documentation and help yourself, first.

In addition, please realize that many players who log in here are busy
with other things, both virtually and in real life, and therefore may
not always be able respond to you immediately.

Harrassment of other players will not be tolerated.  Emoted violence
and obscenities are considered inappropriate in the social context of
JHM.

It isn't reasonable to `:kiss' or `:hug' folks you don't know.  Also,
speak out loud to people you don't know, rather than paging or
whispering.

Respect other player's sensibilities.  MOO inhabitants and visitors
come from a diverse range of cultural backgrounds, both in the
U.S. and abroad, and have varying ideas of what constitutes offensive
expression.  Please keep text as free of potentially-offensive
language and material as you can.

Making logs of JHM conversation for the purpose of public posting is
considered unethical unless each participant in the discussion
expressly agrees to allow the conversation to be posted.

Try to avoid arguing or debating with another player in a crowded
public room; such interactions interrupt the other players in the
room.  Instead, consider paging or moving your conversation to one of
the many empty public rooms.

Although visitors to JHM are asked to use one of the guest characters
for initial explorations, we encourage character creation if you
become a frequent visitor.  That way, you become a fuller part of the
JHM community.

==============

Rude or offensive behavior can result, unfortunately, in your removal,
either temporarily or permanently, from JHM.

If you are uncertain about the meaning of any part of this document
and would like clarification, please consult a Community Group member
(type `help cg'[1] for a listing of players involved in the group or
mail to *cg, the mailing list associated with the Community Group).


me

The MOO helps those who help themselves.  Try starting with `help
summary'[1].  (If you really need immediate help, try typing
`@helpme'.)


@memory

Syntax:  @memory

Prints out all information available on the current memory-usage
behavior of the MOO server.  Probably only an administrator, if
anyone, cares about this.


message-sequences

Certain mail commands, including @mail, @read, and @rmmail, allow a
<message-sequence> argument that indicates to which messages in
one's collection the command is to apply.  Any combination of the
following may appear as a <message-sequence> argument to any of
the various mail commands (@mail, @read, @answer, @rmm).

  17        message number 17 if there is one (and likewise for other integers)
  17..23    all messages numbered between 17 and 23 (inclusive), if any
  cur       the current message
  prev      the message before
  next      the message after
  prev17    the 17 messages prior to the current message
  next17    the 17 messages after the current message
  first     the first message if any
  last      the final message if any (`$' is a synonym for `last')

You may use as many of these at once as sanity permits, e.g.,

  @mail cur 1..5 last

which will display the header for your current message, your messages
in the range 1..5, and your last message.  Though some of these ranges
may overlap, the header for any given message is only shown once in
any event.

In addition, there are other message-sequence arguments that act as
filters on whatever precedes them:

 before:<date>               messages strictly before the given date
 after:<date>                messages strictly after the given date
 since:<date>                messages on or after the given date
 until:<date>                messages on or before the given date
 from:<player>[|<player...]  messages from the given player(s)
 to:<recip>[|<recip>...]     messages to the given recipient(s)
 %from:<string>              messages with <string> in the From: line
 %to:<string>                messages with <string> in the To: line
 subject:<string>            messages with <string> in the subject
 body:<string>               messages with <string> in the body (SLOW!!!)
 first:<number>              the first <number> messages
 last:<number>               the last <number> messages

<date>  is either a weekday, "yesterday", "today" or
        a dd-Month, dd-Month-yy or dd-Month-yyyy date.
<recip> is either <player> or *<$mail_recipient kid>.

Examples:

  @read from:G7|Gemba              read all messages from G7 or Gemba
  @rmm to:yduJ|*Core               remove messages that are to yduJ or to *Core
  @mail since:1-Jan before:1-Feb   show messages dated in January
  @mail since:Tues                 show messages dated on or after Tuesday
  @rmm subject:manners             remove msgs with `manners' in the subject:
  @mail subject:"stupid idiots"    (search string contains a space => need "'s)
  @rmm to:yduJ to:*Core            remove messages that are to yduJ and *Core
  @mail from:Haakon last:5         show the last 5 messages from Haakon
  @mail %from:guest                show mail from players with "guest" in
                                   their names
  @mail last:10 body:fribble       show those of the last 10 messages having
                                   `fribble' in the body (one should always try
                                   to narrow body searches in this way).


messages

Most objects have messages that are printed when a player succeeds or
fails in manipulating the object in some way.  Of course, the kinds of
messages printed are specific to the kinds of manipulations and those,
in turn, are specific to the kind of object.  Regardless of the kind
of object, though, there is a uniform means for listing the kinds of
messages that can be set and then for setting them.

The '@messages' command prints out all of the messages you can set on
any object you own.  Type `help @messages'[1] for details.

To set a particular message on one of your objects use a command with
this form:

        @<message-name> <object> is "<message>"

where '<message-name>' is the name of the message being set,
<object> is the name or number of the object on which you want
to set that message, and <message> is the actual text.

For example, consider the 'leave' message on an exit; it is printed to
a player when they successfully use the exit to leave a room.  To set
the 'leave' message on the exit 'north' from the current room, use the
command

        @leave north is "You wander in a northerly way out of the room."

[Note to programmers: This class of commands automatically applies to
any property whose name ends in '_msg'.  Thus, in the example above,
the command is setting the 'leave_msg' property of the named exit.
You can get such a command to work on new kinds of objects simply by
giving the appropriate properties names that end in '_msg'.
Additionally, in many cases the _msg property is accompanied by a _msg
verb, which defaultly returns the named property, but which is
available to be customized in more complex ways than allowed by simple
string substitution.  You should check for the particular property
you're considering whether the verb form exists (typically with
@list).]

The following help topics describe the uses of the various messages
available on standard kinds of objects:

container-messages[2]
      the messages on objects that can contain other objects
exit-messages[3]
      the messages on exit objects
thing-messages[4]
      the messages on objects that can be taken and dropped


@messages

Syntax:  @messages <object>

List all of the messages that can be set on the named object and their
current values.  See `help messages'[1] for more details.


miscellaneous

Here are a few commands of occasional utility that didn't fit into any
of the neat categories for the rest of the help system:

@version[1]
      printing the MOO server version number
@lastlog[2]
      finding out when some player last connected to the MOO


@more

Syntax:  @more
         @more rest
         @more flush

If you have @pagelength set (see `help @pagelength'[1]) and some
combination of events or commands produces sufficiently many lines of
output, you will see a message of the form

        *** More ***  37 lines left.  Do @more [rest|flush] for more.

indicating (in this case) 37 more lines of text waiting to be read.
At this point, you should give one of the @more commands above.

@more without arguments prints sufficiently many lines to fill your
screen, assuming you've set @pagelength correctly, unless there are
not that many lines left to print.

@more rest will print all of the remaining lines, regardless of your
@pagelength setting.

@more flush discards all remaining lines.


@move

Syntax:  @move <thing> to <place>

Move the specified object to the specified location.  This is not
guaranteed to work; in particular, the object must agree to be moved
and the destination must agree to allow the object in.  This is
usually the case, however.

If @move doesn't work and you own the room where the object is
located, try using @eject instead (see `help @eject').


movement

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


name

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.


@netforward

Syntax:  @netforward <message-number>
         @netforward 
         @netforward <message-sequence> on *collection

Forwards the contents of the indiciated messages from your MOO email
collection to your registered email address.  You get the message
numbers for use here by typing the '@mail' command, which prints a
table of contents for your entire MOO email collection.  If no
arguments are given to @netforward, then the 'current message' in your
collection is sent.  In any case, the 'current message' after
@netforward finishes is not affected.

The most general form of the @netforward command is

         @netforward <message-sequence> [on *<collection>]

where <message-sequence> is as described in `help
message-sequences'.  As with the @mail command you may @netforward
messages on any publically readable collection (child of
$mail_recipient).

If you do not have a valid registered email address, you will not be
able to use this command and must register first.  See `help
@register'[1] for details.

news

Usage:  news [contents] [articles]

Read the latest edition of the newspaper, which carries articles
concerning recent changes to the MOO server or to the main public
classes, or whatever the administrators feel like writing about.

Specifying `contents' means to print only the table of contents for
the newspaper.

The most common uses of this command:

news          -- display articles in the current edition
news new      -- display articles you haven't read yet
news contents -- list articles in the current edition


@next

Syntax:  @next [<number>] [on <collection>]

Print the `next' message in a given email collection (defaults to your
own).  The mail system's notion of your 'current message' for that
collection is incremented.  Thus, e.g., one can read all of one's new
messages one-by-one simply by typing '@next' repeatedly.  If
<number> is supplied, prints and advances that many messages at
once.


@notedit

Syntax:  @notedit <note-object>
         @notedit <object>.<property>

Enters the MOO Note Editor to edit the text on the named object.

For the first form, <note-object> must be a descendant of $note.
For the second form, <object>.<property> can be any
string-valued or text-valued (i.e., list of strings) property on any
object.

See `help editors'[1] for more detail.


notes

Notes are objects that can have text written on them to be read later.
They are useful for leaving messages to people, or for documenting
your creations.

The following help topics cover verbs that can be used with notes:

read[1]          reading the text on the note
write[2]         adding text to a note
erase[3]         removing all the text from a note
delete[4]        deleting one line of text from a note
@notedit[5]      general editing on the text of a note
encrypt[6]       restricting who can read a note
decrypt[7]       undoing a previous encryption

You can make a note by creating a child of the standard note, $note
(see `help @create'[8]).  Note that, like most objects, only the owner
of a note can recycle it.  If you'd like to make it possible for a
reader of your note to destroy it (this is a common desire for notes
to other individual players), then you might want to look at `help
letters'[9].


objective -- not found

The main help database thinks it knows about `objective' but
something's messed up.

Please tell a documenter.


@opacity

Usage:  @opacity <container> is <integer>

The opacity can take on one of three values:

0
      The container is transparent and you can always see into it.
1
      The container is opaque, and you cannot see into it when it's closed.
2
      The container is a black hole, and you can never see into it.

The default @opacity is 1.


@options

Usage:  @options
        @options <category>
        @options all
        @options <category> <option>

There are a number of variations you can request in the way the MOO
interacts with you.  For example, you can specify that you want your
email address to be generally available to other people's MOO
programs.  The options system allows you to view and set these
preferences.

The @options command with no arguments will give you a list of
different option categories available.  Each shows a category name
(which you can use as a <category> argument to @options), a
command (which you can use instead of `@options <category>'),
and a very brief explanation of what the category is about.

`@options <category>' displays the options for the given
category.  Each option is shown with its current setting, and a brief
explanation of what the current setting means.  `@options all' shows
all the options for all the categories.

`@options <category> <option>' either shows or sets the
given option in the given category.  Each option has a name; the ways
you can use this name in an @options command are as follows:

  o  <name> alone shows you the current setting, with a brief explanation.
  o  +<name> and -<name> turn most options on or off.  Obviously, this only works for simple on/off options.
  o  <name>=<value> sets a more complicated option.  For an example, see the manymsgs option in `help mail-options'[1].


page

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.


@pagelength

Syntax:  @pagelength <number>
         @pagelength

If the lines you see scroll off the top of your screen too quickly for
you to read and your client program is such that any lines scrolling
off the top are gone forever, you can use the @pagelength command to
invoke page buffering to limit the number of lines sent at a time.
E.g., if your terminal has a 24 line screen, you can do @pagelength 24
and output will stop every 24 lines if you don't type any other
commands.

You will need to use the @more command to continue reading output once
it has been stopped.  Make sure you read `help @more' before setting
@pagelength.

@pagelength 0 means no page buffering will be done by the MOO.

By default the MOO will assume you have an infinitely wide terminal
screen, so you may wish to set @linelength as well.  As with word
wrapping, you are best off running a client that can do its own page
buffering; the MOO server's page buffering is inherently slower and
many MUD's do not have page buffering at all.


@paranoid

Syntax:  @paranoid
         @paranoid off
         @paranoid immediate
         @paranoid <number>

In immediate mode, the monitor prepends everything you hear with the
name of the character it considers responsible for the
message. Otherwise, it keeps records of the last <number>
(defaults to 20) lines you have heard. These records can be accessed
by the @check command.


@parents

Syntax:  @parents object

A quick way to find out the ancestry of an object.  Prints out the
names and object numbers of all ancestors.

Example:

  @parents #224
  living room (#224)   Generic House Room (#1412)   generic room (#3)   Root Class (#1)


@password

Syntax: @password <old-password> <new-password>

Changes your player's password (as typed in the 'connect' command when
you log in to the MOO) to <new-password>.  For security reasons,
you are required to type your current (soon to be old) password as the
first argument.

Your password is stored in an encrypted form in the MOO database; in
principle, not even the administrators can tell what it is, though
they can change it, of course.  It is recommended that your password
not be your name or a common word; MOO passwords have been stolen or
cracked in the past and characters have been made unhappy by such
theft.  Your password is your security; choose a safe one.


@peek

Syntax:  @read
         @read <message-sequence>...
         @read <message-sequence>... on *<recipient>
         @peek [<message-sequence>...[ on *<recipient>]]

Prints the contents of the indiciated messages from your MOO email
collection.  You get the message numbers for use here by typing the
'@mail' command, which prints a table of contents for your entire MOO
email collection.  If no arguments are given to @read, then the
'current message' in your collection is printed.  In any case, the
'current message' after @read finishes is the last one printed.

The most general form of the @read command is

         @read <message-sequence> [on *<collection>]  

where <message-sequence> is as described in `help
message-sequences'[1].  As with the @mail command you may @read
messages on any publically readable collection (child of
$mail_recipient).

The @peek command is identical to @read, but doesn't set your current
message.  Use this if you want to take a look at a message other than
the current one but not lose your place.


point -- not found

The main help database thinks it knows about `point' but something's
messed up.

Please tell a documenter.


@popo, @popobject

Usage:  @popobject

The @popobject (@popo) command returns you to a previous current
object (see `help current-object'[1]) by popping the present one off
the stack.

See also `help @pushobject'[2] and `help @swapobject'[3] for
information on manipulating the current object stack.


@prev

Syntax:  @prev [<number>] [on <collection>]

Print the 'previous' message in a given email collection (defaults to
your own).  The mail system's notion of your 'current message' for
that collection is decremented.  Thus, e.g., one can review all of
one's previous messages one-by-one simply by typing '@prev'
repeatedly.  If <number> is supplied, prints and decrements the
current message by that many messages.


privacy

OMNISCIENT CORE GROUP AND SYSADMINS
-----------------------------------

People in the Core Group (see `help admin-policy'[1]) can look at
absolutely *anything* in the MOO database.

The above mentioned parties, while they will endeavor to be discreet
about anything incidental that turns up, nevertheless reserve the
right look at anything they want, if only for the sake of being able
to resolve technical problems.

LOGGING
-------

Some client programs (the "client" is the program you use to connect
to the MOO, e.g., telnet, tinytalk, tinyfugue, emacs with mud.el...)
are capable of logging everything that happens to the corresponding
player.  In fact, with some clients this happens by default.  If a
given player's client has logging enabled and said player is either in
the room with you or is monitoring an object that is in the room with
you, then *everything* you say and emote gets recorded.  Also, if you
are in a room owned by someone else, all bets are off.  There is *no
way* that the MOO server can know about what client a given player is
using; thus, anyone who can hear you is a potential logger.

In and of itself this would not be a problem---indeed, logs are often
useful for reference purposes.  However, there is no guarantee that
the log will not end up someplace where you'd rather it didn't, e.g.,
posted on the rec.games.mud Usenet newsgroup.  While it considered bad
form (i.e., rude) to circulate or post a log without having the
permission of at least the major participants in the activities
logged, there is not a whole lot we can do on the technical side to
prevent it from happening.

Be aware of the problem.  The @sweep command (see `help @sweep'[2])
attempts to determine what players can be listening at any given
moment.  If anything, it errs on the side of paranoia.  Even so, it
doesn't cover *all* possible avenues of eavesdropping, and there's no
hope for it covering the situations like the one where someone manages
to convince one of the participants in your discussion who kept a log
that it really doesn't need to be kept private after all.

If you've got something really sensitive to discuss, you are best off
doing it by encrypted email or in person.


programming

MOO contains a rich programming language for the creation of
interesting rooms, exits, and other objects.  Help is available on the
following topics concerning programming in MOO:

language[1]
      a brief reference for the syntax and semantics of the MOO language
tasks[2]
      a brief description of MOO tasks and their resource limits

@property[3]
      adding a property to an object
@rmproperty[4]
      removing a property from an object

@verb[5]
      adding a verb to an object
@rmverb[6]
      removing a verb from an object
@args[7]
      changing the syntax of a verb
@copy[8]
      copying a verb from one object to another

@program[9]
      entering the program for a verb
@list[10]
      printing a listing of the program for a verb
@edit[11]
      editing verb code
eval[12]
      executing MOO statements and expressions without writing a verb

@show[13]
      looking at all the details of an object, a property, or a verb
@display[14]
      a different way to look at those details

@parents[15]
      listing the ancestors of an object
@kids[16]
      listing the children of an object
@chparent[17]
      changing the parent of an object

@contents[18]
      listing the contents of an object
@chmod[19]
      changing the permissions on an object, a property, or a verb
@rename[20]
      changing the name of a verb or object
@currentobject[21]
      specify an object to work with


programming-policy -- not found

The main help database thinks it knows about `programming-policy' but
something's messed up.

Please tell a documenter.


the jayshousemoo project system

(October 1993)


JaysHouseMOO's objective is to perform research and development of
various projects (see `help purpose').  As part of accomplishing that
objective, project teams programmers on this MOO work on a small set
of well-defined projects.  A project is under the direction of a
project leader.  Each project must make some sort of reasonable
progress over time.

This document defines the JaysHouse project system.  It is intended to
be a set of clear and precise guidelines that will help to focus the
work being done on JaysHouseMOO.  As such, it is bureaucratic in form.
A less bureaucratic explanation of the content may be found at the end
of the document.

OBJECTIVES
----------

JaysHouseMOO has several objectives related to research and
development.  (See `help purpose'[1] for details.)  These objectives
take the form of large-scale projects coordinated by the members of
the Steering Committee (see `help steering-committee'[2]), and are
often referred to as `areas of interest' or `metaprojects'.

The active areas of interest may be listed by typing `@projects'.

PROJECT HIERARCHIES AND TERMINOLOGY
-----------------------------------

A metaproject is composed of many smaller projects.  Some of these may
be so large as to also be composed of smaller projects, or
`subprojects'.  Their `parent' project may be referred to as that
project's `superproject'.  These terms are used to clarify relations
between projects, and do not convey a sense of importance.

The `@projects' command facilitates this organization by allowing one
to specify superprojects and subprojects.

Following this, the term `project' will refer to a project of any
scope that has been defined as part of the project hierarchy (and is
thus documented in some way by the `@projects' command.)


Projects
========

A `project' is a programming or research objective, that, when
completed, will enhance the MOO in some way.  It must be associated
with one of the active metaprojects, that is, it must in some way work
toward the goal of that area of interest.

Most likely, a project will take some time (quite possibly a very long
time) to accomplish, and will require a significant amount of MOO
coding.

Information about all active projects on the MOO is available via the
@projects command.  (See `help @projects'[3] for details.)

Project Teams
=============

A project is directed by a `project leader'.  This person is
responsible for the progress and coordination of the project.  The
name of the project leader can be found on the list of projects.

A project leader reports to the leader of that project's superproject.
The leader of each metaproject reports to the Steering Committee (and,
in fact, is a member of the committee).  To `report' means to
coordinate goals and activities, and to give progress updates by
whatever method seems appropriate to the superproject leader.

Individuals wishing to work on a project should communicate directly
with the project leader.  If the project leader, the metaproject
leader, and all project leaders between the two (if any) agree that
the individual may work on the project, then the individual is added
to the set of people working on the project.

Although not all project members need to program, some will.  If a
project member needs a programmer bit, a request should be sent to the
Steering Committee via the *sc mailing list, and the Steering
Committee must agree that e should become a programmer.  For greater
detail on what it takes to be a programmer, see `help
programmer-policy'[4].

If a project leader feels that a programmer on eir team is not
contributing to the project, e may remove the individual from the
project.  If this was the only project the individual was working on,
eir programmer bit should be removed.

Policy Decisions
================

The Steering Committee collectively make decisions about projects. It
decides:

  o  Whether or not a given metaproject proposal should be accepted as a project.
  o  Whether or not the current metaprojects are making reasonable progress.
  o  Any other project-related issues that arise.

It is expected that metaproject and project leaders will make the same
decisions about their own projects.

The committee meets once a month on-line to discuss any
project-related issues.

Any changes related to project policy should be agreed to by the
Steering Committee, and then this document should be updated to
reflect them.

Project Objects and Location
============================

Depending on the size and scope of the project, it may have a spatial
location in the MOO, a mailing list, or a project coordination board.
These things will depend a lot on how the area of interest that the
project is associated with is managed, and should be agreed upon by
both the metaproject leader and the project leader.

If there is a project location, it should be built according to the
JHM theme (see `help theme'[5]).

New Projects
============

Ideas for new metaprojects must be submitted to the Steering Committee
via the *sc mailing list.  For details on this process, see `help
steering-committee'[6].

New projects must be approved by the leader of its proposed
superproject, and by every leader all the way up to the leader of the
associated metaproject.

Once the project has been approved, the new project leader is
responsible for creating the necessary items and pointers for the
project (i.e. a space, a project board, and the correct entries for
@projects).

Project Progress
================

A project leader must submit a monthly report to their superproject
leader, in whatever form they both have agreed upon.  Leaders of
metaprojects should submit at least a paragraph or two to the Steering
Committee, explaining what sorts of things have happened since the
last report, and what progress is being made among their various
subprojects.  This report will be made publicly available so that
interested parties may see what sorts of things are happening with the
various metaprojects.

After three months without any real progress as determined by the
superproject leader or Steering Committee, or without submitting a
project report, a project will be mothballed.

Mothballing a Project
=====================

A project that is completed or stagnant will cease to be an active
project.  This is called `mothballing'.

This consists of taking the entries for the project out of the active
projects lists, appropriately archiving any rooms, mailing lists or
objects associated with the project, and deprogramming anyone who was
working on the single project.

A mothballed project may be reactivated in the same manner that a new
project may be requested - by approval of the superproject leader or
the Steering Commitee.  Essentially, one starts a new project based on
the previous project.

MOO Progress
============

If no projects have made any progress for several months, the Steering
Committee should reconsider the JaysHouseMOO Objective and the Project
Policy.

It has been suggested that if the Objectives are not being
accomplished, the MOO should be gracefully shut down.

What We Really Mean
===================

Okay, the above stuff was bureaucratic policy created to clearly
define the rules.  What follows is meant to explain the rationale
behind the rules.

  Metaprojects (i.e. areas of interest) are really really big things.
They could well take years to accomplish, and are made up of lots of
smaller projects. They are expected to fall pretty closely within the
JHM purpose, but are actually rather broad in scope.  For example `moo
documentation' might be an objective related to the JHM purpose of
`cohesive environments'.

  Projects are pretty big things, and help to make the objectives
actually happen.  Expect projects to take quite a bit of work (not
necessarily programming) and to be large enough for several people to
work on together (although this isn't necessary either).  A project
within the `moo documentation' area of interest might be `the on-line
tutorial' or `the jtext hyperdocument system'. On the other hand
`fixing the description of 169' isn't really big enough to be a
project.  Perhaps it's best to say that a project is clearly
furthering one of the goals of JHM.

  There are project leaders so that someone coordinates a project and
makes sure that it occasionally makes progress.  In many cases only
one person will be working on a project, if the project is of fairly
restricted scope.

  Projects need to be within an administrator's (i.e Steering
Committee member's) area of interest so that an admin can be around to
help out if necessary, and so that the admin can answer any questions.
The SC members are responsible for making sure that work on JHM
proceeds towards its goals on some global sense, while programmers
aren't necessarily under that restriction.  This isn't all that
restrictive on what projects can be; areas of interest are pretty
broad.

  The Steering Committee consists of the metaproject leaders and a few
non-leaders with experience who act in an advising capacity.  This
isn't meant to be a bunch of people on a power trip, or a bunch of
people who for some bizarre reason enjoy making bureaucratic decisions
and going to meetings.  Rather, it is an organization of people who
have the necessary experience to lead the MOO to fulfilling its
purpose, and the willingness to shoulder some responsibility.

  Metaproject leaders should submit project progress reports mostly so
that everyone else on the MOO can see how a project is going.  People
might be curious about a project, or might want to look back over the
last six months of work.  Subproject leaders are encouraged to do so
as well, but this is up to their superproject leader.

  Programmers need to be on a project so that it's clear why a
particular person is a programmer.  Randomly distributed programming
bits have been a bad thing in the past.  Programmer bits are lost when
a project is over so that there aren't random stray programmers.  This
sounds harsh, but think over the fact that a project will take many
moons to complete, and programmers, especially ones who want and like
to program, will probably be on several projects.

  Programmer bits are not a status symbol, nor are they a reward.

  Yes, `meta', `super', and `sub' complicate things and sound sorta
silly, but one has to have a way to express the relationships that we
feel will help to define responsibility and direction.


The main idea behind this is to have some clear direction for the MOO,
figure out how to get there, make it marginally clear who's doing
what, and let people know what's happening.  If you have some
suggestions on changes, please send them to *sc.


pronouns

Some kinds of messages are not printed directly to players; they are
allowed to contain special characters marking places to include the
appropriate pronoun for some player.  For example, a builder might
have a doorway that's very short, so that people have to crawl to get
through it.  When they do so, the builder wants a little message like
this to be printed:

        Balthazar crawls through the little doorway, bruising his knee.

The problem is the use of 'his' in the message; what if the player in
question is female?  The correct setting of the 'oleave' message on
that doorway is as follows:

        "crawls through the little doorway, bruising %np knee."

The `%np' in the message will be replaced by either 'his', 'her', or 'its', depending upon the gender of the player.  

As it happens, you can also refer to elements of the command line
(e.g., direct and indirect objects) the object issuing the message,
and the location where this is all happening.  In addition one can get
at various other information, like verb conjugation, plural/singular
nouns, and strings from the command line.

The MOO offers a variety of pronoun substitution styles; the default
is described in `help two-letter'[1].

For an example of using pronoun substitution in programming, see `help
pronoun-example'[2].


@pusho,@pushobject

Usage:  @pushobject [<object>]

The @pushobject (@pusho) command changes your current object (see
`help current-object'[1]), but remembers where you were by pushing it
onto a stack.  The object is specified as in the @currentobject
command (see `help @currentobject'[2]).

If used with no arguments, the @pushobject command displays the
current object stack.

See also `help @popobject'[3] and `help @swapobject'[4] for
information on manipulating the current object stack.


put

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.


@qsend, @quicksend

Syntax: @quicksend <recipients(s)> [subj=<text>] [<message>]

Sends the recipients(s) a quick message, without having to go to the
mail room. If there is more than one recipients, place them all in
quotes. If the subj contains spaces, place it in quotes.

To put line breaks in the message, use a caret (^).

If no message is given, prompt for lines of message.

Examples:

        @quicksend Alice subj="Wonderland is neat!" Have you checked out the Wonderland scenario yet? I think you'd like it!
        @quicksend "Ethel Fred" Have you seen Lucy around?^--Ricky


@quit

Syntax:  @quit

Disconnect from the MOO.  This breaks your network connection and
leaves your player sleeping.  Disconnecting in most parts of the MOO
automatically returns your player to its designated home (see `help
home'[1]).


@quota

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.

If you want to get more quota, please see `help quota-policy'[1].


 - - - - - - - - - - - - - - - - - - - - - - - - - -
Syntax:  @quota <player> is <number> [<reason>]

This second and more interesting form of the verb changes a player's
quota to the given number.  Mail will be sent to $quota_log; the
message will include the <reason> if such is given.


quota-policy

This MOO apparently has no quota policy.  You should talk to an admin
to get someone to write a quota policy.


read

Syntax:  read <note>

Prints the text written on the named object, usually a note or letter.
Some notes are encrypted so that only certain players may read them.


@read

Syntax:  @read
         @read <message-sequence>...
         @read <message-sequence>... on *<recipient>
         @peek [<message-sequence>...[ on *<recipient>]]

Prints the contents of the indiciated messages from your MOO email
collection.  You get the message numbers for use here by typing the
'@mail' command, which prints a table of contents for your entire MOO
email collection.  If no arguments are given to @read, then the
'current message' in your collection is printed.  In any case, the
'current message' after @read finishes is the last one printed.

The most general form of the @read command is

         @read <message-sequence> [on *<collection>]  

where <message-sequence> is as described in `help
message-sequences'[1].  As with the @mail command you may @read
messages on any publically readable collection (child of
$mail_recipient).

The @peek command is identical to @read, but doesn't set your current
message.  Use this if you want to take a look at a message other than
the current one but not lose your place.


@recycle

Syntax:  @recycle <object-name-or-number>

Destroys the indicated object utterly and irretrievably.  Naturally,
you may only do this to objects that you own.


Of course, wizards are allowed to @recycle anything at all.

There is, however, a block (in $player:recycle) against recycling
actual players, i.e., descendants of $player that have the player flag
set.  This is mainly to prevent stupid mistakes.  If, for some reason,
you want to recycle a player, you need to @toad it first.


@register, registration

Usage:  @register [<someone>]
        @register <someone> as <email-address>[ <commentary>]

Check or update an email address.

The first form just tells you the person's email address.  It works
only if you are that person or are on the community group (see `help
cg'), or if the person has made eir address public (with `@miscoption
+public_email').  It may also tell you about others registered to the
same address.

The second form will change the database entry, assign a new password,
and mail the new password to the given email address.

Most people can only register themselves, and can't provide commentary
(additional text that's stored with the email address).  Community
group members can register others and add comments.

reidle

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.


remove

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.


@remove-entrance

Syntax:  @remove-entrance <entrance>

Remove the specified entrance from the current entrances list of the
room.  Entrance may be either the name or object number of an entrance
to this room.


@remove-exit

Syntax:  @remove-exit <exit>

Remove the specified exit from the current exits list of the room.
Exit may be either the name or object number of an exit from this
room.


@remove-feature

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.


@rename

Syntax: @rename <object>        to [name-and-alias],<alias>,...,<alias>
        @rename <object>        to [name]:<alias>,...,<alias>
        @rename <object>:<verb> to <new-verb-name>

The first two forms are used to change the name and aliases of an
object.  The name is what will be used in most printed descriptions of
the object.  The aliases are the names by which players can refer to
the object in commands.  Typically you want to include the name in the
aliases, as the MOO parser only checks .aliases when matching, so the
first syntax is generally preferred.

If you leave out the "name" part of the list, @rename will leave the
object's name as it is, and only change the aliases.

You can't give an object an empty name or alias.

Examples:
Munchkin names his dog:
  @rename #4237 to "Rover the Wonder Dog":Rover,dog

Now we'll see 'Rover the Wonder Dog' if we're in the same room as him
and we can refer to him as either 'Rover' or just 'dog' in our
commands, like 'pet dog'.

Munchkin changes his dog's aliases:

   @rename #4237 to ,Rover,dog,Rover the Wonder Dog

The name remains the same--we still see 'Rover the Wonder Dog'--but
now any of 'Rover', 'dog', or 'Rover the Wonder Dog' can be used to
refer to him.  This can help reduce confusion.

NOTE that for renaming players, more stringent rules apply.  Your new
name must not include spaces and must be distinct from any other
player's name or alias; likewise for any of your single-word aliases.
Also, certain names (mainly prepositions) are not allowed, and names
of the form "Something_Guest" are reserved for actual guests.  There
are no restrictions on giving yourself multi-word aliases, however the
commands that expect player names (e.g., @who, whereis) will not
recognize multi-word aliases.

The third form of the @rename command is for use by programmers, to
change the name of a verb they own.  If the <new-verb-name>
contains spaces, the verb will have multiple names, one for each
space-separated word.


@renumber

Syntax:  @renumber [<collection>]

Renumbers the messages in your collection to go from 1 to however many
you have at the moment.  The optional argument allows you to renumber
the messages stored in some other collection (@renumber, like @rmmail,
requires write access).

Note that if you have zombie messages from a previous @rmmail command
(see `help zombie-messages'[1]), these will be expunged.


@reply

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').


@request

Usage:  @register [<someone>]
        @register <someone> as <email-address>[ <commentary>]

Check or update an email address.

The first form just tells you the person's email address.  It works
only if you are that person or are on the community group (see `help
cg'), or if the person has made eir address public (with `@miscoption
+public_email').  It may also tell you about others registered to the
same address.

The second form will change the database entry, assign a new password,
and mail the new password to the given email address.

Most people can only register themselves, and can't provide commentary
(additional text that's stored with the email address).  Community
group members can register others and add comments.


@resident

Syntax: @resident player
        @resident !player
        @resident

Adds or removes a player from the residents list of a room.  The
residents list controls who is allowed to use @sethome in that room.
This defaults to just the owner of the room; by manipulating the
residents list you may allow additional players to use that room as
their home.

  o  @resident player adds that player to the list.  
  o  @resident !player removes that player from the list.
  o  @resident with no arguments simply displays the current list
     (which may be "none", indicating no additional people besides
     the owner may use that room as their home).

See also `help @sethome'[1].

Hints for programmers: The verb $room:accept_for_abode is called by
@sethome.  By overriding this verb you can give different criteria to
@sethome.  It should return 1 for allowed and 0 for denied.


@rmalias

Syntax: @rmalias <alias>[,...,<alias>] from <object>
        @rmalias <alias>[,...,<alias>] from <object>:<verb>

The first form is used to remove aliases from an object.  If the
object is a valid player, space and commas will be assumed to be
separations between unwanted aliases.  Otherwise, only commas will be
assumed to be separations.  Note that @rmalias will not affect the
object's name, only its aliases.

The second form is for use by programmers, to remove aliases from a
verb they own.  All spaces and commas are assumed to be separations
between unwanted aliases.


@rmmail

Syntax:  @rmmail [<message-sequence>] [from *<recipient>]

Deletes the indicated messages from your MOO email collection.  By
default, your current message is deleted.

See `help message-sequences'[1] for the full list of possible
arguments.  You get the message numbers for use here by typing the
'@mail' command (see `help @mail').

There is no confirmation for this action, so be careful.  While it is
true that @unrmmail will be able to bring back the messages deleted by
the last @rmm, any messages deleted before then are really gone, i.e.,
irrecoverable.  See `help @unrmmail'[2] for more information.

This command may be used on other mail recipients (children of
$mail_recipient), but only ones to which you have write access (you
either have to own it or be on good terms with whoever does...).


@rn

Syntax:  @rn
         @subscribe
         @unsubscribed

For each collection of mail messages that you read other from your
own, a last-read-time is kept.  The `@rn' command tells you which
collections (out of all those you have ever read) have recently had
messages added to them, i.e., more recently than when you last did a
@read, @prev, @next, or @skip on that collection.

The `@subscribed' command shows all your mailing lists, even those
which have no new mail; the `@unsubscribed' command shows mailing
lists which you haven't read, and indicates how many messages you're
missing out on.

Etymologists' note: If you thought @rn had anything to do with the
popular UNIX newsreading program `rn', it's just your imagination.


room-messages

A few different messages can be set on a room object (see `help
messages'[1] for instructions on doing so); they are printed to
various audiences when a player or other object is ejected from the
room.  (See `help @eject'[2].)  The standard pronoun substitutions are
made on each message before it is printed; see `help pronouns'[3] for
details.

The default message is given in brackets after each name below:

@ejection  [{list}]
  Printed to the player doing the ejecting.

@victim_ejection  [{list}]
  Printed to the object being ejected.

@oejection  [{list}]
  Printed to others in the room from which the object is being ejected.


rooms

Rooms may be made by builders; see `help @dig'[1]. By default, all
rooms are instances of the generic room, $room.  `help
room-messages'[2] and `help locking'[3] discuss how to customize
rooms.


say

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!"


the steering committee, the steering committee

This document details the role of the JaysHouseMOO Steering Committee
(or SC).  The SC defines the goals and objectives of JHM, and makes
decisions related to the accomplishment of those goals.

ORGANIZATION
------------

The Steering Committee members may be reached via the *sc mailing
list.  All of the requests below should be mailed to this list.

The Steering Committee meets at least once a month to discuss any
issues from the mailing list that could not (or should not) be
resolved in email, and to deal with any other issues related to JHM
that should be discussed interactively.

The leader of the Steering Committee plans the agenda for the SC
meetings, resolves disputes between members of the SC, and makes any
`hard' decisions that can not be reached by consensus.

DECISIONS
---------

The following decisions must be made by the Steering Committee.
Others should be added to this list as necessary.

Approve new programmers
=======================

A request to make someone a programmer should be be submitted to the
SC by a metaproject leader.  (The prospective programmer must be
planning to work on a project within that leader's metaproject.)  The
leader must get verbal or email approval of all active SC members.
Once this has happened, the leader may make the person a programmer,
and the fact shall be recorded in the programmer-log.

Approve new metaprojects and metaproject leaders
================================================

A metaproject (or area of interest) should be submitted to the SC,
which should discuss it at an SC meeting.  It must be approved by a
full consensus of SC members, either at the meeting, or via mail if
any member of the SC was not present at the meeting.  If the person
who has submitted the metaproject is not already a metaproject leader,
e must also be approved to become a metaproject leader.

Discontinue metaprojects
========================

A metaproject may be discontinued simply by the choice of the
metaproject leader, or by full consensus of the SC.

Approve new members of the Steering Committee
=============================================

A request should be submitted to the SC.  All active members of the SC
and the potential new member must approve the request.  MOOmail is
sufficient.

Approve new members of the DB group
===================================

A request should be submitted to the SC.  All active members of the SC
and the potential new member must approve the request.  MOOmail is
sufficient.

Approve new members of the Unix group
=====================================

A request should be submitted to the SC.  All active members of the SC
must approve the request.  The Unix systems administrator of the
computer that JHM is running on must also approve the addition.

Approve new members of the Community group
==========================================

A request should be submitted to the SC.  All active members of the SC
and the potential new member must approve the request.  MOOmail is
sufficient.

Dismissals
==========

All dismissals from the above posts are approved by consensus of the
members of the SC, minus the person in question.  Requests to resign
should be handled in the best and most polite manner.

THEORY OF OPERATION
-------------------

Many details in the above decisions have not been explicitly stated,
and it is assumed they will simply be handled reasonably.  If this
turns out not to be the case, or if some method of decision-making is
ambiguous, this document should be modified by the leader of the
steering committee.

Current members: Wizard.


security

There are several commands available to determine the origins of
messages and to check that your communications with other players are
secure. Help is available on the following topics:

@paranoid[1]
      keeping a record of messages your character hears.
@check[2]
      looking at that record to determine responsibility for messages.
@sweep[3]
      checking who is listening in on your conversation.


@send

Syntax:  @send <recipient> [<recipient> ...]  [subj[ect]="<subject>"]

Prepares for you to compose a MOO email message to the recipients
named on the command line.  A recipient can be specified by giving a
player name or object-id, or a '*' followed by the name or object-id
of some non-player mail recipient (e.g., a mailing list or a mail
folder) -- a list of such non-player recipients is available from
within the mailroom with the 'showlists' command.

The usual editor is invoked.  You will be prompted for a subject line
if you did not specify one in the @send command (see `help
@mailoptions'[1] for how to avoid this).

Use `say' (") to insert lines in the body of your message.  See `help
editors' for details.

Giving this command without arguments resumes editing the previous
unsent draft message if one exists.


@sethome

Syntax: @sethome

Sets your designated home (see `help home'[1]) to be the room you're
in now.  If the current room wouldn't allow you to teleport in, then
the `@sethome' command nicely refuses to set your home there.  This
avoids later, perhaps unpleasant, surprises.  Additionally, your home
must be a room that will allow you to stay there.  Rooms which you own
will do this, as will rooms to which you have been added as a
resident.  See the @resident command for help on adding someone as a
resident to a room you own.


sex

Sorry, this really isn't the place to look if you need help with sex.
However, if you're an old Adventure devotee, you might try the casette
port in back.


@skip

Syntax:  @skip [<collection>...]
         @unsubscribe [<collection>...]

For each collection of mail messages that you read other from your
own, a current message and a last-read-time is kept.  Normally, if you
neglect to actually @read any messages on a collection other from your
own, @rn (or :check_mail_lists) will continue to remind you that they
are there.

The @skip command indicates that you're not interested in reading the
rest of the messages that currently exist in that given collection.

The @unsubscribe command flushes the current-message/last-read-time
information completely, indicating that you are not only uninterested
in the rest of the messages on that collection, but also likewise
uninterested in anything else that may appear on that collection later
on.  @unsubscribe also removes you from the collection's .mail_notify
list.


@sort-owned

Syntax:  @sort-owned

Sorts your .owned_objects property so @audit shows up sorted.  See
`help @audit'[1] for more information.


spoofing

There are several commands available to determine the origins of
messages and to check that your communications with other players are
secure. Help is available on the following topics:

@paranoid[1]
      keeping a record of messages your character hears.
@check[2]
      looking at that record to determine responsibility for messages.
@sweep[3]
      checking who is listening in on your conversation.


@subscribe

Syntax:  @subscribe *<collection> [with|without notification] [before|after *<collection>]
         @subscribe

The second form of the command gives a list of all mail collections
that are readable by you.

The first form of this command sets up a current message and a
last-read-time for the given mail collection so that when you next log
in or issue the @rn command, you will be informed about new mail that
has appeared there.  Note that this happens automatically whenever you
@read messages on a given collection, so if this much is all you care
about, you don't need to use this command; just do, e.g.,

         @read last on *<collection>

Specifying "with notification" causes you to be added to the
immediate-notification list (.mail_notify) for that collection, i.e.,
whenever new mail arrives there, you will be notified immediately.
Specifying "without notification" causes you to be removed from the
collection's .mail_notify.

Specifying "before *<other-collection>" causes
<collection> to be placed immediately before *<collection>
in your @rn listing (which see) and likewise for the "after" clause.
By default, new collections are placed at the end of your list.  The
before/after specification is only useful if you have @mail-option
rn_order=fixed set (see `help @mail-options'[1]).

@subscribing to a collection for which you already have a
current-message/last-read-time has no effect other from possibly
changing that collection's .mail_notify and/or reordering your
collections for @rn.

You can only @subscribe to collections that are readable by you.

Note that this is entirely different from the Mail Room `subscribe'
command which actually adds you to the .mail_forward list for a given
collection/mailing-list, so that mail sent to the list actually shows
up in your own mail collection.

We're probably going to phase out the Mail Room `subscribe' command...


@subscribed

Syntax:  @rn
         @subscribed
         @unsubscribed

For each collection of mail messages that you read other from your
own, a last-read-time is kept.  The `@rn' command tells you which
collections (out of all those you have ever read) have recently had
messages added to them, i.e., more recently than when you last did a
@read, @prev, @next, or @skip on that collection.

The `@subscribed' command shows all your mailing lists, even those
which have no new mail; the `@unsubscribed' command shows mailing
lists which you haven't read, and indicates how many messages you're
missing out on.

Etymologists' note: If you thought @rn had anything to do with the
popular UNIX newsreading program `rn', it's just your imagination.


@suggest

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.


summary

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


@swapo, @swapobject

Usage:  @swapobject [<object>]

The @swapobject (@swapo) command returns to the previous object on the
current object stack (see `help current-object'[1]), but it places the
_present_ object _on_ the stack.  Repeated use of this command
essentially alternatives between two current objects.

The new current object is specified as in the @currentobject command
(see `help @currentobject'[2]).  If used with no arguments, the
@pushobject command displays the current object stack.

See also `help @pushobject'[3] and `help @popobject'[4] for
information on manipulating the current object stack.


@sweep

Syntax: @sweep

Used when you wish to have a private conversation, and are concerned
someone may be listening in. @sweep tries to list the avenues by which
information may be leaving the room. In a manner analogous to @check,
it assumes that you don't want to hear about your own verbs, or those
belonging to the Core Group (see `help admin-policy'), who presumably
wouldn't stoop to bugging.


take

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.


the tech group

The JaysHouseMOO `Tech' Group are people who deal with the technical
operation of the MOO.  This consists of three types of jobs:

THE DB GROUP
------------

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.

THE UNIX GROUP
--------------

The set of people who deal with unix-level administration of the
MOO. They deal with startup, shutdowns, backups, memory usage, and
management of auxiliary processes.

Current members: Wizard.

THE PROGRAMMING GROUP
---------------------

People who program verbs.  See `help programmer-policy'[1] for what it
takes to become a programmer.

Current members: Wizard.


teleportation

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


thing-messages

Several kinds of messages can be set on 'things', objects that have
$thing as an ancestor (see `help messages'[1] for instructions on
doing so).  They are printed to various audiences under various
circumstances when an attempt is made to 'take' or 'drop' a thing.
The ones whose names begin with 'o' are always shown prefixed with the
name of the player making the attempt and a single space character.
The standard pronoun substitutions (with respect to the player) are
made on each message before it is printed; see `help pronouns'[2] for
details.

The default message is given in brackets after each name below:

@take_failed  [You can't pick up %td.]
  Printed to a player who fails to take the object.

@otake_failed []
  Printed to others in the same room if a player fails to take the object.

@take_succeeded  [You take %td.]
  Printed to a player who succeeds in taking the object.

@otake_succeeded  [%n:(picks) up %td.]
  Printed to others in the same room if a player succeeds in taking the object.

@drop_failed  [You can't seem to drop %td here.]
  Printed to a player who fails to drop the object.

@odrop_failed [%n:(tries) to drop %ti but %n:(fails).]
  Printed to others in the same room if a player fails to drop the object.

@drop_succeeded  [You drop %td.]
  Printed to a player who succeeds in dropping the object.

@odrop_succeeded  [%n:(drops) %ti.]
  Printed to others in the room if a player succeeds in dropping the object.


throw

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.


time-stamping, time-stamps, timestamping, timestamps, tstamp

Time stamping is a way to get some idea when things happened in your
scrollback--it's most useful when you idle for long periods of time,
although it can be handy in other situations too.  If you have time
stamping on, you'll be told every so often what time it is.

Example:
  [ 9:10 am ]                               {a time stamp}
  Foo says, "I'll be back soon ..."         
  (you idle too)
  [ 5:10 pm ]                               {a stamp triggered by Foo's return}
  Foo says, "I'm back."
  >:wakes
  [ 6:30 pm ]                               {a stamp triggered by your emote}
  (your name) wakes.

There are two time stamping options, both under `@options misc' (see
`help @options').

Time Stamping Options
---------------------

   @options misc tstamp=<number>

This sets the minimum number of minutes between time stamps.  You
won't get time stamps when nothing is happening around you, so the
interval between them may be longer.

If <number> is negative, that doesn't mean you'll get timestamps
in reverse order or anything; it's a way of saying that each time
stamp should appear BEFORE the event that triggers it.  If
<number> is positive, then each time stamp appears AFTER the
trigger event.

   @options misc fstamp=<string>

This sets the format of the time stamp.  Time stamps are run through
$time_utils:time_sub (see `help $time_utils:time_sub'[1]).  One
additional option not in $time_utils:time_sub is %D.  This expands to
", on <day>" when the day changes (i.e. the first stamp for the
new day would have it.  The rest of the time it is ignored.For
example, the default is "[ $o:$M $p ]", which would come out right now
as "[ 7:04 pm ]".

topics

A room is a place where talking can take place.  Sometimes, this
talking is focused on one topic or purpose.  That is what room topic
is for.  Currently, room topics show up in the "parties" list (see
`help parties'[1]).

SETTING TOPICS
--------------

There are two types of topics.  One is the default topic, settable by
the owner of the room, and the other is a part of the topic stack.

Think of it like this: The default topic is carved into the wood of
the sign while the other stack topics are slips of paper covering each
other and the wood.

To create a topic sign and set the first stack topic, type: topic
<topic> Note that this command doesn't work once a sign has been
created.  Use the below commands then:

To set the default topic, type: carve <topic> on sign
To write over current stack topic, type: write <topic> on sign
To add a slip to the stack, type: cover sign with <topic>
To remove a slip from the stack, type: uncover sign
To remove the sign, type: remove sign
To clear the stack, type: shake sign


topology

The topology of the MOO universe is determined by the rooms that exist
and the exits that connect them.  Several commands are available for
creating and discovering the topology of the MOO.  Help on them is
available under the following topics:

@dig[1]
      creating new rooms and exits
@add-exit[2]
      adding other players' exits from your rooms
@add-entrance[3]
      adding other player's entrances to your rooms
@exits[4]
      listing all of the conventional exits from your rooms
@entrances[5]
      listing all of the conventional entrances to your rooms
@resident[6]
      listing or changing the residents of your rooms


@tutorial

Type `@tutorial' to begin the JHM tutorial, a set of walk-through
lessons designed to help people get accustomed to MOO.


two-letter-spec

This help text is a quick reference for pronoun_sub format strings.
For explanation, see `help two-letter'[1].

General format:   %<object specifier><information specifier>

Object Specifiers
  %t - this           %d - the dobj     %l - the player location
  %n - the player     %i - the iobj
  Append `l' to refer to that object's location, or `L' for the outermost.

Information Specifiers (capitalizable)
  n - the object's name         ("Susan",   "duck",    "king and queen")
  d - definite-article          ("Susan",   "the duck","the king and queen")
  i - indefinite-article        ("Susan",   "a duck",  "a king and queen")
  o  - the objective pronoun    ("her",     "him",     "them")
  p  - possessive adjective     ("her",     "his",     "their")
  q  - possessive pronoun       ("hers",    "his",     "theirs")
  r  - reflexive pronoun        ("herself", "himself", "themselves")
  s  - subjective pronoun       ("she",     "he,       "they")
  'i - indefinite possessive    ("a duck's")
  'd - definite possessive      ("the duck's")
  'n - possessive title         ("duck's")
  #  - the object's number 

Verbs, Nouns, Properties (capitalizable)
  :(foos) - conjugate the verb `to foo'
  '(foo)  - pluralize the noun `foo' if necessary
  .(foo)  - the object's `foo' property

Other Substitutions
  %${a,d,i,p} - the {arg,dojb,iobj,prep}str 
  %;(statements) - Evaluates statements


@typo

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.


@ungag

Syntax:  @ungag <player or object>
         @ungag everyone

Remove the given player or object (or, in the second form, everyone)
from your 'gag list'.  You will once again see any messages that
result from actions initiated by the ungagged player(s) or objects.
In particular, you will once again be able to hear them if they speak,
emote, or whisper to you.  See `help gagging'[1] for an explanation of
gagging in general.

Example:

Munchkin types:
  @ungag Grover
and is once again able to hear Grover's witty remarks.  Sigh...


@ungag!

Syntax:  @ungag! <player>
         @ungag! everyone

Remove the given player or object (or, in the second form, everyone)
from your `noisy gag list'.  You will once again see any messages that
result from actions initiated by the ungagged player(s) or objects.
In particular, you will once again be able to hear them if they speak,
emote, or whisper to you.  See `help gagging' for an explanation of
gagging in general.


the unix group

The set of people who deal with unix-level administration of the
MOO. They deal with startup, shutdowns, backups, memory usage, and
management of auxiliary processes.

Current members: Wizard.


@unlock

Syntax:  @unlock <object>

Clear any lock that might exist on the given object.  See `help 
locking'[1] for general information about locking.


@unlock_for_open

Syntax:
  @unlock_for_open <container>

Clears the lock which restricts who may open <container>.  See
`help locking'[1] for general information about locking.

See `help containers'[2] for information on containers.


@unrmmail

Syntax:  @unrmmail [list|expunge] [on *<collection>]

When you do @rmmail on a particular message collection, the messages
removed don't go away immediately, but are rather saved elsewhere.
These "zombie" messages can be brought back or examined using the
@UNrmmail command.

Without `list' or `expunge', @unrmm restores the zombie messages, thus
undoing the effect of the most recent @rmmail command.  Only the most
recent @rmmail can be undone in this way; messages deleted by any
previous @rmmail commands on this same collection are lost and gone
forever.

The `list' option merely lists the headers of the zombie messages
without actually restoring them.

The `expunge' option banishes the zombie messages forever.

Note that the message numbers used by zombie messages are held in
reserve against the possibility that you might @unrmm them some day;
with such messages around, new messages received will be given higher
numbers than you might have expected.  @renumber does an implicit
@unrmm expunge.

`@unrmmail' and `@unrmmail expunge' on collections other than your own
are only allowed when you have write access.  Likewise, `@unrmmail
list' on other collections is only possible when they are readable by
you.


@unsubscribe

Syntax:  @skip [<collection>...]
         @unsubscribe [<collection>...]

For each collection of mail messages that you read other from your
own, a current message and a last-read-time is kept.  Normally, if you
neglect to actually @read any messages on a collection other from your
own, @rn (or :check_mail_lists) will continue to remind you that they
are there.

The @skip command indicates that you're not interested in reading the
rest of the messages that currently exist in that given collection.

The @unsubscribe command flushes the current-message/last-read-time
information completely, indicating that you are not only uninterested
in the rest of the messages on that collection, but also likewise
uninterested in anything else that may appear on that collection later
on.  @unsubscribe also removes you from the collection's .mail_notify
list.


@unsubscribed

Syntax:  @rn
         @subscribed
         @unsubscribed

For each collection of mail messages that you read other from your
own, a last-read-time is kept.  The `@rn' command tells you which
collections (out of all those you have ever read) have recently had
messages added to them, i.e., more recently than when you last did a
@read, @prev, @next, or @skip on that collection.

The `@subscribed' command shows all your mailing lists, even those
which have no new mail; the `@unsubscribed' command shows mailing
lists which you haven't read, and indicates how many messages you're
missing out on.

Etymologists' note: If you thought @rn had anything to do with the
popular UNIX newsreading program `rn', it's just your imagination.


@uptime

Syntax:  @uptime

The @uptime command displays the amount of time since the last restart
of the server.

Note to programmers: The last restart time of the server is stored in
$last_restart_time.


@verify-owned

Syntax:  @verify-owned

Checks that all the objects in your .owned_objects property are
actually owned by you, and effects repairs if needed.  See `help
@audit'[1] for more information.


@version

Syntax:  @version

Prints out the version number for the currently-executing MOO server.


walk

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.


whereis

Syntax:  whereis [<player> [<player>...]]
         @whereis [<player> [<player>...]]

Returns the current location of each of the specified players, or of
all players if not arguments given.


whisper

Usage:  whisper "<text>" to <player>

Whisper a message to another person in the same room.  Only you and
the recipient of the whisper will know about it.  Good for keeping
secrets.


@who

Syntax: @who
        @who <player> [<player> ... ]
        @who [<players>] by <order>

        @who in <room>
        @who with <player>

The first form lists all of the currently-connected players, along
with an indication of how long they've been idle, their present
location in the MOO, and their doing/idle string (see `help doing' and
`help idle').

The second form, in which a list of player names is given, shows
information for just those players.  For any listed players that are
not connected, we show the last login time instead of the idle info.

The third form lets you specify a sort order.  (See `help
@who-options'[1].)  You can also specify the players you want to see,
or specify nothing to see everybody who's on.

The fourth and fifth forms show you @who information for everybody in
a given room, or everybody in the same room as a given player,
respectively.

@who's format and sorting order can be modified using @who-options
(see `help @who-options').

Note for builders: @who refers to the @who_location message (see `help
messages'[2]) on each player's location in order to determine what
should be printed in the location column.  Pronoun substitutions are
done on this string in the usual manner (see `help pronouns'[3]).  The
default value is "%Tn" (i.e., the room name).


@who-options, @whooptions

@who-options is an options package (see `help @options'[1]) that allows
you to change the way @who (see `help @who'[2]) and commands that use
it, such as @admins (see `help @admins'[3]), look.

The @who-options are as follows:

o order: One of name, idle, connected, location, and party.  These
  modify the which field @who is sorted by.

o ascending: This setting also affects sorting order.  Toggling it
  will always reverse the current sort order.

o columns: One of name, idle, connected, location, doing, and
  last_disconnect.  This setting is set with the command @who-options
  columns="column1 column2 ..." (the quotes are required).  It
  determines which columns are visible in @who.


The current values for these options are shown using the command
@who-options.



wizard-list, wizards

Please see `help administrators'[1] for information about the people who
run JHM.


@wrap

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.


write

Syntax:  write "<any text>" on <note>

Adds a line of text to the named note or letter.  Only the owner of a
note may do this.


zombie-messages

Syntax:  @unrmmail [list|expunge] [on *<collection>]

When you do @rmmail on a particular message collection, the messages
removed don't go away immediately, but are rather saved elsewhere.
These "zombie" messages can be brought back or examined using the
@UNrmmail command.

Without `list' or `expunge', @unrmm restores the zombie messages, thus
undoing the effect of the most recent @rmmail command.  Only the most
recent @rmmail can be undone in this way; messages deleted by any
previous @rmmail commands on this same collection are lost and gone
forever.

The `list' option merely lists the headers of the zombie messages
without actually restoring them.

The `expunge' option banishes the zombie messages forever.

Note that the message numbers used by zombie messages are held in
reserve against the possibility that you might @unrmm them some day;
with such messages around, new messages received will be given higher
numbers than you might have expected.  @renumber does an implicit @unrmm
expunge.

`@unrmmail' and `@unrmmail expunge' on collections other than your own
are only allowed when you have write access.  Likewise, `@unrmmail list'
on other collections is only possible when they are readable by you.


 


Contact NWE help staff
http://web.nwe.ufl.edu/writing/help/moo/jhc/main_help.html
Updated Thu Aug 23 17:45:10 2001.