This is a listing of the contents of the major LambdaMOO `help' databases 
as of Tuesday, June 2, 1993.  If you're seeing this for the first time, 
you may want to skip down to `help summary'

There are actually several distinct help `databases' that comprise the
LambdaCore/LambdaMOO help system.  Typing `help index' gives a list of all of
the ones that are currently searched when you ask for help on a given topic; 
the actual list is dependent your current player class, (occasionally) on what 
room you are in, and on the value of your .help property (see `help $help' for
details).

LambdaCore provides the following help databases

    General Help Topics ($help)
       help with commands for ordinary players and builders.
       `help gen-index' gives a list of topics.
       [GENERAL]

    Editor Help Topics ($editor_help)
       Information about the editing commands available in the MOO editors
       (@edit, @notedit, the mail editor).
       `help edit-index' gives a list of topics.
       [EDITOR]

    Programmer Help Topics ($prog_help)
       help topics for programmers.  This includes general programming topics 
       and information about commands available to programmers.
       `help prog-index' gives a list of topics.
       [PROGRAMMER]

    Core Utility Help Topics ($core_help)
       This describes various objects and utilities available in LambdaCore,
       often in gory detail.  First-time readers can probably skip this.
       `help core-index' gives a list of topics.
       [CORE]

    Wizard Help Topics ($wiz_help)
       help topics for wizards (system administrators).
       These will most likely only be of interest to those planning to run 
       a LambdaCore-based MOO.
       `help wiz-index' gives a list of topics.
       [WIZARD]

    Builtin Function Help ($builtin_function_help)
       descriptions of server builtin functions.  
       These are lifted straight from the LambdaMOO Programmers' Manual and
       thus are not repeated below.
       `help builtin-index' gives a list of topics.

    Verb Help ($verb_help)
       This help_db extracts documentation strings directly from verbs in 
       response to requests like `help object:verbname'.  
       There is no corresponding index.

In addition, for players on LambdaMOO itself, we also have

    LambdaMOO-Specific Help Topics (#3223 on LambdaMOO)
       help topics for ordinary players on LambdaMOO.  This includes
       descriptions commands that are not in the LambdaCore $player class and
       policies that are peculiar to LambdaMOO itself.
       `help lmoo-index' gives a list of topics.
       [LAMBDA]

    LambdaMOO-Specific Programmer Help Topics (#56204 on LambdaMOO)
       help topics for programmers players on LambdaMOO.
       For now, this just shadows certain topics in Builtin Function Help.
       [LAMBDA-PROG]

What follows is a combined listing of seven of the above help
databases, Except for the initial summary, the texts are listed in
alphabetical order by name (ignoring leading @ or $ signs); this
should make it easy to find any particular text.  For each text, we
indicate with [GENERAL], [EDITOR], [PROGRAMMER], [CORE], [WIZARD],
[LAMBDA], or [LAMBDA-PROG] which of the above databases it came from.

"*subst*" on any given topic indicates that the help text contains
parameters that depend on the current state of the MOO (e.g., `help
registration' depending on what $login:registration_string() returns).
See `help $generic_help' if you really want to know what all of the
%-clauses do in such help-texts.

There is a full list of all topics at the very end.

===== help summary ======[LAMBDA]=============================================

Help is available on the following general topics:

introduction -- what's going on here and some basic commands
index -- index into the help system

players -- setting characteristics of yourself
movement -- moving yourself between rooms
communication -- communicating with other players
manipulation -- moving or using other objects
miscellaneous -- commands that don't fit anywhere else

building -- extending the MOO
programming -- writing code in the MOO programming language
editors -- editing text and code in the MOO

@pagelength -- what to do if lines scroll off your screen too fast
@linelength -- what to do if lines are truncated
tinymud -- a list of equivalences between MOO and TinyMUD concepts/commands



===== help " ======[GENERAL]==============================================
SEE say

===== help # ======[PROGRAMMER]===========================================

#<string>[.<property>|.parent] [exit|player|inventory] [for <code>] returns information about the object (we'll call it <thing>) named by string.  String is matched in the current room unless one of exit|player|inventory is given.
If neither .<property>|.parent nor <code> is specified, just return <thing>.
If .<property> is named, return <thing>.<property>.  .parent returns parent(<thing>).
If <code> is given, it is evaluated, with the value returned by the first part being substituted for %# in <code>.
For example, the command
  #JoeFeedback.parent player for tonum(%#)
will return 26026 (unless Joe has chparented since writing this).

===== help : ======[GENERAL]==============================================
SEE emote

===== help :: ======[GENERAL]==============================================
SEE emote

===== help ; ======[PROGRAMMER]===========================================
SEE eval

===== help ? ======[GENERAL]==============================================
SEE help

===== help abort ======[EDITOR]===============================================

Syntax:  abort

Abandons this editing session and any changes.

===== help @abort-shutdown ======[WIZARD]===============================================

Syntax:  @abort-sh*utdown [<text>]

This aborts any shutdown currently in progress (i.e., set in motion by @shutdown).  All players are notified that no shutdown will actually occur; <text>, if given will be included in this notification.

===== help @add-entrance ======[GENERAL]==============================================

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.

===== help @add-exit ======[GENERAL]==============================================

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

===== help @add-feature ======[GENERAL]==============================================

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

===== help @add-feature ======[PROGRAMMER]===========================================
(continued)
Note to programmers: @add-feature and @remove-feature are front-ends for player:add_feature and :remove_feature.

:add_feature returns

 * E_PERM unless caller == this || $perm_utils:controls(caller_perms())

 * E_INVARG if feature is not an object or is invalid

 * E_PERM if the object is not feature_ok

 * a true value otherwise

and calls feature:feature_add, if the verb exists.

:remove_feature returns

 * E_PERM unless caller == this || $perm_utils:controls(caller_perms()) || caller_perms() == feature.owner

 * a true value otherwise

and calls feature:feature_remove, if the verb exists.

===== help @add-owned ======[GENERAL]==============================================

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 objects is really owned by you and otherwise belongs in your .owned_objects property.  See help @audit for more information.

===== help @addalias ======[GENERAL]==============================================

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, spaces will also be assumed to be separations between aliases and 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.

===== help @addroom ======[LAMBDA]===============================================
SEE @rooms

===== help @addword ======[LAMBDA]===============================================

Syntax: @addword <word or words>
        @addword object.property
        @addword object:verb

Will add all words found and unknown into your personal dictionary.
Your dictionary is stored in a property named ".dict".

===== help alias ======[GENERAL]==============================================
SEE  name

===== help also-to ======[EDITOR]===============================================

Syntax:  also-to [<recipients>]

Synonym: cc

(MAIL ROOM)
Adds additional recipients to the To: line of your message.
Same rules apply as for the `to' command.

===== help @answer ======[GENERAL]==============================================

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

===== help @arb ======[LAMBDA]===============================================

Usage: @arb
       @arb all

This command gives information about the members of the Architecture Review Board (see `help @quota').  Specifically, it gives exactly the same sort of information that the @who command provides.  "@arb" tells you about those members who are currently logged in; "@arb all" tells you about all members.

===== help @args ======[PROGRAMMER]===========================================

Syntax:  @args <object>:<verb-name> <dobj>
         @args <object>:<verb-name> <dobj> <prep>
         @args <object>:<verb-name> <dobj> <prep> <iobj>

Changes the direct object, preposition, and/or indirect object specifiers for the named verb on the named object.  Any specifiers not provided on the command line are not changed.  The direct and indirect object specifiers (<dobj> and <iobj>) must be either 'none', 'this', or 'any'.  The preposition specifier (<prep>) must be either 'none', 'any', or one of the prepositional phrases listed in `help prepositions'.

===== help @audit ======[GENERAL]==============================================

Syntax:  @audit [<player>] [for <string>] [from <number>] [to <number>] 

`@audit'        prints a report of all of the objects you own.
`@audit player' prints the same report for another player.

The `for' string restricts the search to objects whose names begin with that string.
It is also possible to restrict the range of object numbers to include only those above a given number (`from') or below a given number (`to').

All forms of @audit print a report:

   #14 Gemba                          [The Pool]
  #144 Popgun                         [Gemba]
 #1479 Cockatoo                       [The Living Room]
 #1673 Bottom of Swimming Pool       
 #2147 Cavern                        <-*west
 #2148 tunnel                         Bottom of Swimming ->Cavern

The first column is the object's number, the second its name. The third column shows the object's location: Gemba is in The Pool, and is carrying the Popgun (#144).
For exits, the third column shows source ->dest (preceded by a * if owned by someone else).
For rooms, the third column shows any entrances owned by someone else, listed as <-*.

@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 @verify-owned, @sort-owned, and @add-owned.

See also @prospectus, which gives some additional information.

===== help ballots ======[LAMBDA]===============================================
SEE petitions

===== help @ballots ======[LAMBDA]===============================================

Syntax:  @ballots [all]

Prints a list of all open ballots (or, if the argument `all' is given, all
existing ballots) in tabular form, showing each ballot's object number, title,
and vote counts, along with an indication of whether or not you have voted on
it.

===== help $biglist ======[CORE]=================================================

Generic BigList Utilities
----------------------------
$biglist is a collection of routines for maintaining huge persistent (sorted) lists in a format that is less likely to spam the server (which runs into a certain amount of trouble dealing with long ordinary lists --- btw we use `biglist' to refer to the huge data structure we're about to describe and `list' to refer to ordinary MOO lists {...}).  The biglist in question lives on a particular object, to which we will refer in the discussion below as the `home' object, and its various elements appear as leaves of a tree whose nodes are kept in properties of the home object.  It should be noted that the home object does not need to be (and in fact should *not* be) a descendant of $biglist one; $biglist merely provides utilities for manipulating the properties on the home object that are used in a particular biglist manipulation.  

All of the utilities below refer to `caller' to locate the home object.  Thus verbs to manipulate a given biglist must be located on or inherited by its home object itself.  The home object needs to define the following verbs

  :_make(@args)     => new property on home object with value args
  :_kill(prop)      delete a given property that was created by :_make
  :_get(prop)       => home.prop
  :_put(prop,@args) set home.prop = args
  :_ord(element)    given something that is of the form of a biglist element
                    return the corresponding ordinal (for sorting purposes).
                    If you never intend to use :find_ord, then this can be a 
                    routine that always returns 0 or some other random value.

See $generic_biglist_home or $big_mail_recipient for examples.

Those of the following routines that take a biglist argument are expecting
either {} (empty biglist) or some biglist returned by one of the other routines

  :length(biglist)          => length(biglist) (i.e., number of elements)
  :find_nth(biglist,n)      => biglist[n]
  :find_ord(biglist,k,comp) => n where n is
     the largest such that home:(comp)(k,home:_ord(biglist[n])) is false, or
     the smallest such that home:(comp)(k,home:_ord(biglist[n+1])) is true.
     Always returns a value between 0 and length(biglist) inclusive.
     This assumes biglist to be sorted in order of increasing :_ord values 
     with respect to home:(comp)().
     Standard situation is :_ord returns a number and comp is a < verb.

  :start(biglist,s,e)  => {biglist[s..?],@handle} or {}
  :next(@handle)       => {biglist[?+1..??],@newhandle} or {}
     These two are used for iterating over a range of elements of a biglist
     The canonical incantation for doing
        for elt in (biglist[first..last])
          ...
        endfor
     is
        handle = :start(biglist,first,last);
        while(handle)
          for elt in (handle[1])
            ...
          endfor
          handle = :next(@listdelete(handle,1));
        endwhile

The following all destructively modify their biglist argument(s) L (and M).

  :set_nth(L,n,value)  =>  L[n] = value
     replaces the indicated element

  :insert_before(L,M,n) => {@L[1..n-1],@M,@L[n..length(L)]}
  :insert_after (L,M,n) => {@L[1..n],  @M,@L[n+1..length(L)]}
     takes two distinct biglists, inserts one into the other at the given point
     returns the resulting consolidated biglist

  :extract_range(L,m,n) => {{@L[1..m-1],@L[n+1..]}, L[m..n]} 
     breaks the given biglist into two distinct biglists.

  :delete_range(L,m,n[,leafkiller]) => {@L[1..m-1],@L[n+1..]}
  :keep_range  (L,m,n[,leafkiller]) => L[m..n]
     like extract_range only we destroy what we don't want.

  :insertlast(L,value)  => {@L,value}
     inserts a new element at the end of biglist.  
     If find_ord is to continue to work properly, it is assumed that the 
     home:_ord(elt) is greater (comp-wise) than all of the :_ord values
     of elements currently in the biglist.

  :kill(L[,leafkiller]) 
     destroys all nodes used by biglist.  
     Calls home:leafkiller on each element.

===== help blacklist ======[WIZARD]===============================================

The Site Blacklist
------------------
$login maintains three lists of hosts/domains to support player registration schemes and blocking of connections from highly untrusted hosts:

  .redlist   -- all connections from these sites are disabled 
  .blacklist -- player creation and guest logins are disabled
  .graylist  -- advisory list of potential trouble spots (putting a site on the
                .graylist merely annotates it in @net-who listings).

The lists are kept in a special format so it is highly recommended that you 
either use $wiz:@*list/@un*list or the following verbs to query/update the 
respective lists rather than bash them directly:

  $login:*listed     (host)              is host is on .*list?
  $login:*list_add   (domain or subnet)  add domain or subnet to .*list
  $login:*list_remove(domain or subnet)  remove domain or subnet from .*list

where `*' is one of `black', `red', or `gray'.

One may either specify a domain name (e.g., "baz.edu") or a numeric IP address (e.g., "36.0.23.17").  Domain names match all hosts underneath that domain, so, e.g., puting "baz.edu" on a list effectively adds "x.bax.edu" for all x as well.  
Likewise, an incomplete numeric address, e.g., "128.42" will match that entire subnet, in this case all hosts whose IP numbers have the form "128.42.m.n" for arbitrary integers m and n.

One may also give a domain name containing a wildcard ("*"), e.g., "fritz*.baz.edu", in which case all hostnames matching in the sense of $string_utils:match_string() are considred to be on the list.  Wildcard matching should be avoided since it is more time-consuming.

It should be noted that, since there is no direct access to the domain name service from within the MOO, it is possible for a host to be blacklisted or redlisted via its domain name, and yet have someone be able to connect from that host (and, in the case of a blacklisted host, create a character) --- this can happen if the name service is down and connection_name() on that player thus has given the numeric IP address rather than the domain name.  Similarly, if you list a host by IP number alone, it will still be possible to get in via the site's domain name.  Thus to be completely assured of shutting out a site, you need to list it both by domain name and IP number.

===== help @blacklist ======[WIZARD]===============================================

Syntax:  @redlist   [<domain or subnet> [commentary]]
         @blacklist [<domain or subnet> [commentary]]
         @graylist  [<domain or subnet> [commentary]]

Syntax:  @unredlist   [<domain or subnet> [commentary]]
         @unblacklist [<domain or subnet> [commentary]]
         @ungraylist  [<domain or subnet> [commentary]]

With no argument, the current contents of the <color>list are printed.
Otherwise, the specified domain or subnet is added to or removed from the list and mail will be sent to $site_log.  

If the given domain or subnet has subdomains/subsubnets that are already on the list, you will be prompted as to whether you want to remove them.  Note that adding an entry for a particular domain or subnet effectively adds all subdomains/subsubnets, so unless there's some reason for keeping an explicit entry for a particular subdomain, chances are you will indeed want to remove them.  One reason to keep an explicit entry for a subdomain would be if you intended to unlist the full domain later but wanted to be sure you didn't unlist the subdomain in the process.

See `help blacklist' for a description of the functions of these <color>lists.

===== help @bug ======[GENERAL]==============================================
SEE @typo

===== help building ======[GENERAL]==============================================

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 -- making, unmaking, and listing your rooms, exits, and other objects
topology -- making and listing the connections between rooms and exits
descriptions -- setting the names and descriptive texts for new objects
locking -- controlling use of and access to your objects

===== help building ======[LAMBDA]===============================================
(continued)
Please see 'help theme' for policy about what kind of building is appropriate.

===== help burn ======[GENERAL]==============================================

Syntax:  burn <letter>

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

===== help cc ======[EDITOR]===============================================
SEE also-to

===== help @check ======[GENERAL]==============================================

Syntax:   @check <options>

where <options> is one or more of:
-- the number of lines to be displayed
-- a player's name, someone to be "trusted" during the assignment of responsibility for the message.
-- a player's named prefixed by !, someone not to be "trusted".

          @check-full <options>
where <options is either 
-- the number of lines to be displayed
-- a search string: only lines containing that string will be displayed.

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:
    what object the message came from,
    what verb on that object that was responsible,
    whose permissions that verb was running with, and
    the beginning of the actual message.

Output from @check-full is in columns that contains a description of all the verbs that were responsible for the noise heard, not just the best guess as to who was responsible.

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

===== help @check-chparent ======[PROGRAMMER]===========================================

Syntax:  @check-property <object>.<propname>
         @check-chparent <object> to <newparent>
         
You cannot add a new property to an object if an ancestor or a descendant already defines a property with the same name.  @check-property will give you the list of all descendants of <object> that that define .<propname>.  

Likewise you cannot chparent an object to a new parent if the new parent has a property that is also defined on the object or some descendant.  Use @check-chparent to find out all instances of conflicting properties that would interfere with @chparent in this manner.

Note that @check-property requires either that you own the object or that it be writeable, the same conditions that need to hold if you are to create new properties on the object.  Similarly, @check-chparent requires that you own the object and that the new parent is either fertile or likewise owned by you.

For objects with large numbers of descendants, these commands can be time-consuming.

===== help @check-property ======[PROGRAMMER]===========================================
SEE @check-chparent

===== help @chmod ======[PROGRAMMER]===========================================

Syntax:  @chmod <object> <object-permissions>
         @chmod <object>.<prop-name> <property-permissions>
         @chmod <object>:<verb-name> <verb-permissions>

Changes the permissions of an object, property or verb, to those given.  The following table shows what permission bits are allowed for each form of the command:
        <object-permissions>        r, w, f
        <property-permissions>      r, w, c
        <verb-permissions>          r, w, x, d

See the LambdaMOO Programmer's Manual for their meanings.

To clear all of the permissions for an object, verb, or property, use "" as the second argument.

@chmod also accepts +, !, and - as modifiers for a single permission to add or subtract that permission from the current set.  (! and - are the same.)

Examples:

Set a verb to be Readable and Callable:
  @chmod chair:sit rx

Set a verb to be not Callable, without changing its other permissions:
  @chmod cookies:eat !x

Set an object to be Writeable in addition to any current bits:
  @chmod table +w

===== help @chown ======[WIZARD]===============================================

Syntax:  @chown <object>            [to] <owner>
         @chown <object>.<propname> [to] <owner>
         @chown <object>:<verbname> [to] <owner>

Changes the ownership of the indicated object, property or verb.

Verb ownership changes are fairly straightforward, being merely a matter of changing the verb_info() on a single verb.

Changing an object ownership includes changing the ownership on all +c properties on that object.  Note that @chown will not change the ownership of any other properties, nor will it change verb ownerships.  Use @grant if you need to do a more complete ownership change.  The quota of the former owner is increased by one, as is the quota of the new owner decreased by one.

Changing a property ownership is truly hairy.  If the property is +c one shouldnot be doing this, unless it is to correct a past injustice which caused the property to be owned by the wrong player.  In the case of -c properties, the property ownership is changed on all descendent objects (currently, if +c instances of a -c property are found in the traversal of all of the descendants, these are not changed, being deemed sufficiently weird that they should be handled on a case-by-case basis...).

If there's any justice, a future version of the server will prevent occurrences of (1) +c properties being owned by someone other than the object owner (2) -c properties with different owners on descendant objects (3) -c properties that are +c on some descendants.

===== help @chparent ======[PROGRAMMER]===========================================

Syntax:  @chparent <object> to <new parent>

Changes the parent of the named object to be the named parent.  The object acquires all the verb and property definitions of its parent.  Newly acquired properties are initilialized with `clear' values so that they inherit whatever values are currently assigned to the parent's corresponding properties (see `help @clearproperty').

If the player does not own <new parent>, it must have been set `fertile'.  <object> must be owned by the player.  Neither <object> nor any descendant can define any property which already exist on <new parent>.  Use @check-chparent (see `help @check-chparent') to list such property conflicts.

It is also sometimes the case that you will own some object and want to @chparent some child of that object that you do not own.  Use @disinherit (see `help @disinherit') in such situations.

===== help @classes ======[GENERAL]==============================================

Syntax:  @classes
         @classes <class-name> ...

The wizards have identified several useful classes of objects in the database.  The @classes command is used to see which classes exist and what their member objects are.

The first form simply lists all of the defined classes along with short descriptions of the membership of each.

The second form prints an indented listing of that subset of the object parent/child hierarchy containing the objects in the class(es) you specify.

===== help @clearproperty ======[PROGRAMMER]===========================================

Syntax:   @clearproperty <object>.<prop-name>

This clears <object>'s <prop-name> property.  That is the property value becomes `clear' and all further references to this property will use the value of the same property on the parent object.  Note that you can only clear inherited properties.  Nor is this the same as removing a property; the property continues to exist.

`@clearproperty' can be abbreviated as `@clearp'.

Example:

  @create #1 named foo
  You now have foo with object number #42 and parent Root Class (#1).
    [foo, as a child of #1 has a .description property which starts out clear]
  ;#1.description
  => ""
  ;#1.description = "You see nothing special"
  => "You see nothing special"
  ;#42.description  
  => "You see nothing special"
  ;#42.description = "Something special"
  => "Something special"
   [foo.description is now no longer clear; it has a value of its own]
  ;#1.description = "Boring"
  => "Boring"
  ;#42.description  
  => "Something special"
   
  @clearp foo.description
  Property #42.description cleared; value is now "Boring".
   [foo.description is now clear again]
  ;#1.description = ""
  => ""
  ;#42.description
  => ""

===== help commands ======[GENERAL]==============================================
SEE summary

Type 'help <topic>' for information on a particular topic.


===== help @comment ======[GENERAL]==============================================
SEE @typo

===== help common_quota ======[GENERAL]==============================================

Syntax:  @quota

Each player has a limit as to how many objects that player may create, called their 'quota'.  Every object they create lowers the quota by one and every object they recycle increases it by one.  If the quota goes to zero, then that player may not create any more objects (unless, of course, they recycle some first).

The @quota command prints out your current quota.

The quota mechanism is intended to solve a long-standing problem in many MUDs: database bloat.  The problem is that a large number of people build a large number of dull objects and areas that are subsequently never used or visited.  The database becomes quite large and difficult to manage without getting substantially more interesting.  With the quota system, we can make it possible for players to experiment and learn while simultaneously keeping random building to acceptable levels.

===== help communication ======[GENERAL]==============================================

There are several commands available to allow you to communicate with your fellow MOOers.  Help is available on the following communication-related topics:

say      -- talking to the other connected players in the room
whisper  -- talking privately to someone in the same room
page     -- yelling to someone anywhere in the MOO
emote    -- non-verbal communication with others in the same room
gagging  -- screening out noise generated by certain other players
news     -- reading the wizards' most recent set of general announcements
@gripe   -- sending complaints to the wizards
@typo @bug @idea @suggest
         -- sending complaints/ideas to the owner of the current room
whereis  -- locating other players
@who     -- finding out who is currently logged in
mail     -- the MOO email system
security -- the facilities for detecting forged messages and eavesdropping.

===== help compile ======[EDITOR]===============================================

Syntax:  compile [as <object>:<verb>]

(VERB EDITOR)
Installs the new program into the system if there are no syntax errors.
If a new object:verb is specified and actually turns out to exist, that <object>:<verb> becomes the default for subsequent compilations.

===== help @complete ======[LAMBDA]===============================================

Syntax:  @complete prefix

This verb is part of the MOO spelling checker.  It will show you all the words in the dictionary that start with the prefix letters you specify.  You should be specific as to what you're looking for (for example, you might use @complete comput, rather than @complete co) in order to avoid getting an excessive number of words output.

Refer to help spelling for more information.

===== help $container ======[CORE]=================================================

The Generic Container (for programmers)

In addition to the command verbs described under `help containers'
and the _msg properties described in `help container-messages',
the following verbs and properties are available for use within programs

.opened == TRUE iff the container is open
.dark   == TRUE iff the contents of the container may be seen
.opaque -- describes the correlation between .open and .dark
   == 0  container is always !dark
   == 1  container is dark iff it is closed
   == 2  container is always dark              

:set_opaque(newvalue)   
  changes the .opaque value for the container
  => newvalue or E_PERM or E_INVARG

:set_opened(newvalue)   
  opens/closes the container (updates .open and .dark) according to newvalue
  => newvalue or E_PERM

:is_openable_by(player) 
 what the :open command uses to test whether the player should be able to open
 the container.  By default this refers to .open_key  (set by
 @(un)lock_for_open), but the object owner is free to customize this.

N.B.:  There is no way to directly set .dark; .dark can be changed only by 
changing one of .opaque or .opened.  Use :set_opaque(0) and :set_opaque(2)
to have .dark change independently of the value of .opened.

===== help container-messages ======[GENERAL]==============================================
*subst*
Several kinds of messages can be set on a container object; they are printed to various audiences at certain times whenever an attempt is made to use the container.  The ones whose names begin with 'o' are always shown prefixed with the name of the player making the attempt and a single space character.  The standard pronoun substitutions (with respect to the player) are made on each message before it is printed; see 'help pronouns' for details.

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

@empty[%[$container.empty_msg]]
  Printed in place of the contents list when the container is empty.

@open  [%[$container.open_msg]]
  Printed to the player who successfully opens the container.

@oopen  [%[$container.oopen_msg]]
  Printed to others in the same room if the player successfully opens the container.

@open_fail  [%[$container.open_fail_msg]]
  Printed to the player who cannot open the container.

@oopen_fail  [%[$container.oopen_fail_msg]]
  Printed to others in the room when a player fails to open a container.

@close  [%[$container.close_msg]]
  Printed to the player who closes a container.

@oclose  [%[$container.oclose_msg]]
  Printed to others in the room when a player closes a container.

@put  [%[$container.put_msg]]
  Printed to a player when an object is successfully placed in a container.

@oput  [%[$container.oput_msg]]
  Printed to others in the room when a player successfully places an object in a container.

@put_fail  [%[$container.put_fail_msg]]
  Printed when a player fails to put an object in a container.

@oput_fail  [%[$container.oput_fail_msg]]
  Printed to others in the room when a player fails to place an object in a container.

@remove  [%[$container.remove_msg]]
  Printed when a player succeeds in removing an object from a container.

@oremove  [%[$container.oremove_msg]]
  Printed to others in the room when a player succeeds in removing an object from a container.

@remove_fail  [%[$container.remove_fail_msg]]
  Printed when a player fails to remove an object from a container.

@oremove_fail  [%[$container.oremove_fail_msg]]
  Printed to others in the room when a player fails to remove an object from a container.

===== help containers ======[GENERAL]==============================================

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 -- putting an object into a container
remove -- taking an object out of a container

Containers may be open or closed, using the verbs 'open container' and 'close container'.  Containers have a separate lock to determine if a player may open them.  See the following help topics:

@lock_for_open -- setting the lock for opening a container
@unlock_for_open -- clearing the lock

You can make a container by creating a child of the standard container, $container (see 'help @create').

Containers have a large number of messages which get printed when players act upon them.  See 'help container-messages' for more information.

Containers have opacity.  See 'help @opacity' for more information.

===== help @contents ======[GENERAL]==============================================

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)

===== help copy ======[EDITOR]===============================================

Syntax:  c*opy [<range>] to <ins>

Copies the specified range of lines to place given by <ins>.
If <ins> happens to be the current insertion point, the insertion 
point moves to the end of the inserted lines.

See `help insert' for a list of possibilities for <ins>.

===== help @copy ======[PROGRAMMER]===========================================

Syntax:  @copy <object>:<verb> to [<newobject>][:<newverb>]

Copies the code of the named verb to the new object and verbname.  Permissions, and arguments of the new verb are set to match those of the old verb in the event that the new verb does not already exist.  One of <newobject> or :<newverb> must be supplied.  If no new verbname is given, the old name is retained.  Likewise, <newobject> defaults to <object> if not given.

Examples:
  @copy me:verbname to myobject
  @copy me:test_verb to myobject:real_verb

In general, @copy'ing verbs is a bad idea.  In the vast majority of cases, the desired effect can be accomplished with parenting (i.e., having <object> be an ancestor of <newobject>), which has the advantage that if a verb is updated or fixed, this immediately becomes available to child objects that inherit this verb.  In such a case, copies that were made using @copy have to be tracked down and fixed by hand.

This facility is provided for those rare occasions where one has no choice but to actually copy the verb.

===== help @count ======[GENERAL]==============================================

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.

===== help cracking ======[LAMBDA]===============================================

Famous last words:
  ``I really only wanted to see if it could be done.''
  ``I wasn't going to wreck anything.  Honest.''
  ``Geez, you've got that huge hole there; you're just asking for it.''

It's a natural thing to wonder about holes in the system and how easy it is to break in, whether it be to get yourself a wizard bit (i.e., by nefarious means that don't involve asking for one) or do other neat things that should normally require a wizard bit.  Doubtless, some would consider a successful break-in to be a spectacular achievement, a mark of programming machismo, so to speak.  Some would suppose that this entitles them to a wizard bit, or to do anything they like to the database.  This is highly debatable.  

If I accidentally drop my keys somewhere in my front yard and you manage to find them, this is not likely to mark you as a master locksmith, no matter how much time you spent painstakingly examining every square inch of turf.  Though I'll probably be happy to get my keys back and might even be inclined to give some sort of reward, the mere act of finding the keys does not entitle you to go through the house and take anything that interests you.  Nor does it entitle you to make copies of the keys before giving them back to me --- I'll say nothing of your expecting me to sign over the title to the house.  Moreover, I'll be extremely annoyed if I have to take the time to search through the house in order to make sure nothing is missing, likewise if I have to change the locks.

You may be entirely innocent, but you have to be careful just the same.

It may seem like a shoot-the-messenger policy when in fact we actually LIKE having security holes found.  The key point is that, if you SAVE us time by finding a hole for us, then we're happy.  But, if you COST us time because we're not absolutely sure we can trust you and have to grep the db looking for any Trojan horses we think you might have planted, then we're not happy.  If having you around costs us more time than it saves, then, suffice it to say, you won't be around and we can go to some fairly extravagant lengths to try to ensure this.

Thus, if you're going to hunt security holes, you MUST understand the rules of the game.  It's particularly important here, since in matters of security, we can't take chances; while we do take regular checkpoints, vandals can still make life miserable for everyone.  Thus, it's @toad first, ask questions later.

So here are the cardinal rules:

1.  If you find out about a major security hole, you tell us AS SOON AS 
    POSSIBLE.  Nor does it matter HOW you find out, i.e., whether you find 
    it yourself or someone else points it out to you.

It's the mere existence of the hole that's a problem.  *You* may not intend to do anything evil, but there are other people around who are at least as bright as you, including some that are significantly less scrupulous, and it only takes one to do damage.

What is a major security hole?  You'll know it when you see it.  Figure if you can use it to set your wizard bit then it's major.  There are also minor security holes (e.g., finding a way to read $site_db) which we also like to find out about, but for which one is unlikely to suffer a summary @toading (unless of course, a major security hole was involved in creating the minor security hole).

2.  If you find something you think might be a security hole but needs
    an experiment to verify, you consult us FIRST.

One problem is your experiment might succeed.  If we should happen to catch you (and there are various hooks and tasks out there that watch for certain things) before you get a chance to tell us, you may find yourself in the unenviable position of having to PROVE that you actually were intending to tell us about it; if you are someone we only know as an ascii byte stream, we won't be in a very good position to judge your intentions.

Another problem is your experiment might fail but manage to leave some kind of mess behind which we'd have to clean up in which case we're not going to be terribly happy.  Also if it looks to us like you were trying to take advantage of a security hole and weren't going to tell us if you had succeeded, then you'll be in a situation roughly similar to that of the previous paragraph, albeit better for not having succeeded, but it could still mark you as someone not to be trusted.

3.  If you do a particularly simple experiment to break security, something 
    that you didn't seriously think would work (and thus didn't think was
    worth bothering us with), but find that, against all odds, it does, 
    you should TELL us IMMEDIATELY.

Okay, so you did something silly like `;player.wizard = 1' and it worked!  You might infer from (2) that you're already screwed no matter what you do.  The bottom line, however, is that if you tell us immediately, then you're in a much BETTER position than if you DON'T tell us.  Chances are, if you can manage to tell us BEFORE we catch you, and you're careful not to give us any reason to believe you took advantage of the hole, you'll emerge unscathed.

No promises, though.

===== help @create ======[GENERAL]==============================================

Syntax:  @create <class-name> named "<names>"
         @create <parent-object> named "<names>"

The main command for creating objects other than rooms and exits (for them, see 'help @dig'; it's much more convenient).

The first argument specifies the 'parent' of the new object: loosely speaking, the 'kind' of object you're creating.  <class-name> is one of the four standard classes of objects: $note, $letter, $thing, or $container.  As time goes on, more 'standard classes' may be added.  If the parent you have in mind for your new object isn't one of these, you may use the parent's name (if it's in the same room as you) or else its object number (e.g., #4562).

The <names> are given in the same format as in the @rename command:
        <name-and-alias>,<alias>,...,<alias> [preferred]
        <name>:<alias>,...,<alias> [not preferred]

See 'help @rename' for a discussion of the difference between a name and an alias.

===== help creation ======[GENERAL]==============================================

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 -- conveniently building new rooms and exits
@create -- making other kinds of objects
@recycle -- destroying objects you no longer want
@quota -- determining how many more objects you can build
@count -- determining how many objects you already own
@audit -- listing all of your objects
@classes -- listing all of the public classes available for your use
@realm -- listing the parenting tree for objects owned by one or more players
@move -- moving your objects from place to place

===== help @cspell ======[LAMBDA]===============================================

Syntax: @cspell <any number of words>
        @cspell object.property
        @cspell object:verb

Like @spell, but attempts to guess at correct spellings for words it believes are spelled incorrectly.   This verb can be quite slow, so correcting large chunks of text may not be a good idea.

Refer to help spelling and help @spell for more information.

===== help @dbsize ======[PROGRAMMER]===========================================

Syntax:  @dbsize

@dbsize goes through the entire database, counting the valid and invalid objects, giving a summary at the end.  This information can be useful, but because this command is cpu intensive, it should be used sparingly.

===== help decrypt ======[GENERAL]==============================================

Syntax:  decrypt <note>

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

===== help defense ======[LAMBDA]===============================================

Unfortunately, not everyone is nice, and it is sometimes necessary to take action to protect oneself from the destructive actions of others.  Here is a quick summary of the things you can do to protect yourself.

@gag:
  Some people delight in saying nasty things, or just saying so much that your screen fills up and you can't do anything.  @gag prevents you from seeing any text that the person is producing.  See help @gag for details.

@refuse:
  This is a fairly general facility with lots of options.  See help @refuse for details.  Here are a couple of common examples (these aren't exact commands: see help @refuse!)

@refuse move:
  Some people delight in moving you from place to place without your consent.  This can be terribly confusing, and also makes it difficult to do anything.

@refuse mail:
  After someone notices you've gagged them, they might start sending you lots of mail.  This will help you avoid that problem.

@refuse page:
@refuse whisper:
  Sometimes you only want to refuse a little bit; someone is mostly OK, but they're paging you too much.  This will help with that.

Hopefully you won't come in contact with people who force you to use the above commands, but just in case you do, they're here to help.

===== help delete ======[GENERAL]==============================================

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.

===== help delete ======[EDITOR]===============================================

Syntax:  del*ete [<range>] 

(EDITOR)
Deletes the specified range of lines
<range> defaults to the line *before* the current insertion point.

===== help @denewt ======[WIZARD]===============================================

Syntax:    @denewt <player> [commentary]

Synonyms:  @unnewt
           @get-better

@denewt reverses the effects of @newt, moving a player's :denewt_confunc back to :confunc, but checking first that :confunc is the same as $wiz_utils:newt_confunc (if not, we save :confunc as :newt_confunc and complain).

Mail is sent to $newt_log including any commentary you provide.  E.g.,

  @denewt Twit  He promises not to do it again.

===== help depublish ======[EDITOR]===============================================
SEE unpublish

===== help @describe ======[GENERAL]==============================================

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.

===== help descriptions ======[GENERAL]==============================================

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 -- setting the name and aliases of your objects
@describe -- setting what others see when they look at your objects
messages -- listing and setting the other descriptive texts on an object

===== help @detoad ======[WIZARD]===============================================
SEE @untoad

===== help @dig ======[GENERAL]==============================================

Syntax:  @dig "<new-room-name>"
         @dig <exit-spec> to "<new-room-name>"
         @dig <exit-spec> to <old-room-object-number>

This is the basic building tool.  The first form of the command creates a new room with the given name.  The new room is not connected to anywhere else; it is floating in limbo.  The @dig command tells you its object number, though, so you can use the @move command to get there easily.

The second form of the command not only creates the room, but one or two exits linking your current location to (and possibly from) the new room.  An <exit-spec> has one of the following two forms:
        <names>
        <names>|<names>
where the first form is used when you only want to create one exit, from your current room to the new room, and the second form when you also want an exit back, from the new room to your current room.  In any case, the <names> piece is just a list of names for the exit, separated by commas; these are the names of the commands players can type to use the exit.  It is usually a good idea to include explicitly the standard abbreviations for direction names (e.g., 'n' for 'north', 'se' for 'southeast', etc.).  DO NOT put spaces in the names of exits; they are useless in MOO.

The third form of the command is just like the second form except that no new room is created; you instead specify by object number the other room to/from which the new exits will connect.

NOTE: You must own the room at one end or the other of the exits you create.  If you own both, everything is hunky-dorey.  If you own only one end, then after creating the exits you should write down their object numbers.  You must then get the owner of the other room to use @add-exit and @add-entrance to link your new exits to their room.

Examples:
    @dig "The Conservatory"
creates a new room named "The Conservatory" and prints out its object number.
    @dig north,n to "The North Pole"
creates a new room and also an exit linking the player's current location to the new room; players would say either 'north' or 'n' to get from here to the new room.  No way to get back from that room is created.
    @dig west,w|east,e,out to "The Department of Auto-Musicology"
creates a new room and two exits, one taking players from here to the new room (via the commands 'west' or 'w') and one taking them from the new room to here (via 'east', 'e', or 'out').
    @dig up,u to #7164
creates an exit leading from the player's current room to #7164, which must be an existing room.

===== help @disinherit ======[PROGRAMMER]===========================================

Syntax:   @disinherit <object> 
          @disinherit <object> [from <parent>]

Synonym:  @disown

This command is used to remove an unwanted child from an object you own.  If you owned said child, you could use @chparent; this command is to cover the other case, namely where you don't own the child.  

Both forms of this command chparent <object> to its grandparent, provided you own the parent.  The second form matches the string you supply for <object> against the list of children of the given <parent>.

Turning off the fertile bit (.f) for a particular object prevents others from creating children of it or chparenting to it (see `help @chmod').
Note also that, though the name might seem to indicate otherwise, this command does not change the ownership of any object.

===== help @disown ======[PROGRAMMER]===========================================
SEE @disinherit

===== help @display ======[PROGRAMMER]===========================================

Syntax: @display <object>.[property]
                         ,[inherited_property]
                         :[verb]
                         ;[inherited_verb]

@display is a fancy version of @show.  As @show, it can select individual verbs or properties to display.  In addition, it can display all the verbs or properties defined on an object, or all the verbs or properties defined on any of the object's ancestors.  Don't specify a property or verbname after the punctuation mark to get the "all" feature.  Its display is more compact than that of @show (it uses a one-line format, and truncates values that don't fit in the value field).

You may mix properties and verbs on the command line, but the parser may become confused.  (E.g. @display object,: displays all properties including inherited ones plus all locally defined verbs on the object.)

Examples:
Individual property:
  @display poolsweep.count
  .count                   yduJ (#68)            r c    8

Individual verb:
  @display poolsweep:tell
  #3560:tell                     yduJ (#68)           rxd    this none this

All properties, including one truncated value:
  @display poolsweep.
  poolsweep (#3560) [ readable ]
    Owned by yduJ (#68).
    Child of generic thing (#5).
    Location The Pool (#1428).
  .gagged                  yduJ (#68)            r c    0
  .count                   yduJ (#68)            r c    8
  .messages                yduJ (#68)            r c    {"The poolsweep stir..
  .index                   yduJ (#68)            r c    2
  .quantum                 yduJ (#68)            r c    20

Inherited verbs, edited for brevity, showing verbs from various parents, with owners, permissions, and argument lists.
  @d poolsweep;
  poolsweep (#3560) [ readable ]
   #3560:tell                     yduJ (#68)           rxd    this none this
   #3560:description              yduJ (#68)           rxd    this none this
      #5:"g*et t*ake"             Haakon (#2)          rxd    this none none
      #5:"d*rop th*row"           Haakon (#2)          rxd    this none none
      #5:moveto                   Haakon (#2)          rxd    this none this
      #1:description              Haakon (#2)          rxd    this none this
      #1:look_self                Haakon (#2)          rxd    this none this

Some aspects of @display can be customized (see `help @display-options').

===== help @display-options ======[PROGRAMMER]===========================================

Syntax:  @display-option
         @display-option <option>

Synonym:  @displayoption

The display options customize the behavior of the @display command to your particular taste.  The first form of this command displays all of your display options.  The second form displays just that one option, one of the flags listed below.

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

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

These respectively set and reset the specified flag

-blank_tnt     Show the verb args on all verbs.
+blank_tnt     Don't show the verb args on `this none this' verbs.
-shortprep     Use full prepositions  (e.g., "on top of/on/onto/upon")
+shortprep     Use short prepositions (e.g., "on")
-thisonly      Specifying . (:) to retrieve all properties (verbs) will go
               up the ancestor chain until it finds a readable object with
               properties (verbs) defined on it.
+thisonly      Specifying . (:) to retrieve all properties (verbs) will only
               display properties (verbs) defined on the object itself.

===== help @displayoptions ======[PROGRAMMER]===========================================
SEE @display-options

===== help done ======[EDITOR]===============================================
SEE quit

===== help drop ======[GENERAL]==============================================

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.

===== help @dump ======[GENERAL]==============================================

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.
   id=#<id> -- specifies an idnumber to use in place of the object's actual id (for porting to another MOO)
   noprops  -- don't show properties.
   noverbs  -- don't show verbs.
   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.

===== help @dump-database ======[WIZARD]===============================================

Syntax:  @dump-database

Invokes the builtin dump_database(), which requests that the server checkpoint the database at its next opportunity.  It is not normally necessary to call this function; the server automatically checkpoints the database at regular intervals; see the chapter on server assumptions about the database for details.

===== help edit ======[EDITOR]===============================================

(VERB EDITOR)
Syntax:  edit <object>:<verb>

Changes what verb you are editing and loads the code for that verb
into the editor. 
Equivalent to @edit <object>:<verb>.

(NOTE EDITOR)
Syntax:  edit <note-object>
         edit <object>.<property>

Changes to a different note or a different object text property and 
loads its text into the editor.
These are equivalent to @notedit <note> or @notedit <object>.<property>
respectively.

For both the verb-editor and note-editor commands, <object> will match on the room you came from, though if the room you came from was another editor, then all bets are off...

===== help @edit ======[PROGRAMMER]===========================================

Syntax:  @edit <object>:<verb-name> [<dobj> [<prep> [<iobj>]]]

Enters the MOO Verb Editor for the named verb on the named object.  See 'help editors' for more detail.

===== help @edit-options ======[GENERAL]==============================================

Syntax:  @edit-option
         @edit-option <option>

Synonym:  @editoption

The edit options customize the behavior of the various editors (mail editor, verb editor, etc...) to your particular taste.  The first form of this command displays all of your edit options.  The second form displays just that one option, one of the flags listed below.

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

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

These respectively set and reset the specified flag

-quiet_insert    insert (") and append (:) echo back the line numbers
+quiet_insert    insert (") and append (:) produce no output
-eval_subs       (VERB EDITOR) ignore .eval_subs when compiling verbs
+eval_subs       (VERB EDITOR) apply .eval_subs to verbs being compiled
-local           Use in-MOO text editors.
+local           Ship text to client for local editing.

===== help @editoptions ======[GENERAL]==============================================
SEE @edit-options

===== help editors ======[GENERAL]==============================================

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.

===== help @egrep ======[PROGRAMMER]===========================================
SEE @grep

===== help @egrep ======[WIZARD]===============================================
SEE @grep

===== help @eject ======[GENERAL]==============================================

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' for a list of messages one can set regarding the @eject command.

===== help emote ======[GENERAL]==============================================

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.

===== help emote ======[EDITOR]===============================================

Syntax: emote <text>
        :<text>

(EDITOR)
Appends <text> to the end of the line before the insertion point.
The second form is equivalent to the first except that it doesn't strip leading blanks off of <text> (just as with the normal `emote' and `:' commands).
The insertion point is left unmoved.

    >list .
    _37_ Hello there
    ^38^ Oh, I'm fine.
    >:, how are you
    Appended to line 37.
    >:?
    Appended to line 37.
    >list .
    _37_ Hello there, how are you?
    ^38^ Oh, I'm fine.


===== help encrypt ======[GENERAL]==============================================

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' for information on the syntax and semantics of key expressions.  Only the owner of a note may do this.

===== help enter ======[EDITOR]===============================================

Syntax:  enter

(EDITOR)
Enters a sequence of lines at the insertion point (see `help insert').
This is similar to .program in that every line you type after the `enter' command is inserted verbatim into the text until you type a line with a single period (`.') on it.  This command is essentially for if you don't like the idea of putting " at the beginning of each line you type.  The only exceptions, i.e., lines that are not entered verbatim (aside from the `.' line), are

 - If you type a line whose sole text is `@abort', 
   that aborts this command without making any changes to the text.  
 - Any line whose first nonblank character is `.' and has additional text
   is entered but with its first `.' stripped off.  

Thus, to enter a line whose text is `@abort', you could enter it as `.@abort'.

===== help @entrances ======[GENERAL]==============================================

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.

===== help erase ======[GENERAL]==============================================

Syntax:  erase <note>

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

===== help $error ======[CORE]=================================================

$error
------

The Error Generator, $error, may be used to automatically generate errors. This is particularly useful if you are working in a !d verb but have occasion to -want- to crash with traceback. To raise a specific error, use $error:raise(error type) -- for example, $error:raise(E_PERM) will produce traceback resulting from a Permission Denied error.

Random notes about $error:

+ The complete list of errors is stored in $error.names.
+ The seemingly useless :accept() verb on $error is so that $error:E_RECMOVE and $error:E_NACC will be guaranteed success (success meaning, of course, a termination by traceback).
+ There is, unfortunately, no way to raise the error E_NONE.

===== help errors ======[PROGRAMMER]===========================================

*errors*
The complete list of error codes:


===== help eval ======[PROGRAMMER]===========================================

Syntax:  eval <MOO-code>
         ; <MOO-code>
         eval-d <MOO-code>

Evaluates the given piece of MOO code and prints the resulting value.  If the MOO code begins with one of the MOO language keywords ('if', 'for', 'while', 'fork', or 'return') or with the character ';', then the entire piece of code is treated as the program for a verb, with ';' appended to the end.  Otherwise, 'return' is appended to the front and ';' is appended to the end and that string is treated as the code for a verb.  In either case, the resulting verb is invoked and whatever value it returns is printed.

For programmers, this is such a mind-bogglingly useful thing to do that there is a simple abbreviation for this command; any command beginning with a semicolon (';') is treated as a use of 'eval'.

Eval treats specially a duplicated semicolon at the beginning.  It enables you to make multi-statement programs within eval (but does not by default print the return value).

Eval-d (no ";" abbreviation for this) evaluates the following text exactly as eval, except that the "d" debug flag (see programmer's manual for explanation) is turned off.  Thus errors will cause an error return value rather than a traceback.

If you set the player property .eval_time to 1, then eval will print out how many ticks and seconds the program required.

Examples:
   eval 3 + 4
   =>  7
   ;3+4
   =>  7
   ;for x in (player.aliases) player:tell(x); endfor
   Haakon
   Wizard
   ArchWizard
   =>  0
   ;;l = {}; for i in [1..10] l = {@l, i}; endfor return l
   =>  {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}
   eval-d 8 + "foo"
   => E_TYPE  (Type mismatch)

You may customize your evaluation environment.  The player property .eval_env may contain statements to be executed prior to any evaluated program.  Two caveats:  This will throw off the tick count.  You can account for additional ticks inserted by your environment with the .eval_ticks property; just set it to the number of ticks you'd like subtracted from the total.  Additionally, if you make a syntax error in your program, the line reported will be wrong (it will count those initial statements), and if you make an error in the eval_env itself, you can be in deep trouble.  Despite these drawbacks, the eval_env property can be quite useful.  The following is a sample:

Eval_env:    "me=player;here=player.location;"
eval_ticks:  3

See also @setenv.

You can also define textual substitutions in a separate property, called eval_subs.  These are discouraged, however, for anything that can be done with variable assignments, because the overhead of replacing the strings in the evaluated program is significant.  However, some things, such as substituting characters which can't be typed easily on one keyboard (e.g. "[]" is difficult to type on some IBM keyboards), can only be done by textual substitutions.  Note that the eval substitutions are also interpreted by the verb editor when "eval_subs" is selected in your .edit_options property (see `help editors').  This adds to their overhead, but again, makes it possible for people to program who otherwise can't type the full character set.  Remember:  Don't use eval_subs unless you really have to!

===== help examine ======[GENERAL]==============================================

Syntax:  examine <object>
         exam <object>

Prints several useful pieces of information about the named object, including the following:
        + its full name, object number, and aliases
        + its owner's name
        + its description
        + its key expression (if it is locked and if you own it)
        + its contents
        + the 'obvious' verbs defined on it

===== help examine ======[PROGRAMMER]===========================================
(continued)
[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.]

===== help @examine ======[GENERAL]==============================================

Syntax:  @examine <object>
         @exam <object>

Prints several useful pieces of information about the named object, including the following:
        + its full name, aliases, and object number
        + its owner's name and object number
        + its description
        + its key expression (if it is locked and if you own it)
        + its contents and their object numbers
        + 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') or, if it shouldn't be used as a command, give it 'args' of 'this none this' (see 'help @args').]

===== help exit-messages ======[GENERAL]==============================================
*subst*
Several kinds of messages can be set on an exit object (see 'help messages' 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' for details.

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

@leave  [%[$exit.leave_msg]]
  Printed to the player just before they successfully use the exit.

@oleave  [%[$exit.oleave_msg||"has left."]]
  Printed to others in the source room when a player successfully uses the exit.

@arrive  [%[$exit.arrive_msg]]
  Printed to the player just after they successfully use the exit.

@oarrive  [%[$exit.oarrive_msg||"has arrived."]]
  Printed to others in the destination room when a player successfully uses the exit.

@nogo  [%[$exit.nogo_msg||"You can't go that way."]]
  Printed to the player when they fail in using the exit.

@onogo  [%[$exit.onogo_msg]]
  Printed to others when a player fails in using the exit.

===== help $exit ======[CORE]=================================================

Exits
-----
An exit can be renamed by either the owner of the exit or the owner of its source.

The standard verbs that are called in exit movement are:

:move(object)  - moves the object via this exit
:invoke()      - equivalent to :move(player)

When an exit is invoked on a particular object (via exit:move(object)), the following occurs.

(1) The exit may be locked against the object, in which case we print the 
   nogo messages and quit.

(2) (room=exit.dest):bless_for_entry(object) is called.  Assuming that exit is recognized by room as being a legitimate entrance (i.e., is in room.entrances), this will enable room:accept(object) to return true.

(3) object:moveto(room) is called and the various messages (see `help exit-messages') are :announced/:told.  Note that this, in accordance with the way the builtin move() (and hence the default :moveto()) works, we get a call to room:accept(object) which checks for the room itself being locked against the object, and otherwise returns true if the blessing in the previous step worked.  The move is performed, here:exitfunc(object) and room:enterfunc(object) are called.  In particular, room:enterfunc clears the blessing bestowed in (2) now that it is no longer needed.

In general, the move may fail, in which case we :announce the (o)nogo_msgs.

===== help @exits ======[GENERAL]==============================================

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 typing its name, like 'east'.

===== help expressions ======[PROGRAMMER]===========================================

The following kinds of expressions exist in the MOO programming language:

        number
        # number
        # - number
        "character string"
        error-name
Literal expressions return the obvious values: numbers, object numbers, strings, and errors.

        { expression , expression , ... , expression }
The list-construction expression evaluates the each of the expressions in turn and returns a list whose elements are the results of those expressions.  Any of the expressions may be prefixed with an at-sign ('@'); in this case, that expression must return a list and, rather than that list becoming an element of the final list, its elements are spliced into the final list.

        name
Variable expressions return the current value of the named variable.  Variable names must start with a letter or underscore ('_') and contain only letters, digits, and underscores.  The following variables are predefined:
            OBJ, STR, LIST, ERR, NUM
            player, caller, this, verb, args
            argstr, dobj, dobjstr, prepstr, iobj, iobjstr
Their initial values are described in detail in the LambdaMOO Programmer's Manual.

        expression . name
        expression . ( expression )
        $ name
Property-reading expressions return the current value of a named property on the object that is the value of the first subexpression.  In the second form, the second subexpression must return a string, the name of the property to be read.  The third form is an abbreviation for '#0.name'.

        expression : name ( arguments )
        expression : ( expression ) ( arguments )
Verb-call expressions invoke a named verb on the object that is the value of the first subexpression, passing the given arguments.  In the second form, the second subexpression must return a string, the name of the verb to invoke.  The syntax and semantics of arguments is exactly as in the list-construction expression but no initial or final curly-braces ('{' or '}') are used.

        function ( arguments )
The function-call expression invokes one of the MOO primitive functions, as listed in 'help functions', passing the given arguments.

        expression [ expression ]
The indexing expression first evaluates the two subexpressions; call their values S and N, respectively.  S must be a string or a list and N must be a number between 1 and the length of S, inclusive.  The Nth element of S is returned.  The elements of a string are themselves one-character strings.

        expression [ expression .. expression ]
The subsequence expression first evaluates the three subexpressions; call their values S, N1, and N2, respecitively.  S must be a string or a list and N1 and N2 must be numbers.  If N1 <= N2, then both must be between 1 and the length of S, inclusive; the subsequence of S beginning at index N1 and continuing through index N2 is returned.  If N1 > N2, the empty sequence of the same type as S is returned, either "" or {}.

        name = expression
        expression . name = expression
        expression . ( expression ) = expression
        $ name = expression
Assignment expressions give new values to variables and object properties.  For the second and third forms, the expressions on the left-hand side of the '=' are evaluated first.  Then the right-hand side expression is evaluated and result is stored in the indicated variable or object property.

        expression + expression
        expression - expression
        expression * expression
        expression / expression
        expression % expression
        - expression
The arithmetic expressions evaluate the subexpressions, all of which must return numbers, and then perform addition, subtraction, multiplication, division, remaindering, or negation, respectively.  For addition, the subexpressions may both return strings as well; in this case, the result is the concatenation of the two strings.

        expression == expression
        expression != expression
        expression < expression
        expression <= expression
        expression > expression
        expression >= expression
The comparison expressions evaluate the subexpressions and then test whether or not the first result is equal to, unequal to, less than, less than or equal to, greater than, or greater than or equal to the second result, respectively.  If the indicated relation holds then they return 1 and otherwise they return 0.  Comparisons of strings are performed case-insensitively, those of lists are performed on an element-by-element basis, objects are compared by their object numbers, and errors by an ordering given in the LambdaMOO Programmer's Manual.

        expression ? expression | expression
        expression && expression
        expression || expression
        ! expression
The logical expressions each return results based upon the truth value of their first subexpression; call the value of this expression X.  The first of these returns the value of the second subexpression if X is a true value and that of the third expression if X is a false value; the unused subexpression is not evaluated.  The definitions of 'true value' and 'false value' are given in 'help truth'.  The expression 'E1 && E2' is an abbreviation for 'E1 ? E2 | E1' except that E1 is only evaluated once.  The expression 'E1 || E2' is an abbreviation for 'E1 ? E1 | E2' except that E1 is only evaluated once.  The expression '! E' is an abbreviation for 'E ? 0 | 1'.

        expression IN expression
The list-membership expression first evaluates both subexpressions; call their values E and L, respectively.  L must be a list.  If E is an element of L, then the index of the first occurence of E in L is returned.  If E is not an element of L, then 0 is returned.

The method for disambiguating the meaning of a complex MOO expression in the absence of sufficient parentheses is described in 'help precedence'.

===== help features ======[GENERAL]==============================================

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 with the @features command, and add or remove features from your list with the @add-feature and @remove-feature commands.

===== help features ======[PROGRAMMER]===========================================
(continued)
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.

===== help features ======[LAMBDA]===============================================
(continued)
On LambdaMOO, a collection of feature objects is maintained in #24300; you can "list stuff in #24300" to get a list.

===== help @features ======[GENERAL]==============================================

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.

===== help fill ======[EDITOR]===============================================

Syntax:  fill [<range>] [@ c]

combines the specified lines as in join and then splits them so that no line is more than c characters (except in cases of pathological lines with very long words).  c defaults to 70.  <range> defaults to the single line preceding the insertion point.

===== help find ======[EDITOR]===============================================

Syntax:  f*ind  /<str>[/[c][<ins>]]
         /<str>[/[c][<ins>]]

Searches for the first line after <ins> containing <str>.  <ins> defaults to  the current insertion point (see `help insert' for how to specify other places).  With the first form, any character (not just `/') may be used as a delimiter.
For the second form, you must use '/'.

The 'c' flag, if given, indicates that case is to be ignored while searching.

[Bug: With the second form, there are problems if the search string contains quotes, backslashes or a run of spaces.  The first whitespace will always be treated as a single space.  Likewise, quotes and backslashes occuring in the first word of the command (i.e., the "verb") need to be escaped with `\'.  Unfortunately it will not be possible to fix this until we get a new command parser.]

===== help @find ======[LAMBDA]===============================================

  @find #<object> - locate an object by number
  @find <player>  - locate a player
  @find :<verb>   - locate a verb on an object in your vicinity

For example, '@find frand' shows Frand's number and location. '@find :jump' lists every object in the same room as you (including you and the room itself) which has a 'jump' verb.

===== help @forked ======[PROGRAMMER]===========================================

Syntax:  @forked

Gives a list of all of the forked tasks you own, along with detailed information about each one.  The information includes the following:

Queue ID:
   A numeric identifier for the task, for use in killing it (see 'help @kill').

Start Time:
   The time after which the task will begin execution.

Owner:
   The player whose permissions under which the task is running.
   Unless you are a wizard, @forked will show only your tasks.

Verb:
   The object and verb-name of the code that forked the task.

Line:
   The line number of the first statement that the task will execute when it starts.  Note that the code for the verb in question may have changed since the task was forked; the forked task will use the version that was being executed when it was forked.

This:
   The value of `this' for the forked task, in the case that it is different from (i.e., is a descendant of) the object on which the verb code lives.

===== help @forward ======[GENERAL]==============================================

Syntax:  @forward <msg> [on *<collection>] to <recipient> [<recipient>...]

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 on to the given recipients.

===== help functions ======[PROGRAMMER]===========================================

There are many, many built-in functions available to MOO programmers.  The following list gives a brief summary of the arguments and purpose of each function; for more information, see the LambdaMOO Programmer's Manual.  

pass(arg, ...)            -- calling a verb defined on this object's parent
eval(string)              -- parsing and executing strings as MOO code
notify(player, string)    -- sending text to a player's terminal
read()                    -- reading a line of input from the player (*)
output_delimiters(player) -- return {prefix,suffix} set by PREFIX/SUFFIX cmds

typeof(value)      -- determining the data type of a value
 tostr(value, ...) -- converting any set of values into a string
 tonum(value)      -- converting any non-list value into a number
 toobj(value)      -- converting any non-list value into an object
length(value)      -- returns the length of a string or list

listappend(list, value [, index]) -- adding an element at the end of a list
listinsert(list, value [, index]) -- adding an element at the head of a list
   listset(list, value, index)    -- updating a list at some index
listdelete(list, index)           -- removing an element from a list
    setadd(list, element) -- adding an element to a set represented as a list
 setremove(list, element) -- removing an element from such a set

min(n1, n2, ...) -- minimum of n1,n2,...
max(n1, n2, ...) -- maximum of n1,n2,...
abs(n)           -- absolute value of n
sqrt(n)          -- square root of n, rounded down
random(n)        -- random integer between 1 and n inclusive
 time()          -- current time in seconds since midnight GMT, 1 Jan 70
ctime([time])    -- time (or current time) converted to a human-readable string

 index(str1, str2 [, case-matters]) -- index of first str2 in str1
rindex(str1, str2 [, case-matters]) -- index of last  str2 in str1
strcmp(str1, str2) -- case-sensitive string comparison
strsub(subject, what, with [, case-matters]) -- substitution in a string
crypt(string [, salt]) -- one-way string encryption
 match(str1, str2 [, case-matters]) -- match first pattern str2 in str1
rmatch(str1, str2 [, case-matters]) -- match last  pattern str2 in str1
substitute(template, subs) -- perform substitutions on template

   valid(object)             -- testing whether an object exists
  create(parent [, owner(*)])-- creating a new MOO object
 recycle(object)             -- destroying a MOO object
    move(object, where)      -- altering the object-containment hierarchy
chparent(object, new-parent) -- altering the object-inheritance hierarchy
  parent(object)             -- object's parent   in the inheritance hierarchy
children(object)             -- object's children in the inheritance hierarchy
max_object()       -- the highest-numbered object in the MOO
renumber(obj)      -- changes an object's number to lowest available one (*)
reset_max_object() -- resets max_object() to the largest valid object (*)

     properties(object) -- a list of the properties defined on an object
   add_property(object, prop-name, value, info) -- add a new property
delete_property(object, prop-name)              -- remove a property
    property_info(object, prop-name)       -- {owner, perms} info on a property
set_property_info(object, prop-name, info) -- setting same
is_clear_property(object, prop-name) -- find out if a property is "clear"
   clear_property(object, prop-name) -- make a property "clear"

      verbs(object) -- a list of the verbs defined on an object
   add_verb(object, info, args)  -- add a verb to an object
delete_verb(object, verb-name)   -- remove a verb from an object
    verb_info(object, verb-name) -- {owner, perms, names} info for a verb defn.
    verb_args(object, verb-name) -- {dobj, prep, iobj} argument info for a verb
    verb_code(object, verb-name [, fully-paren [, indent]]) -- program listing
set_verb_info(object, verb-name, {owner, perms, names})
set_verb_args(object, verb-name, {dobj, prep, iobj})   
set_verb_code(object, verb-name, {line, line, ...})

        is_player(object) -- testing whether or not object is a player
          players()       -- a list of all players, active or not
connected_players()       -- a list of all currently-connected players
     idle_seconds(player) -- seconds since given player typed anything
connected_seconds(player) -- seconds given player has been logged in
    boot_player(player)        -- disconnect player from the MOO immediately(*)
set_player_flag(player, value) -- set/clear player bit; boot player if clear(*)
connection_name(player)   -- a server-assigned name for player's connection
open_network_connection(@args) -- open a connection to another network site

caller_perms()         -- the player whose permissions your caller was using
set_task_perms(player) -- changing permissions of the running task (*)
callers()      -- list of {obj, verb, owner, vloc, player}: this task's stack
suspend(secs)  -- suspending the current task for a number of seconds
seconds_left() -- number of seconds left in the current task
ticks_left()   -- number of ticks   left in the current task
task_id()      -- a random number representing the currently-running task
queued_tasks() -- list of {id,start,0,20000,owner,obj,verb,line,this}
kill_task(id)  -- delete one of your tasks from the queue

server_log(string) -- add a comment to the server log file
server_version() -- a string of three numbers "major.minor.release"
memory_usage()   -- {{blocksize, nused, nfree}, ...}, the server's memory stats
shutdown(msg)    -- print msg and kill the server (*)
dump_database()  -- what it says (*)

(*) => as you might have expected, these usually require wizard permissions.

===== help @gag ======[GENERAL]==============================================

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

===== help gagging ======[GENERAL]==============================================

Occasionally, you may run into a situation in which you'd rather not hear from certain other players.  It might be that they're being annoying, or just that whatever they're doing makes a lot of noise.  Gagging a player will stop you from hearing the results of any task initiated by that player.  You can also gag a specific object, if you want to hear what the owner of that object says, but not the ourput from their noisy robot.  The commands to use gagging are listed below; detailed help is available on each of them:

@gag -- add one or more players to your gag list
@ungag -- remove a player from your gag list
@listgag -- list the players you currently have gagged

===== help @gaglist ======[GENERAL]==============================================
SEE @listgag

===== help @gender ======[GENERAL]==============================================

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.

It should be noted that some of the "genders" on the standard gender list need verb conjugation in order to work properly and much of the MOO isn't set up for this (...yet).  For example, you should expect to see `they is' a fair amount if you @gender yourself `plural'.

===== help $generic_db ======[CORE]=================================================

Generic Database
----------------
This holds a collection of {string key, datum} pairs, where datum can be anything.  At most one datum may be associated with any given string.  Data may be anything (lists, strings, numbers, objectids).  If you like, you can think of this as an array indexed by strings.
Verbs supplied include

  :find(string)          => datum, $ambiguous_match or $failed_match
  :find_key(string)      => full string key,  $ambiguous_match or $failed_match
  :find_exact(string)    => datum or $failed_match (no partial matches)
  :find_all(string)      => list of all data corresponding to matching strings
  :find_all_keys(string) => list of all matching strings

  :insert(string,datum)  
       if the string is already present in the db, 
       changes the associated datum and returns {old_datum};
       otherwise enters a new {string,datum} pair and return 0.
  :delete(string)
       if there is a datum associated with string, 
       remove this association and return {datum}; otherwise return 0.
  :delete2(string,datum)
       if the given datum is associated with string, 
       removes that association and return {datum}, 
       if some other datum is associated with string, just return {other datum}
       otherwise return 0.
  :clearall([4|3])
       removes all associations from the database.
       optional argument changes the type of the database 
       (4 is normal, 3 is a kludge for when the data are simply boolean flags
        i.e., this is a set of strings rather than a string-indexed array;
        more on this below)

  count [entries|chars] in this
        provide some vague statistics about how big this thing is.

N.B.  As entries get made, properties belonging to $generic_db.owner will be created on the db object itself.  These properties will be created having flags as specified by .node_perms, which by default is "r", but can be changed to "" should you want to ensure that randoms don't have access to the raw information.

Implementation notes
 - - - - - - - - - -
The representation is as a `trie', a tree in which each internal node corresponds to a prefix shared by two or more strings in the db.
Each internal node is kept in a property named " "+<prefix>, where <prefix> is a prefix shared by all strings in the subtree under this node.
The property value is a 4 element list

this.(" "+<prefix>)[1] = <common>
   maximal continuation shared by all strings beginning with prefix
   i.e., all these names actually begin with <prefix>+<common>

this.(" "+<prefix>)[2] = <continuations>
   string of all characters <c> that can follow <prefix>+<common> for which
   there is more than one string in the db beginning with <prefix>+<common>+<c>

this.(" "+<prefix>)[3] = <exact_matches>
   list of all strings in this subtree for which 
   the character (or lack thereof) following the <prefix>+<common> substring 
   suffices to determine the string.

this.(" "+<prefix>)[4] = <data>
   list of data corresponding to the strings in [3].

Child nodes are       this.(" "+<prefix>+<common>+<c>) 
       for all <c> in this.(" "+<prefix>)[2].
The root node is this.(" ").
If, e.g., there are 2 or more strings in the db beginning with a, 
there will be a node this.(" a").  
If all of these strings actually begin with "ani", then this.(" a")[1]=="ni".
The db consisting of the 5 correspondences

  {"animal", #1}
  {"anime",  #2}
  {"anil",   #3}
  {"anile",  #4}
  {"banal",  #5}

would be represented

this.(" ")    =={"",  "a",  {"banal"},         {#5}}
this.(" a")   =={"ni","lm", {},                {}}
this.(" anim")=={"",  "",   {"animal","anime"},{#1,#2}}
this.(" anil")=={"",  "",   {"anil","anile"},  {#3,#4}}

In some cases one may merely wish to hold a collection of strings without trying to associate a particular datum with each string.  One may then instead set up a db without the fourth field on each of the properties.  In this case the datum is taken to be the found string itself and that is what gets returned by :find*() in the event of a successful search.   :find and :find_key are then equivalent as are :find_all and :find_all_keys.  To setup the db this way, do a :clearall(3).  :clearall(4) reverts to the above described type of db with a separately kept datum.  Note that you can't change the type without emptying the db.  3 and 4 are currently the only db types allowed.

===== help $generic_editor ======[CORE]=================================================

The Generic Editor enables a player to edit a list of strings.  While one might contrive to use it directly, it is rather intended as a parent for some actual editor.  It supplies the following commands:

say         <text>                      w*hat       
emote       <text>                      abort       
lis*t       [<range>] [nonum]           q*uit,done,pause 
ins*ert     [<ins>] ["<text>]           
n*ext,p*rev [n] ["<text>]               
del*ete     [<range>]                   
f*ind       /<str>[/[c][<range>]]       
s*ubst      /<str1>/<str2>[/[g][c][<range>]]
m*ove,c*opy [<range>] to <ins>          
join*l      [<range>]                   
fill        [<range>] [@<col>]          

$editor_help.(cmdname) descrbes cmdname
$editor_help.insert    descrbes insertion points (<ins>)
$editor_help.ranges    descrbes range specifications (<range>)

You'll notice that nowhere does it say how to load in a given list of strings or how and where one may save said list away when one is done editing.  These commands are supplied by the child editor object.  The generic editor contains only the code for editing lines, though it defines additional functions for use by the children:

  :loaded(player)
     returns the index (player in this.active) iff text has been loaded
     from somewhere, otherwise returns 0.

     Note that, by default, there is a difference between 

        having nothing loaded                (:text(who)==0) and 
        having loaded something with no text (:text(who)=={}).

     If you don't care about this distinction in a particular case,
     just do (player in this.active) instead of this:loaded(player).  
     If you don't want your editor to make this distinction at all, do

        @stateprop texts={} for <youreditor>

     which changes the initial value of :text() to {} 

In all functions below, 'who' is the index returned by :loaded(player) 

BTW, be careful about using 'player' in non-user (i.e., +x this-none-this) verbs --- much better to have the user verb get the index with :loaded() and then pass that around.  

Also be careful about suspend() and verbs that call suspend().  In particular, the player's index in the .active list can change during the suspend interval, so you must be sure to obtain the index (e.g., using :loaded()) again after the suspend() returns.

For your non-user verbs, we have

  :ok(who)
     returns E_PERM if the caller is not an editor verb and E_RANGE
     if 'who' does not point to a valid session.

which should take care of the more egregious security holes (but maybe not the less egregious ones).  For getting and loading text, we have

  :text(who)    
     the current text string list or 0 if nothing loaded yet.
  :load(who,text)
     loads the given list of strings as the text to be edited.
     this also resets the 'changed' flag and pushes the insertion 
     point to the end.

and various flags and properties (all of the set_* routines return E_PERM when not called from an editor verb, E_RANGE if who is out of bounds, E_INVARG if something is wrong with the 2nd arg, or the new value, which may not necessarily be the same as the 2nd arg (e.g., set_insertion(..,37) on a 5 line text buffer returns 6).

  :changed(who)
     has the text been altered since the last save/load?
     (the child editor gets to define what "save" means).
  :set_changed(who,value)
     Any child editor command that is considered to save the text should do a 
     :set_changed(who,0).  
     Note that if the changed flag is 0, the session will be flushed when 
     the player leaves the editor, so you may also want certain commands to
     do set_changed(who,1)...

  :origin(who)
     room where the player came from.  
  :set_origin(who,room)
     can be used to change the room the player will return to when finished
     editing.  Since origin gets set even in cases where the player teleports
     into the editor you probably won't usually need to do this.

  :insertion(who)
     current insertion point.
  :set_insertion(who,linenumber)
     linenumber needs to be a positive integer and will get 

  :readable(who)
     whether the current editing session has been made globally readable.
  :set_readable(who,boolean)
     change the readability of the current editing session.
     This is used by the publish/perish verbs.

We also provide

  :invoke(...)
      If the player has a previous unsaved (i.e., :changed()!=0)
      session, we return to it, moving the player to the editor.  
      If the player is already in the editor, this has no effect other
      than to print a few nasty messages.  In any case a :changed()
      session must be aborted or set_changed(,0) before anything else 
      can be started

      Otherwise, we pass the arguments (which are assumed to be the
      result of some munging of the command line) to :parse_invoke(),
      move the player to the editor and load whatever parse_invoke()
      specified.  The only interpretation the generic editor makes on
      the arguments is that if the boolean value of the first is true,
      this indicates that the player wanted to load something as
      opposed to resume a previous session.  Usually a command calling
      :invoke will have a true (i.e., nonzero number, nonempty list or
      string) first arg iff the command line is nonempty, in which case 
      'args' works fine for this purpose.

      If the command parses sucessfully (:parse_invoke() returns a list),
      we move the player to the editor if necessary and then call 
      :init_session() to set things up.

The child editor is assumed to provide

  :parse_invoke(...)
     given :invoke()'s arguments, determines what the player wants to edit.
     It either returns 0 and reports syntax errors to player,
     or it returns some list that :init_session() will understand.

  :init_session(who,@spec)
     where spec is something that was returned by :parse_invoke().
     Loads the text and sets the stateprops (below) to indicate that 
     we are working on whatever it is we're suppose to be working on.

  :working_on(who)   
     returns a string X as in "You are working on X."
     This is called by the 'w*hat' command, among other things.

Child editors may have their own properties giving state information for the various editing sessions.  The value of each such property will be a list giving a value for each player in the editor.  For each such property, you should, once the editor object has been created, initialize the property to {} and do one of

    @stateprop <propname>                 for <editor>
    @stateprop <propname>=<default-value> for <editor>
               (0 is the default <default-value>)

Henceforth, adding and deleting new editing sessions will amend the list held by the given property.  The value of the property for a given session can be obtained via this.<propname>[player in this.active] and can be changed with a corresponding listset() call.  The usual idiom for an editor command is

   if(!(who=this:loaded(player)))
     player:tell(nothing_loaded_msg());
   else
      ... various references to  this.<propname>[who] ...
   endif

To remove such a property from the list of such state properties:

    @rmstateprop <propname> from <editor>

Note that you can only do this with properties defined on the child editor itself.  

Sometimes you may wish to @stateprop a new property on an editor where active editing sessions exist.  @stateprop will fail if the property in question does not hold a list of the correct length (== length(editor.active); one value for each editing session).  You need to either give the @flush command to clear out all sessions and boot all players currently in the editor or somehow manually initialize the property to a list of appropriate values and pray that nobody enters/exits the editor between the property initialization and the @stateprop command --- this problem can be avoided by doing an eval() that does all of the initializations (beware of suspends()) and calls :set_stateprops directly.

Incidentally, the @flush command may be used at any time to clean out the editor or to remove all sessions older than a given date.

There are also numerous _msg properties that may be customized

    @depart          announced at the origin when :invoke() is called. 
    @return          announced at the origin the player is returned there.
    @nothing_loaded  printed when user attempts editing 
                     before anything has been loaded.
    @no_text         response to 'list' when :text()=={}
    @no_change       printed by 'what' when :changed()==0
    @change          printed by 'what' when :changed()==1
    @no_littering    printed upon leaving the editor with :changed()==1.
    @previous_session  printed by :invoke() when player tries to start a 
                     new session without aborting or saving the old one

The general procedure for creating a child editor:

. @create $generic_editor named <editor>

. define additional <editor> verbs/properties
    At the very least you need 'edit' and 'save' commands.
    Usually you can get away with just having 'edit' call :invoke();
    Presumably, you'll need at least a command to load text from somewhere
    as well as a command to save it back out.

. define a verb (somewhere) to invoke the editor 
    This could be just a one-liner that calls <editor>:invoke(args,verb).
    Either that or
      .  you have to set up an exit somewhere whose destination is <editor>
      .  you have to advertise the object number so that people can 
         teleport to it.
  
. @stateprop x for <editor>

. if you want the 'abort' command to boot the player from the editor do
    <editor>.exit_on_abort = 1;

. set <editor>.commands to be the list of additional commands defined
    by <editor>.  
    Each element of the list is itself a list of the form {name,args}.
  set <editor>.commands2 to be the list of commands that should appear
    in the `look' listing, and should be a list of strings appearing 
    as names in .commands on either <editor> or some editor ancestor.
  look at $verb_editor or $note_editor for an example.

. If you want to have help text for new verbs you define, create a child of 
    $generic_help and add properties to this object for each of the topics 
    that you want to provide help text.
    Finally, set <editor>.help = {this object} so that the help system
    knows to consult this object.

===== help $generic_help ======[CORE]=================================================

The Help System
---------------
When a player types help, the following list of objects is consulted for .help properties:  the player itself, all ancestors of player up to and including $player, and, if the current location is a room, the current location together with all ancestors of the current location back to and including $room.  Each help property should have as value either an object or a list of objects (otherwise we just ignore it).  These objects are then strung together as a list of `help databases' to be searched in order for the requested topic.

A help database (in the sense of anything that is usable by $player:help()) is any object having the following three verbs:

  :find_topics([string])
     where string is a supposed help topic, returns a list of strings,
     i.e., actual help topics that this db knows about, or some boolean 
     false value in the event that this db is clueless...
     If no arguments are given, this should return a list of all topics
     in the db

  :get_topic(string)
     given one of the strings returned by :find_topics this either
     returns a list of strings (text to be spewed to the player) or
     returns 1 to indicate that it has already taken care of printing
     information to the player.

  :dump_topic(string)
     like get_topic, but instead returns the raw text of a help topic
     as a (download/upload) script

In short if :find_topic reports that a particular db knows about a given topic
it returns the full topic name, so that :get_topic may be called on it later.
:dump_topic is used by maintainers (see $wiz:@gethelp) to edit help topics.

$generic_help and $help
-----------------------
The Generic Help Database, $generic_help, is the parent class of a particular kind of help database of which $help is an instance.  On help databases of this type, every help topic has a corresponding property, interpreted as follows:

  this.(topic) = string             
      one-line help text.

  this.(topic) = {"*<verb>*",@args}
      call this:<verb>(args,dblist) to get text where dblist is the list of 
      help objects that would have been consulted had the topic not been found 
      on this object.

  this.(topic) = other list of strings 
      multi-line help text

For the {"*<verb>*",...} form, the current verbs available are

  {"*forward*", topic, @rest}   
     - get help text for topic and then append the lines of `rest'.  
       rest may, in turn, begin with a "*<verb>*"...

  {"*pass*", topic, @rest}   
     - get help text for topic from the first help database after this one
       that actually has help text for topic, and then append lines of `rest'.
       As with "*forward*" rest may, in turn, begin with a "*<verb>*"...

  {"*subst*", @lines} 
     - All occurences of %[exp] in lines are replaced with the value of exp
         which is assumed to evaluate to a string.  
       All lines beginning with %;exp are replaced with the value of exp 
         which is assumed to evaluate to a list of strings.
       Evaluation is done using $no_one's permissions so exp in either case
       can only refer to public information.

  {"*index*", title}
     - returns a list of all topics in this database, arranged in columns.
       title is used as a heading for this index.

Individual help dbs are free to define additional verbs that may be used in this context.  $help itself defines the following additional such verbs:

  {"*index_list*"}
     - returns a list of all index topics in all databases in the search list.
       An index topic is one whose actual text is {"*index*", something}.
       When creating a help db, you should be sure to make an index topic.

  {"*full_index*"}
     - prints indices for all help databases in the search list.

It should be noted (once again) that help databases need not be children of $generic_help, so long as they have :find_topics/:get_topic/:dump_topic working as specified above.

===== help $generic_options ======[CORE]=================================================

Generic Option Package
----------------------
It occasionally happens that one has a command or set of commands for which one wishes to provide several options/flags that a player can set to customize the command's behavior for him/herself.  Making each option a separate property is a bit expensive, especially when the option in question is merely a boolean flag that gets set to false in most cases.  This package provides an alternative, as well as providing a uniform set of commands for setting these flags/options and checking that the values given are of appropriate types.

Instead of needing several properties, only one is required to store a list containing values for all of the options.  An "option package" (pkg, below) is then an object of this class, which provides routines for manipulating such lists.

The set of option names is divided into a set of "real" options, those whose names will actually appear in a given list, and "extras" which are either synonyms for or represent combinations of real options.

 pkg:add_name(name)      adds name to .names  (remove it from .extras if there)
 pkg:add_name(name,1)    adds name to .extras (remove it from .names if there)
    => 1 - ok, 0 - already added, E_INVARG - illegal name, E_PERM

 pkg:remove_name(name)   remove name from either .names or .extras
    => 1 - ok, 0 - not present, E_PERM

For setting or retrieving values we have

 pkg:get(options,name) 
    => value (or 0 if name isn't a real option)
 pkg:set(options,name,value)
    => revised options (or string error message if something goes wrong)

By default, a given option can only be a boolean flag, having one of the values 0 (absent from the list), or 1 (present in the list).  :set translates 0/""/{} to 0 and any other non-object value to 1.

One may however designate a wider range of possible values for an option "foo" by either installing one of

  pkg.type_foo
    -- list of allowed types, 
       e.g., {NUM,STR}   => must be a number or a string
       e.g., {OBJ,{OBJ}} => must be an object or a list of objects
    for anything fancier use:

  pkg:check_foo(value)
    => string error message or {value munged as desired}

In general, the only restriction on option values is that 0 is the only false value; setting an option to "" or {} sets it to 0.  Every option defaults to 0, and no matter what you install as .type_foo or :check_foo(), 0 will always be a legal value for option "foo".

When presented with an option that is in .extras, :set will typecheck the value as described, however, then :actual(name, value) will be called to obtain a list of {name-of-real-option, value} pairs indicating which combination of real options should be set.

Other verbs
  pkg:parse(args,...)
    parses the command line arguments of a @whatever_option command
    => {optionname, value}  if the player wants to set an option
    => {optionname}         if the player wants to view an option
    => string error message  otherwise

  one may install pkg:parse_foo to parse arguments for option "foo" 
    !foo     => {"foo",0}  (:parse_foo not called)
    foo=     => {"foo",0}  (:parse_foo not called)
    -foo     => {"foo",0}  (:parse_foo not called)
    +foo     => pkg:parse_foo("foo",1)
    foo=word => pkg:parse_foo("foo","word")
    foo word1 word2    => pkg:parse_foo("foo",{"word1","word2"})
    foo is word1 word2 => pkg:parse_foo("foo",{"word1","word2"})

 pkg:show(options,name|list of names)
    => list of strings describing the current value of the named option(s).
       calls     pkg:show_foo(options,list of names) or
       refers to pkg.show_foo
       to describe option "foo"

(see sources for details...  at some point I'll finish writing this... --Rog)

===== help get ======[GENERAL]==============================================
SEE take

===== help give ======[GENERAL]==============================================

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 @gms ======[LAMBDA]===============================================

Usage: @gms
       @gms all

This command gives information about the game-masters of the Bovine Illuminati.  Specifically, it gives exactly the same sort of information that the @who command provides.  "@gms" tells you about those game-masters who are currently logged in; "@gms all" tells you about all game-masters.

===== help go ======[GENERAL]==============================================

Syntax: go <direction> ...

Invokes the named exits in the named order, moving through many rooms in a single command.

Example:
Munchkin types:
  go n e e u e e s e
and moves quite rapidly from the Living Room all the way to the Bovine Illuminati Atrium, all in one command.

===== help @go ======[LAMBDA]===============================================
SEE @move

===== help @grant ======[WIZARD]===============================================

Syntax:  @grant <object> to <player>

Ownership of the object changes as in @chown, i.e., .owner and all c properties change hands while the previous owner's and the new owner's quotas are adjusted.  In addition all verbs and !c properties owned by the previous owner change ownership as well.  Finally, for !c properties, instances on descendant objects change ownership as when @chowning the properties individually.

===== help graylist ======[WIZARD]===============================================
SEE blacklist

===== help @graylist ======[WIZARD]===============================================
SEE @blacklist

===== help @grep ======[PROGRAMMER]===========================================

Syntax:  @grep <string> in <object>
         @grep <string> in {<objectlist>}

         @egrep <regexp> in <object>
         @egrep <regexp> in {<objectlist>}

These are named for the corresponding unix utilities.
@grep searches the given object(s) for verbs whose verbcode contains the given string as a substring of one of its lines.  
@egrep searches the given object(s) for verbs whose verbcode contains a substring matching the given regular expression (see `help regular-expressions').

===== help @grep ======[WIZARD]===============================================
(continued)
For wizards, the following forms are also available for doing full-db searches

         @grep <pattern>
         @grep <pattern>
         @egrep <pattern> from [#]<n>
         @egrep <pattern> from [#]<n>

the first two search all objects in the database while the last two search the range [#<n>..max_object()]

See also:  @grepcore, @who-calls.

===== help @grepcore ======[WIZARD]===============================================

Syntax:  @grepcore <pattern>
         @who-calls <verbname>

@grepcore pattern is @grep pattern in {all core objects}.  Core objects are computed for you by #0:core_objects().

@who-calls greps for the verbname + "(", hoping to catch it as a verb call.  Currently @who-calls does not allow you to restrict the search as @grep does.  (Volunteers?)

===== help @gripe ======[GENERAL]==============================================

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

===== help @guests ======[WIZARD]===============================================

Syntax:  @guests [<n>]

Prints out the log of guest player connections, indicating connect/disconnect times and where they came from.  If a numeric argument n is given, then only the last n entries in the log are consulted (useful for when the full log is rather long) --- note that connections and disconnections are separate entries so the actual printed listing will be about half this length.

Alternate:  @guests now

Prints out in @who format all connected guests.  In place of the location field is the current connect site.

===== help hand ======[GENERAL]==============================================
SEE give

===== help help ======[GENERAL]==============================================

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

===== help help ======[PROGRAMMER]===========================================
(continued)
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'.

===== help $help ======[CORE]=================================================
SEE $generic_help

===== help home ======[GENERAL]==============================================
*subst*
Syntax: home

Instantly teleports you to your designated home room.
Initially, this room is %[tostr($player_start.name," (",$player_start,")")].
You can change your designated home; see 'help @sethome' for details.

===== help $housekeeper ======[CORE]=================================================

The housekeeper is an object that can help keep other objects where they belong.  New MOOs may want to add their own user interface for the housekeeper; here is some information that may be helpful.

To indicate what objects should be cleaned:

  :add_cleanup(object[, requestor[, where]])
    Ask the housekeeper to clean 'object' for 'requestor' to 'where'.
    Requestor defaults to 'player'.
    Where defaults to object.location.

  :remove_cleanup(what[, requestor])
    Remove 'what' from the cleanup list at 'requestor's request.
    Will remove it only if 'requestor' made the original request and owns
    the object or the destination.

To actually get the housekeeper to clean stuff up:

  :cleanup([insist])
    Clean up player's objects.  Argument is 'up' or 'up!' for manually
    requested cleanups.  'up!' means to clean things even if it's against
    the housekeeper's better judgement.

  :replace(object[, insist])
    Clean up the indicated object.  'insist' is as in :cleanup.

  :continuous()
    Starts the housekeeper cleaning continuously, killing any previous
    continuous task.  This should be called only when starting up a new MOO,
    or if something has gone wrong, as normally it will just keep going
    without any help.

  :litterbug()
    Clean up all the places in housekeeper.public_places by getting rid of
    all contents not in their .residents lists.  This is called by
    :continuous, so it doesn't need to be called directly.

To find out what's being cleaned to where for whom:

  :cleanup_list([whom])
    Show 'player' the personal cleanup list for 'whom', or the housekeeper's
    complete list if no argument is given.

  :clean_status()
    Show 'player' a brief summary of eir personal cleanup list.

===== help @idea ======[GENERAL]==============================================
SEE @typo

===== help information ======[GENERAL]==============================================
SEE help

===== help insert ======[GENERAL]==============================================
SEE put

===== help insert ======[EDITOR]===============================================

Syntax:  ins*ert [<ins>] ["<text>]
         .                    (`.' == `insert' without arguments)

(EDITOR)
Many editor commands refer to an "insertion point" which is (usually) the place right below where the most recent line was inserted.  The insertion point should really be thought of as sitting *between* lines.  In listings, the line above the insertion point is marked with `_' while the one below is marked with `^'.

The `insert' command, when given an argument, sets the insertion point.
If <text> is provided, a new line will be created and inserted as with `say'.
<ins>, both here and in other commands that require specifying an insertion point (e.g., copy/move), can be one of
          
    ^n   above line n
     n   above line n
    _n   below line n
     $   at the end
    ^$   before the last line
   n^$   n lines before the end
     .   the current insertion point  (i.e., `insert .' is a no-op)
    +n   n lines below the current insertion point.
    -n   n lines above the current insertion point.

For the truly perverse, there are other combinations that also work due to artifacts of the parsing process, but these might go away...

===== help introduction ======[GENERAL]==============================================

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

LambdaMOO is more of a pastime than a game in the usual sense; there is no `score' kept, there are no specific goals to attain in general, and there's no competition involved.  LambdaMOO participants explore the virtual world, talk to the other participants, try out the weird gadgets that others have built, and create new places and things for others to encounter and enjoy.

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 -- getting a description of the current room or any other object
say -- speaking to the other players in the same room as you
@who -- showing which players are currently connected to the MOO
movement -- how to move around in the MOO, from room to room
@quit -- disconnecting from the MOO

===== help inventory ======[GENERAL]==============================================

Syntax:  inventory
         i

Prints a list showing every object you're carrying.

===== help join ======[EDITOR]===============================================

Syntax:  join        [<range>]
         joinliteral [<range>]

combines the lines in the specified range.  Normally, spaces are inserted and double space appears after periods and colons, but 'joinliteral' (abbreviates to 'joinl') supresses this and joins the lines as is.  <range> defaults to the two lines surrounding the insertion point.

===== help @join ======[LAMBDA]===============================================
SEE @move

===== help key-representation ======[GENERAL]==============================================

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

===== help keys ======[GENERAL]==============================================

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

===== help @kids ======[PROGRAMMER]===========================================

Syntax:  @kids object

A quick way to find out the children of an object.  Prints out the names and object numbers of the found children.  Note: this is not a list of all descendents, just direct children.

Example:
  @kids #3107
  Generic Body of Chlorinated Water(#3107) has 3 kids.
  The Pool(#1428)   The Hot Tub(#388)   Deep Blue Underground Pool(#17340)

===== help @kill ======[PROGRAMMER]===========================================

Syntax:  @kill task_id
         @kill [object]:[verb]
         @kill soon [number-of-seconds]
         @kill all
         @kill %trailing_id


Immediately kills one or more forked tasks.  The '@forked' command is useful for finding out what tasks you have pending; see 'help @forked' for details.  Only the owner of a task may kill it.

@kill task_id kills only the task with that id.

@kill object:verb kills all tasks which were scheduled by the object running the verb named.  Both object and verb are optional:  @kill object: kills all tasks scheduled by that object, and @kill :verb kills all tasks which were scheduled by any object running that verb.  This can be useful if you have several similar objects which are running tasks from similarly named verbs.  (Perversely, @kill : kills all tasks...  Any object running any task.)

@kill soon kills all tasks scheduled within the next minute.  @kill soon number kills all tasks scheduled within that number of seconds, e.g. @kill soon 300 would kill all tasks scheduled within the next five minutes.  This can be useful if you have a runaway task you want to quickly remove, but don't want to kill you later tasks.

@kill all kills all tasks.  Like @kill soon, but more dramatic.

@kill %trailing_id expects you to specify the last few digits of a task id.  It then kills all tasks that end with those digits.

Example:
  @forked
  1359083655  Sep 16 21:45:00 1991  yduJ          #5803:heartbeat (10) [#68]
  @kill %655
  Killed:   task 1359083655, verb #5803:heartbeat, line 10, this==#68

===== help LambdaMOO ======[LAMBDA]===============================================

LambdaMOO takes place inside and on the grounds of a large, sprawling mansion.  The house has existed in one form or another for literally hundreds of years, passing through the hands of a bewildering seqeuence of owners.  Most of the owners have taken the opportunity to add to the mansion, extending it in dozens of different directions, each with a completely different vision and architectural style.  In short, this house is a bit of a mongrel.

The house is also very large, so large in fact that the current occupants themselves have only ever explored a tiny portion of it.  What may be going on in other parts of the house is anybody's guess.  I wouldn't be the least bit surprised to hear about space aliens, ancient secret societies, or even high-tech cottage industries that are making use of parts of the house.  With nobody having the means or inclination to patrol the whole place, almost anything could be squatting here.

South of the occupied part of the house lie the palatial gardens.  Many parts of the gardens are still being tended and cared for, some even by gardeners hired by the current occupants.  Of course, there are other parts of the gardens that have become quite overgrown and wild, sheltering who knows what.

The land underneath the house is also full of strange tunnels, odd caverns, perhaps a forgotten mine, and other amusements.  Of course, except for the wine cellars, the current occupants are completely unaware of such developments.

To add to the LambdaMOO universe, please look for themes that fit well into this framework.  You can build your additions in limbo, disconnected from the rest, until you've got it up to a certain level of coherence.  Look for an existing place that would make a good neighbor for your addition, and then find the owner of that place to hook you in.

Please note that we intend that the topology of the LambdaMOO universe be consistent: rooms should not overlap each other, going east through a door should be reversable by going west, etc.  Please keep this in mind while building new areas.

Have fun!

===== help language ======[PROGRAMMER]===========================================

The MOO programming language is described in excruciating detail in the LambdaMOO Programmer's Manual, available for FTP from parcftp.xerox.com in the file pub/MOO/ProgrammersManual.txt.  The online help consists of a few quick reference guides here in the help system under the following topics:

statements -- the syntax and semantics of the various kinds of MOO statements
expressions -- the same for the various kinds of MOO expressions
functions -- a list of the primitive functions available to MOO programs

===== help @lastlog ======[GENERAL]==============================================

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.

===== help letters ======[GENERAL]==============================================

A letter is a special kind of note (see 'help notes') 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' and 'help write'), encrypt it so that only you and the other player can read it (see 'help encrypt') 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' for details.

===== help @linelength ======[GENERAL]==============================================

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

===== help list ======[EDITOR]===============================================

Syntax:  lis*t [<range>] [nonum]

Prints some subset of the current verb text.
The default range is some reasonable collection of lines around the current insertion point:  currently this is 8_-8^, ie., 8 lines above the insertion point to 8 lines below it unless this runs up against the beginning or end of file, in which case we just take the first or last 16 lines, or just 1-$ if there aren't that many.  (See `help ranges' for how to specify line numbers and ranges.)

`nonum' prints without line numbers.

Yes, window heights will be customizable some day.

===== help @list ======[PROGRAMMER]===========================================

Syntax:  @list <object>:<verb>
         @list <object>:<verb> [with|without parentheses|numbers]
         @list <object>:<verb> <dobj> <prep> <iobj>

Prints out the code for the MOO program associated with the named verb on the named object.  

Normally, the code is shown with each line numbered and with only those parentheses that are necessary to show the meaning of the program.  You can e.g., specify `without numbers' to have the numbers omitted or `with parentheses' to include all parentheses or even `with parentheses without numbers' to do both.

The 3rd form of the verb lists the verb matching the given dobj/prep/iobj specification if such exists.  

Example:
  Type `@list $room:@move' to see the code for the `@move' command, or even `@list $prog:@list' to see the code implementing @list itself...

The 2nd and 3rd forms can be combined, e.g.,

  @list frobule:burfle this in front of any without numbers

which would be useful if `frobule' had more than one `burfle' verb and we wanted to see the one having `this' `in front of' `any' as its respective dobj/prep/iobj specifiers.

===== help @listgag ======[GENERAL]==============================================

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' for an explanation of gagging in general.

===== help @locations ======[GENERAL]==============================================

Syntax:  @locations object

Prints out the names and object numbers of all containing objects.

Example:
  @locations ur-Rog
  ur-Rog(#6349)   ur-Rog's Display Case(#6355)   Editorial Boardroom(#5747)

===== help @lock ======[GENERAL]==============================================

Syntax:  @lock <object> with <key expression>

Set a lock on <object> to restrict its use.  See 'help locking' for general information about locking and 'help keys' 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.

===== help @lock_for_open ======[GENERAL]==============================================

Syntax:
  @lock_for_open <container> with <key expression>

Set the lock on <container> which restricts who can open it.  See 'help locking' for general information about locking and 'help keys' for the syntax and semantics of key expressions.

See 'help containers' for information on containers.

===== help locking ======[GENERAL]==============================================

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:
  + Rooms and containers refuse to allow any object inside them if they're locked for it.
  + Exits refuse to transport any object that they're locked for.
  + Things (including notes and letters) cannot be moved to locations that they're locked for.

There are two sides to locking:
  + How is it specified whether one object is locked for another one?
  + 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 -- setting a lock on an object
@unlock -- clearing the lock on an object
keys -- describes the language used to describe lock keys

===== help @log ======[WIZARD]===============================================

Syntax:  @log <message>
         @log

The first form enters <message> as a one-line comment in the server log.
The second form prompts for a sequence of lines to be collectively entered as an extended comment.  This uses $command_utils:read_lines so all of those conventions apply, i.e., a period on a line by itself ends the text, `@abort' aborts the command, etc...).  Example:  If Wizard (#2) types

    @log I did $dump_interval=3600

the following line appears in the server log

    Aug 19 22:36:52:  COMMENT:  from Wizard (#2):  I did $dump_interval=3600

===== help $login ======[CORE]=================================================

$login
------
This object manages command parsing for unconnected players and governs the initiation of an actual connection.  There are verbs pertaining to registration, controlling player creation, and doing site-locks (see `help blacklist' on $wiz_help).

COMMANDS FOR UNCONNECTED PLAYERS

Recall that for each line that an unconnected player types, the server parses that line into words (the same way normal commands are parsed into a list of words that is then assigned to `args') and then #0:do_login_command is called.

  :parse_command (@args) => {verb, @args}
    given the sequence of arguments that were fed to #0:do_login_command
    this returns the name of a verb on $login to be called together with a 
    list of arguments to be passed to it.

By default this just returns args iff args[1] names an actual verb on $login that is +x and has args {"any","none","any"}.  Otherwise, it returns one of

  .blank_command   -- verb to call if command line is empty
  .bogus_command   -- verb to call if command line otherwise unintelligible

In both cases :parse_command returns a verbname followed by the entire args list passed to it (including the would-be verb at the beginning if any).

Currently the following verbs are availabe to non-connected players

  h*elp @h*elp       -- print .welcome_message
  ?                  -- print a short list of available commands
  w*ho @w*ho         -- print a list of logged in players (excluding wizards)
  co*nnect @co*nnect -- connect to an existing player
  cr*eate @cr*eate   -- create a new player
  up*time @up*time   -- tell how long the server has been running
  version @version   -- tell which version of the server is running
  q*uit @q*uit       -- logoff

Adding a new command is fairly straightforward; just create a verb on $login, making sure a previous verb doesn't already match the name you want to give it.  Then give it args of "any" "none "any" and make sure it is +x.  Such a verb should begin with `if (caller != #0) return E_PERM; ...' so as to prevent anyone other from a not-logged-in player from making use of it.

CUSTOMIZATIONS

  .welcome_message 
    -- the message for "help" to print.
  .create_enabled 
    == 0 => @create prints .registration_string if one tries to use it
    == 1 => anyone from a non-blacklisted site (see `help blacklist')
            may use @create to make a new player

  .registration_address
    -- an email address for character creation requests
  .registration_string  
    -- string to print to players to give them information about how to get 
       a character created for them, .registration_address is substituted 
       for %e, % for %%
  .newt_registration_string
    -- string to print to @newted players (see `help @newt').
       same substitutions as for .registration_string.

Other verbs
   :registration_string()      => .registration_string with substitutions
   :newt_registration_string() => .newt_registration_string with substitutions
   :player_creation_enabled(connection) 
       decides whether someone on connection should be allowed to create 
       a player.  If you decide this shouldn't depend strictly on the blacklist
       and on the value of .create_enabled, here's where the extra code can go.
   :check_for_shutdown()
       prints a warning message to append to the login banner in the event 
       that the server will be going down soon.
   :check_player_db()
       prints a warning message to append to the login banner in the event 
       that $player_db is being reloaded to warn players that their character
       names might not be recognized.

SITE LOCKS
see `help blacklist'

===== help look ======[GENERAL]==============================================

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

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

===== help mail ======[GENERAL]==============================================

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     -- seeing a table of contents for a collection of email messages
@read     -- reading individual messages 
@next     -- reading the 'next'     message
@prev     -- reading the 'previous' message

@send     -- composing and sending a message to other players
@answer   -- replying to one of the messages in a collection
@forward  -- resending one of the messages in a collection somewhere else

@rmmail   -- discarding some subset of a collection
@unrmmail -- undoing the most recent @rmm on a collection
@renumber -- renumbering the messages in a collection

@mail-option -- describes and sets various customization flags

help mail-forwarding
 -- describes mail forwarding
help message-sequences
 -- describes message-sequences arguments to @mail, @read, @rmm, and @answer.

For viewing collections other from your own, the following commands are useful:

@rn          -- list those collections that have new messages on them
@subscribe   -- indicate that you want @rn to report on a given collection
                  and add yourself to its .mail_notify list
@skip        -- ignore any remaining new messages in a given collection
@unsubscribe -- ignore a given collection entirely from now on
                  and remove yourself from its .mail_notify list
@unsubscribed-- show the mailing lists that you aren't subscribed to.
@subscribed  -- like @rn, but shows all lists that you are subscribed to
                even if they have no new activity

===== help mail ======[PROGRAMMER]===========================================
(continued)
See `help mail-system' for a description of the programming interface to the mail system.
In particular, see `help $mail_recipient' for information on creating new mail collections.

===== help @mail ======[GENERAL]==============================================

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

<recipient> must name some child of $mail_recipient (e.g., a mailing list);
<message-sequence> can be a sequence of message numbers; you can also scan the recipient for articles that fit a given description, as specified in `help message-sequences'.

Note that if you view mail on some other recipient and have "sticky" in your .mail_options (see `help mail-options'), 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.

===== help $mail_agent ======[CORE]=================================================

$mail_agent

This object contains a two distinct sets of routines:

  1.  utilities for performing basic mailsystem functions, e.g.,
      matching on recipient names, resolving mail forwarding, 
      formatting messages, sending messages

Recipient Matching

match           - match on a $mail_recipient
match_recipient - match on either a $mail_recipient or a player
match_failed    - print angry messages to the user for $failed/ambiguous_match

look_self  - provides a list of available $mail_recipients
check_names
touch
accept

Message Format

make_message        - produces a message in the canonical transmission format
name                - single recipient     => string for address field
name_list           - list of recipients   => string for address field
parse_address_field - address field string => object list

Sending Messages

send_message  - advertised message sending routine.
raw_send      - raw message sending routine 
                (only called by $mail_editor:send and this:send_message)
resolve_addr  - converts a given list recipients into a list of actual 
                recipients and objects to be notified.
sends_to      - Does X forward (transitively) to Y

Mail Options

option         
option_verbose

  2.  canonical versions of mail_recipient verbs

Ideally, the verbs to perform operations on a given mail recipient would be located on the recipient itself, except for the fact that these verbs also need to be located on players, which for various reasons, shouldn't be children of $mail_recipient.  Multiple inheritance would solve our problems, but we don't have it yet.  Ergo, both $mail_recipient and $player refer to the following verbs here:

display_seq_full     print entire text of messages  (@read)
display_seq_headers  print headers of messages      (@mail)
rm_message_seq       remove messages                (@rmm)
undo_rmm             undo last rm_message_seq       (@unrmm)
expunge_rmm          flush removed messages         (@unrmm expunge)
list_rmm             list removed messages          (@unrmm list)
renumber             renumber messages              (@renumber)
msg_summary_line     msg header => display_seq_headers/list_rmm summary line

parse_message_seq    command line msg sequence spec => message sequence
new_message_num      => message number of next new message
length_all_msgs      => number of messages (total)
length_num_le        => number of messages numbered <= some number
length_date_le       => number of messages dated <= some date
exists_num_eq        => true iff there exists a messsage with the given number
from_msg_seq         => message sequence of msgs from given sender(s)
to_msg_seq           => message sequence of msgs to given recipient(s)
subject_msg_seq      => message sequence of msgs with subjects containing text
body_msg_seq         => message sequence of msgs with bodies containing text
messages_in_seq      => list of {message number, message} pairs

messages             == :messages_in_seq(1,:length_all_msgs()+1)   (obsolete)

The $mail_agent versions of these verbs are set_task_perms(caller_perms()) and perform their operations on caller, which in turn is assumed to have done any necessary security checks.

===== help mail-format ======[CORE]=================================================

Mail Transmission Format
------------------------
There is a standard message format used for transmitting messages.  This is the format that $mail_editor:make_message produces, and that :receive_message verbs on players and $mail_recipients expect to see.  The (currently experimental) @refile and @copym commands also use this format to transfer messages.

This *transmission* format is distinct from the *storage* format, though, for convenience this same format is often used as well for storing messages in player collections and ordinary $mail_recipient children though, in general, there is no requirement that this be the case.

A transmitted message is a list in the following form

   date (number),
     the time() value at the time the message was sent.
   from (string),
     the sending object (address list form)
     if this is not a player, an additional header will indicate the 
     current ownership of the object.
   to  (string),
     recipients (address list form) which can either be players 
     or $mail_recipient descendents.
   subject (string),
     subject of the message, or " " if there is no subject,
  @additional optional headers (list of strings),
     each header has the form "<header-name>: text" where <header-name>: 
     is padded out to a width of 10 columns for the convenience of 
     :display_message.  Currently "Reply-to: <address list>" is the only 
     additional header in use,
   "",
  @body of message (list of strings)

Note that the from, to and subject lines do *not* include a header name like "From:", "To:", or "Subject:".  The @'s indicate that the lists in question get spliced in (as usual), thus the entire message is a list whose first element is a number and the rest are strings.

The address lists that appear in the from and to lines is a string in the form a sequence of object ids, each enclosed in parentheses and preceded by optional text, e.g.,

  "*Core-DB-Issues (#8175), Rog (#4292), and Haakon (#2)"

The text is intended to give the current name of each object for the benefit of human readers, but is actually ignored by all header parsing routines.  The convention is that the text is either a player name or a * followed by a mailing list name.

===== help mail-forwarding ======[GENERAL]==============================================

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

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

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

===== help @mail-options ======[GENERAL]==============================================

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      @reply's start out with a blank message body
 +include      @reply's start with original message included
 -all          @reply's go to sender only
 +all          @reply's 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

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.

===== help $mail_recipient ======[CORE]=================================================

Generic Mail Recipient
----------------------
A "mail recipient" is, by definition, an object that can be sent mail.
Mail recipients must either be players or descendants of $mail_recipient.

One source of confusion is that the terms "mail recipient", "mail folder", "mailing list", and "mail collection" really all refer to the same kind of object.  It so happens that $mail_recipient serve several distinct functions and we tend to use whatever term happens to best match the application under discussion, e.g., it's a "mailing list" if we're playing with its .mail_forward property but it's also a "mail folder" if we're examining the messages that have been saved in it.

Note that, by default, a freshly created recipient is accessibly only by you.  If you wish to make a publically accessible recipient, set .readers=1.  Furthermore, if you want to allow a message on your recipient to be removed by its sender without your intervention, set .rmm_own_msgs=1.  Finally, in order for other players to be able to refer to your recipient by name, the object must reside in $mail_agent.  $mail_agent will not accept the object unless it has an actual description and a name distinct from all other mail recipient names/aliases.

Topics:

  MR-access       -- controlling read, write and send access to a recipient
  MR-naming       -- naming conventions and how to match on recipient names
  MR-sequences    -- message sequence arguments to $mail_recipient verbs
  MR-reading      -- reading messages/headers on recipients
  MR-searching    -- searching message lists for patterns in certain fields
  MR-writing      -- removing and renumbering messages
  MR-subscribing  -- updating .mail_forward, .mail_notify 
                       and the story of .current_message

===== help mail-resolve ======[CORE]=================================================

Resolving Mail Forwarding & Notification
----------------------------------------
For each recipient of a given mail message, the following two verbs are called to determine where the message should actually go and who should be notified about it:

:mail_forward([from])
    should return either
     . a list of objects (either players or $mail_recipients)
         to which mail for this recipient will be redirected.
     . a string error message to be printed to the player sending the message.
         If this recipient is one of the original destinations (i.e., not the
         result of a previous forwarding), no mail is actually sent.

    If :mail_forward returns a nonempty list, the recipient itself will *not*
    actually receive the mail message unless it is included in the list.
    #-1 is allowed to be on the list; it is ignored but does make the list 
    nonempty.  Thus, having :mail_forward() return {#-1} is the canonical way
    to have arriving mail disappear without being kept or forwarded.

:mail_notify([from]) 
    should return a list of objects that are to be told about any mail sent 
    to this recipient (whether or not the recipient actually receives it).
    Said objects must have a :notify_mail verb, but other from that, there 
    is no restriction on what these can be.

    object:notify_mail is called with the arguments 
    (sender,recipients,msgnumbers) where 
      recipients  == list of recipients including object in .mail_notify
      msgsnumbers == corresponding list of :receive_message return values
                 (or 0 if :receive_message is not actually called, which
                  will be the case if the recipient forwards without keeping)

When called as part of a mail send, the `from' argument is the immediate predecessor on the forwarding chain.  The default versions of these verbs return the values of .mail_forward and .mail_notify respectively (pronoun_subbing if the value is a string), unless this is a moderated mailing list and `from' is an unapproved sender (see `help MR-access') in which case the following verbs are called instead:

:moderator_forward(from) 
    what :mail_forward should return for mail coming from unapproved senders
    This returns .moderator_forward (pronoun_subbed if a string) by default.

:moderator_notify(from)
    what :mail_notify should return for mail coming from unapproved senders
    This returns .moderator_notify (pronoun_subbed if a string) by default.

Since the :mail_forward verbs only see the previous sender in the forwarding chain, if, e.g, B is moderated but A can send to B (i.e., B:mail_forward(A) returns an actual list), then any mail sent to A goes to B even if the original sender isn't normally allowed to send to B directly.

These verbs should all allow `from' to be omitted in which case they should return as if `from' were a generic approved sender (e.g., wizard).

It should rarely be necessary to actually modify any of :*_forward/*_notify verbs, since one has a fair amount of control over their behavior via the following properties

  .mail_forward
  .mail_notify
  .moderated          (see `help MR-access')
  .moderator_forward
  .moderator_notify

===== help mail-system ======[CORE]=================================================

Mail System
-----------
The following topics describe the guts of the LambdaCore mail system

sending-mail     -- how to send mail from a program; what happens.
mail-forwarding  -- how to do mail forwarding/notification (the simple version)
mail-resolution  -- how mail forwarding/notification works, in gory detail
receiving-mail   -- what :receive_message should do
mail-format      -- format of transmitted messages
mail-command-parsing   (TODO) -- routines for parsing mail commands

$mail_recipient  -- generic non-player mail recipient
$mail_agent      -- mail utility object

===== help @mailoptions ======[GENERAL]==============================================
SEE @mail-options

===== help make-core-database ======[WIZARD]===============================================

Syntax:  make-core-database

...makes a core database (surprise).  Film at 11...

===== help @make-guest ======[WIZARD]===============================================

Syntax:  @make-guest <adjective>

This creates a new guest character.  For example,
  @make-guest Loud
creates a child of $guest, owned by $hacker, named Loud_Guest and with aliases Loud and Loud_Guest.

See also `help @make-player'.

===== help @make-petition ======[LAMBDA]===============================================

Syntax:  @make-petition <name>,<name>,...

Creates a new petition for requesting that the wizards perform some technical
task aimed at addressing some social problem.  You may only have one petition
at a time.  The names on the command line are for the mailing list to be
associated with the petition; people will be able to send mail to
`*Petition:foo' or `*P:foo' for each `foo' given.  No spaces are allowed in
these names.

===== help @make-player ======[WIZARD]===============================================

Syntax:  @make-player <name>[,<aliases>] [<email-address> [password>]]

This creates a new player having the given name and password.
If an email address is given, this information is sent off to $new_player_log.
If password is null or not given, a random password is generated.

See also `@make-guest'.

===== help manipulation ======[GENERAL]==============================================

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

get  -- pick an object up and place it in your inventory
drop -- remove an object from your inventory and place it in the room
put  -- take an object from your inventory and place it in a container
give -- hand an object to some other player
look -- see what an object looks like

You can see what objects you're carrying with the 'inventory' command; see 'help inventory' 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' for details.

The following specialized objects have help entries you should consult:

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

===== help manners ======[LAMBDA]===============================================

The MOO, like other MUDs, is a social community; it is populated by real people that you interact with via network connections.  Like other communities of human beings, the members of this one have evolved certain guidelines for the behavior of the participants.  This article lays out what is believed to be the general consensus concerning these `rules of courteous behavior,' or `manners,' on the MOO.

Many of the rules that follow are by no means `obvious' or even related to similar rules in the real world.  The MOO is not the real world; it has its own special properties that require new kinds of rules.  These rules have been worked out through our experiences with the MOO; they reflect what we've learned about what make the MOO an enjoyable place.

        >> Be polite.  Avoid being rude. <<
The MOO is worth participating in because it is a pleasant place for people to be.  When people are rude or nasty to one another, it stops being so pleasant.

        >> Avoid revenge. <<
If someone is nasty to you, please try to ignore it or avoid them.  Revenge just escalates the level of rudeness and makes the MOO a less pleasant place for everyone involved. The wizards no longer have the job of acting as neutral parties in disputes between players, but it sometimes helps to call in someone neutral to help sort things out.

Purely defensive measures such as @eject, @refuse or @lock are not considered `revenge' in this sense.

        >> Respect other players' sensibilities. <<
The participants on the MOO come from a wide range of cultures and backgrounds.  Your ideas about what constitutes offensive speech or descriptions are likely to differ from those of other players.  Please keep the text that players can casually run across as free of potentially-offensive material as you can.  If you want to build objects or areas that are likely to offend some segment of the community, please give sufficient warning to the casual explorer so that they can choose to avoid those objects or areas.

        >> Don't spoof. <<
Spoofing is loosely defined as `causing misleading output to be printed to other players.'  For example, it would be spoofing for anyone but Munchkin to print out a message like `Munchkin sticks out his tongue at Potrzebie.'  This makes it look like Munchkin is unhappy with Potrzebie even though that may not be the case at all.  Please be aware that, while it is easy to write MOO programs that spoof, it is also easy to detect such spoofing and correctly trace it to its source.  See `help spoofing' for more details.

        >> Don't shout. <<
It is easy to write a MOO command that prints a message to every connected player in the MOO.  Please don't.  It is generally annoying to receive such messages; such shouting should be reserved for really important uses, like wizards telling everyone that the server is about to be shut down.  Non-wizards never have a good enough reason to shout.  Use `page' instead.

        >> Only teleport your own things. <<
By default, most objects (including other players) allow themselves to be moved freely from place to place within the MOO.  This fact makes it easier to build useful objects like exits and magic rings that move things as a part of their normal role in the virtual reality.  Unfortunately, it also makes it easy to move other players from place to place without their permission, or to move objects in and out of other players' possession.  Please don't do this; it's annoying (at the least) to the poor victim and can only cause bad feelings.  
EXCEPTION:  Room owners should feel free to @eject unwanted objects/players from their own rooms or to divert unwanted objects/players trying to enter their rooms.

        >> Don't teleport silently. <<
It is easy to write MOO commands that move you instantly from place to place.  In writing such programs, please remember to print a message to all players both in the place you're moving from and in the place you're moving to.  It is disconcerting and otherwise unpleasant for someone to suddenly say something in a room without there ever having been a notice that that person had arrived.  Similarly, it is annoying to discover that you've been talking for some time to a person who has left the room without a sound.

        >> Don't hog the server. <<
The server is carefully shared among all of the connected players so that everyone gets a chance to execute their commands.  This sharing is, by necessity, somewhat approximate however; while players cannot completely shut out others, they can significantly degrade the server's overall performance.  The most annoying way to do this is to run MOO programs that loop forever (or for a long time) using `fork (0)' or `suspend(0)' occasionally to keep from running out of ticks.  If you are writing a program that will run for a long time, please make it wait at least five seconds between iterations.  That is, if your task will run continuously, use `fork (n)' or `suspend(n)' where `n' is at least five.

        >> Don't waste object numbers. <<
Some people, in a quest to own objects with what they consider `interesting' object numbers (e.g., #17000, #18000, etc.) have written MOO programs that simply loop, creating and recycling objects until the `good' numbers come up.  Please don't do this; it artificially inflates all object numbers and increases the disk space used by the server unnecessarily.

      >> Don't Crack <<
It should go without saying: attempting to break into the system to obtain more quota, power, other player's site information, etc. is *very* rude. See 'help cracking' for more on this topic.

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

The wizards are always interested in hearing players' feedback on these rules of behavior.  The rules were developed by the consensus of players and can be expected to evolve that way, too.

If you couldn't read the above because it scrolled off your screen and you
don't have any text capture mechanism available on your host, please type
`help @pagelength' and `help @linelength' to learn how MOO can help you read
this (and other) lengthy text.

===== help @memory ======[GENERAL]==============================================

Syntax:  @memory

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

===== help message-sequences ======[GENERAL]==============================================

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

===== help messages ======[GENERAL]==============================================

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' 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 -- the messages on objects that can contain other objects
exit-messages -- the messages on exit objects
thing-messages -- the messages on objects that can be taken and dropped

===== help @messages ======[GENERAL]==============================================

Syntax:  @messages <object>

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

===== help miscellaneous ======[GENERAL]==============================================

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 -- printing the MOO server version number
@lastlog -- finding out when some player last connected to the MOO

===== help mode ======[EDITOR]===============================================

(NOTE EDITOR)
Syntax:  mode
         mode string
         mode list
         
There are (currently) two modes the note editor can be in.
One is string mode, in which if the text being edited is one line or less, 
it will be saved as a single string (or an empty string) rather than as a list.
The other is list mode, in which text is always saved as a list of strings.
The mode is set when the text is first loaded (string mode if the text is a string, list mode otherwise), but can be changed using this command.

The first form above (i.e., without any arguments) reports the current mode.

===== help @more ======[GENERAL]==============================================
*subst*
Syntax:  @more
         @more rest
         @more flush

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

%[strsub(player.more_msg,"%%n","37")]

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

===== help move ======[EDITOR]===============================================

Syntax:  m*ove [<range>] to <ins>

Moves the range of lines to place specified by <ins>.
If <ins> happens to be the current insertion point, the insertion point is moved to the end of the freshly moved lines.  If the range of lines contains the insertion point, the insertion point is carried over to the range's new location.

See `help insert' for a list of possibilities for <ins>.

===== help @move ======[GENERAL]==============================================

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.  The special case where <thing> is 'me' is useful for teleporting yourself around.

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

===== help @move ======[LAMBDA]===============================================

  @move <obj> to <location>  - teleport an object to a given location
  @go <location>             - teleport yourself to a given location
  @join <player>             - teleport yourself to a player's location

You can teleport an object (if it allows this) to any location that will accept it. For example, `@move rock to #11' will teleport the rock to the closet. `@move #123 to here' will move object #123 to your location. `@go home' will teleport you home. `@join yduj' will teleport you to yduJ's location. You can also teleport an object to #-1, which is nowhere.

See help teleport-messages for information on customizing the text that appears
(both to you and to others in the vicinity) when you teleport.
See also help @rooms for information on naming rooms for convenient movement.
If @move doesn't work and you own the place where the object is located, try using @eject instead.

===== help move() ======[LAMBDA-PROG]==========================================
(continued from programmers' manual help)
 - - - -
As a general rule, you will not be able to use the move() command to actually move most objects on the MOO. This is because your permissions as a player or as a programmer will not be sufficient to move() an object. For this reason, the root class defines a verb called :moveto, which may be used in the following way:

Consider the case that I wish to move Xiombarg (#37636) to the Nether Planes of Chaos (#37857). Were I wizardly, or were I Xiombarg, I could use the command
  move(#37636, #37857);
... but as circumstances has it, I'm not. Thus, I would use (and this is the general way to move objects around):
  #37636:moveto(#37857)

===== help movement ======[GENERAL]==============================================

The descriptions of most rooms outline the directions in which exits exist.  Typical directions include the eight compass points ('north', 'south', 'east', 'west', 'northeast', 'southeast', 'northwest', and 'southwest'), 'up', 'down', and 'out'.

To go in a particular direction, simply type the name of that direction (e.g, 'north', 'up').  The name of the direction can usually be abbreviated to one or two characters (e.g., 'n', 'sw').  You can also type 'go <direction>' to move; this is particularly useful if you know you're going to type several movement commands in a row (see 'help go').

In addition to such vanilla movement, some areas may contain objects allowing teleportation and almost all areas permit the use of the 'home' command to teleport you to your designated home (see 'help home' for more details).

===== help MR-access ======[CORE]=================================================

Controlling Access to Mail Recipients
-------------------------------------
:is_writable_by(one) - one may alter/add/remove saved messages
:is_readable_by(one) - one may read messages.
:is_usable_by(one)   - one may send to this list

By default, these verbs refer to the following properties:

writers   - list of players other from the owner who can do anything
readers   - if == 1, indicates a public mailing list.
            list of additional readers (by default anyone who receives mail 
            sent to the list can read the saved messages).
moderated - if false, indicates a normal mail recipient everyone can send to.
            otherwise this should be a list of approved senders.

Terminology:
  A mailing list is "public" if everyone can read it.
  A mailing list is "moderated" if not everyone can send to it.

Note that while being able to write to a recipient implies being able to read from it or send to it, neither of read-ability or send-ability implies the other.

It is highly recommended that if you are creating custom mail recipients with variable reader/sender lists, i.e., you find you need to write your own :is_readable/usable/writabe_by verbs, you are best off if such verbs are of the form

  return pass(@args) || << your_test(args[1]) >>

and have .writers == .readers == {} and .moderated == 1.  This will ensure
 (1) wizards having write access
     --- necessary in order for :receive_message to work
 (2) writers being able to read and send (the converse being a ludicrous 
     situation), 
 (3) persons on the mail_forward list of someone with reader access will also
     have read access (convenient).

===== help MR-naming ======[CORE]=================================================

One may always refer to a list by its object number.  In order to refer to it by name, it must be contained in $mail_agent, which holds all mailing lists, i.e., those that you want others to be able to refer to by name.

The .aliases field holds the names by which one may refer to the list, but only those names not containing spaces actually count for anything.  As with certain other types of objects (e.g., players), set_aliases() needs to be called in order to change the .aliases field.

$mail_agent:match(name) 
    is the canonical way to obtain the objectid of a mailing list 
    given the name ("*" is assumed; an initial "*" will be dropped).

$mail_agent:match_recipient(name) 
    is the canonical way to obtain the objectid of a list or player
    matching the given name.  An initial "*" indicates that this is 
    supposed to be a list.

$mail_agent:match_failed(objid,name) 
    is the mail_recipient counterpart to $command_utils:object_match_failed

===== help MR-reading ======[CORE]=================================================

Read verbs
----------
The following verbs may be used to extract headers/messages from readable mail recipients/players;

:display_seq_headers (message sequence, current message number, last_read_date)
  Does a @mail listing of the given message sequence.  If current message
  number is given and the sequence includes it, we mark it with a `>'.
  Likewise if the sequence includes any new messages (i.e., dated after 
  last_read_date), these are also indicated as such.

display_seq_full (message sequence, preamble)
  Does a @read listing of the given message sequence.  Each message is preceded
  by preamble.
  => {new current message number, new last_read_date}

:messages_in_seq (index)
  => {n, msg}
:messages_in_seq (message sequence)
  => {{n_1,msg_1},{n_2,msg_2},...}
  where the n_i are message numbers and the msg_i are messages in transmission
  format (see `help mail-format')

:list_rmm ()
  Does an `@unrmm list' listing of messages in .messages_going

===== help MR-searching ======[CORE]=================================================

Search verbs
------------
The following verbs can be used on a readable mail-recipient/player to search for messages with fields matching a given pattern.

from_msg_seq (objectid or list [,mask])
  => message sequence: messages from (one of) the given objectid(s)

%from_msg_seq (string or list [,mask])
  => message sequence: messages with (one of) the given string(s)
     in the From: line

to_msg_seq (objectid or list [,mask])
  => message sequence: messages to (one of) the given objectid(s)

%to_msg_seq (string or list [,mask])
  => message sequence: messages with (one of) the given string(s)
     in the To: line

subject_msg_seq (string [,mask])
  => message sequence: messages with given string occurring in Subject:

body_msg_seq (string [,mask])
  => message sequence: messages with given string occurring in body of message

In all cases `mask' is a message sequence which one may supply to limit the range of the search.  One way of looking at it is that the message sequence to be returned is first intersected with mask.

===== help MR-sequences ======[CORE]=================================================

Message Sequences
-----------------
A "message sequence" is a handle by which one may refer to a particular subset of a mail recipient's (player or $mail_recipient-descendant) saved messages.  Routines like rcpt:display_seq_headers or rcpt:display_seq_full need to be supplied with message-sequence arguments to deterimine which headers or full-messages to display.

Message sequences can in turn be obtained from routines like rcpt:parse_message_seq, which takes a command-line description of a message sequence on that particular recipient and returns the corresponding message sequence handle.

The actual form of a message sequence (though you shouldn't actually need to make use of this) is that of a set of integers in the format used by $seq_utils (see `help $seq_utils').  It should however be noted that these integers are *not* themselves message numbers, but rather indices into the list of saved messages.  For example, if a particular recipient holds 5 messages numbered 1,3,5,7,9.  Then the message sequence handle representing messages 3,5,7 collectively, would be {2,5} which is $seq_utils-ese for the range 2..4, namely the second, third and fourth messages saved on that recipient.

The following verbs are available for obtaining indices to use in message sequences

  :length_all_msgs()    => total number of messages, or equivalently,
                        => index of last message
  :length_num_le(n)     => number of messages numbered <= n, or equivalently,
                        => index of highest numbered message <= n
  :exists_num_eq(n)     => 0 unless there exists a message numbered n in which
                           case we return the index of that message.
  :length_date_le(date) => number of messages dated <= date, or equivalently,
                        => index of most recent message dated <= date

  :length_date_gt(date) => number of messages dated > date

Note that r:length_date_gt(date) == r:length_all_msgs()-r:length_date_le(date).
The only reason :length_date_gt is provided as a separate routine is in order 
to do quick checks for the existence of new mail (as @rn needs to do).

===== help MR-subscribing ======[CORE]=================================================

Subscribing to Mail Recipients
------------------------------
There are two notions of being "subscribed" to a mailing list/recipient.

(1) Hard subscribed == being on the recipient's .mail_forward list so that mail sent to this list is forwarded to one's own .messages as well (see `help mail-forwarding').

(2) Soft subscribed == keeping track of a current message for this recipient and (optionally) being on the recipient's .mail_notify list.


Each player has a .current_message property that contains, for each recipient the player cares to keep track of, a current message number and a last read date.

player:current_message(rcpt)                 (somewhat obsolete)
 => player's current message number for rcpt 

player:get_current_message(rcpt) 
 => player's {current message number for rcpt, last-read-date for rcpt}

player:make_current_message(rcpt)
 => adds a current_message entry for rcpt  (NOOP if rcpt == player)

player:set_current_message(rcpt,n|E_NONE,[,date])
 => sets player's current message number for rcpt to n iff n!=E_NONE
    updates the last-read-date for rcpt to date iff date > last-read-date

player:kill_current_message(rcpt)
 => removes current-message info for rcpt  (NOOP if rcpt == player)


On $mail_recipient, .mail_forward and .mail_notify are -c so one needs to use the following verbs to actually modify them.

    :add_forward(@new_recipients)
    :delete_forward(@recpients)
    :add_notify(@new_notifiees)
    :delete_notify(@notifiees)

A recipient's owner is, of course, allowed to make arbitrary changes to .mail_forward and .mail_notify.  However, the default versions of these verbs also allow any player to add him/herself to a recipient's .mail_forward or .mail_notify if the recipient is readable (see `help MR-access') by him/her.

Likewise any player may use the :delete* verbs to delete him/herself from any .mail_forward/.mail_notify list, regardless of his actual access to the list.

===== help MR-writing ======[CORE]=================================================

Write verbs
-----------
The following verbs can be used to manipulate writable mail recipients/players:

:rm_message_seq (message sequence)
  Does an @rmmail.  Messages in message sequence are removed from this 
  recipient's saved .messages and written to .messages_going.

:undo_rmm ()
  Does an @unrmm.  Messages in .messages_going are copied back to .messages.

:expunge_rmm ()
  Does an @unrmm expunge.  Blows away .messages_going.

:renumber ()
  Does a @renumber.


===== help multiple-characters ======[LAMBDA]===============================================

We permit individuals to have multiple characters on LambdaMOO.  However, as stated in "help quota-policy", the use of multiple characters specifically in order to defeat the quota mechanism is prohibited.  If we determine that an individual has done this, we may take action such as removing the additional characters.

Typically, an individual with multiple characters will have them for role-playing purposes.  The second character will not be granted building privileges (generally a quota of two is permitted, to make one or two personal objects to assist with the role playing).  An individual who wants to build using a second character must apply through the ARB, using the building of the primary character as evidence for the quota increase.  We use the player registration system to verify that the two characters are controlled by the same individual.

Some individuals share their network accounts with friends and relatives.  We officially frown on this practice, but are sometimes willing to grant a character to such a friend or relative, provided we are told full name and relationship to the account holder.  Note that the account holder's character will be held responsible for their guests' behavior.

If you are registering for a second character, use the email address form of registration (LambdaMOO-Registration@Xerox.COM).  You should mention in the email that it is your second character, and who your main character is.

Please do not "help" your friends by requesting characters for them if they have their own email addresses.  It will be flagged as a second character and you will waste your time and ours as we interrogate you about it.

We generally do not permit more than one individual to control a single character.  You should not be giving out your password to other users, and your character is for your use only.  In certain rare cases, two or more players may wish to collaborate on a project, and the easiest way to help them accomplish this is with a shared character.  This will only be permitted when the players all have individual characters as well, and must be cleared with the wizards and the ARB.  The Grand_Master of the LambdaMOO RPG system is an example of a shared character for a collaborative project.

===== help name ======[GENERAL]==============================================

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.

===== help negative_quota ======[GENERAL]==============================================
*subst*
We recently reduced the initial quota for new players to %[$help:player_quota()].
Those of you who were around before this are covered by a grandfather clause
i.e., you get to keep your over-quota objects.  However this means that 
your quota for creating new objects may now be *more than* used up, i.e.,
negative.  In particular, this means that if you recycle an object, 
you will not be able to @create one in its place.

You can, however, re-use your over-quota objects by using the @recreate 
command instead (see `help recreate').

===== help @net-who ======[WIZARD]===============================================

Syntax:  @net-who [<player>...]
         @net-who from [<domain>]

Synonym: @@who

@net-who without any arguments prints all connected users and hosts.  If one or more <player> arguments are given, the specified users are printed along with their current or most recent connected hosts.  If any of these hosts are mentioned on $login.blacklist or $login.graylist (see `help blacklist'), 
an annotation appears.

With a `from...' argument, this command consults $site_db and prints all players who have ever connected from the given domain.

===== help news ======[GENERAL]==============================================

Syntax:  news

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

===== help @newt ======[WIZARD]===============================================
*subst*
Syntax:  @newt <player> [commentary]

The @newt command temporarily prevents logins on a given player.
It works by installing a confunc ($wiz_utils:newt_confunc) on player that does an immediate ;boot_player(), saving any existing :confunc the user may have as :denewt_confunc.  Use @denewt to reverse this.

You must give either the player's full name or its object number.
Also, this command does not let you @newt yourself.

Mail will be sent to $newt_log, listing the player's .all_connect_places and including any commentary you provide.  E.g.,

  @newt Twit  did real annoying things.

As with @toad and @programmer, there are messages that one may set

@newt  [%[$wiz.newt_msg]]
  Printed to everyone in the room in which the victim is being @newted.
  If you're worried about accidentally newting yourself in the process of
  setting this message, you can't (see above).

@newt_victim  [%[$wiz.newt_victim_msg]]
  Printed to the victim.  
  This is followed by $login:newt_registration_string().

See `help @toad' if you need something more drastic.

===== help next ======[EDITOR]===============================================

Syntax:  n*ext [n] ["<text>]

Moves the insertion point down n lines.  If <text> is provided, inserts a new line there just like `say'.
Equivalent to `insert +n'.  As one might expect, n defaults to 1.

===== help @next ======[GENERAL]==============================================

Syntax:  @next [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.

===== help $no_one ======[CORE]=================================================

$no_one
-------
is a powerless player.  He owns no objects, not even himself; nor does he own any verbs.  He is, however, a programmer and thus may use eval().
In fact his sole purpose is to evaluate questionable code.
`questionable' could be in either or both of the following senses

(1) Its origin is sufficiently uncertain so that there is no obvious way of deciding whose permissions it should run under.
(2) The code itself is potentially malicious, i.e., to the extent that one does not want to be evaluating it using one's own permissions.

set_task_perms($no_one);  is thus the canonical idiom in wizard code for rendering anything that follows mostly harmless.  For use by ordinary programmers, we have:

    $no_one:eval(string)

which attempts to evaluate an arbitrary string using $no_one's permissions.
string is either an expression or ";" followed by one or more statements, of which the final semicolon may be omitted.  return values are what eval() would return (either {1,value} or {0,@error_messages}).

===== help @notedit ======[GENERAL]==============================================

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' for more detail.

===== help notes ======[GENERAL]==============================================

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 -- reading the text on the note
write -- adding text to a note
erase -- removing all the text from a note
delete -- deleting one line of text from a note

@notedit -- general editing on the text of a note

encrypt -- restricting who can read a note
decrypt -- undoing a previous encryption

You can make a note by creating a child of the standard note, $note (see 'help @create').  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'.

===== help notify() ======[LAMBDA-PROG]==========================================
(continued from programmers' manual help)
 - - - -
Under normal circumstances, notify() is not the preferred method of sending text to a player; perhaps the most important reason for this is that a task with non-wizardly permissions cannot notify() another player.

For this reason, all objects in the MOO have both :tell and :notify verbs which can be used within programming. Thus, if you would like to send text to Xiombarg (#37636), you can and should use a line similar to the following in your programming:
  #37636:tell("Hullo, there!");
  #37636:tell("Hello, there. I bring you greetings from ", player:title(), ".");

The :tell verb serves several functions on players (on other objects, it will most likely merely ignore the text). It takes several arguments (concatenating them into a single string if needed). It handles spoof-attribution, if the player's .paranoid is set, and checks for gagging if the player's .gaglist is set. Assuming the text isn't being gagged, it's sent to the :notify verb next.

The :notify verb takes a single string as an argument, and (again, on players) must be called either by permissions which control the player, or by the player itself (perhaps by one of the player's parents). It handles line-breaks (if required, see `help @linelength') and page-breaks (if required, see `help @pagelength') and, in the end, actually contains the raw notify() call which sends the text to the player.

===== help object-matching ======[CORE]=================================================

Which :match...() Verb Do I Call?
---------------------------------
There are many situations where one wishes to obtain an object from a room or a player's .contents whose name/aliases matches a particular string.  There are four main verbs available for this and it is important to understand the distinctions between them and how they are supposed to be used.

(*)  LOC:match("X")
     -- what you get looking for something that is inside LOC and named "X".
        By default, this looks through LOC.contents to find a unique object 
        having a name or alias that has "X" as a prefix.

Essentially, you can think of :match as a contents-matching verb, though, e.g., for rooms you also get matches on exits as well.

(*)  LOC:match_object("X", YOU)           [YOU defaults to player]
(*)  YOU:my_match_object("X", LOC)        [LOC defaults to player.location]
     -- what YOU get being located at LOC and looking for something named "X".
        By default these both return $string_utils:match_object("X",LOC,YOU)

(*)  $string_utils:match_object("X", LOC, YOU) 
   -- what you *would* get *if* YOU were a typical player, YOU were inside LOC,
      YOU were looking for something named "X", *and* LOC were a typical place.

In other words, $string_utils:match_object describes the :match_object() algorithm for "typical places" and the :my_match_object for "typical players":

    (1)  check for "X" being one of "", "me", "here", "$something", or "#n"
    (2)  try YOU:match("X") i.e., something in your inventory (maybe)
    (3)  try LOC:match("X") i.e., some object in the room (maybe)

The distinction between these location:match_object and player:my_match_object has to do with whether the player or the location should determine what the matching algorithm is.  Which one you should use depends on the command that you are writing.  If you are writing a command with a virtual-reality flavor, then you should be respecting the room owner's idea of which objects you can "see" and thus the command should be calling the location's :match_object verb.  If you are writing a building/programming command where it is appropriate for the player to determine the matching algorithm  --- whether because the current location is irrelevant, not to be trusted, or both --- then the player's :my_match_object verb should be called.

Examples:

  `look diamond in box'
      calls box:match("diamond").  This is a match on the contents of box.

  `take ball', 
      calls player.location:match_object("ball")
      to determine which "ball" to take.  Note that if the room is dark, 
      we might not be able to find any "ball".

  `@program widget:foo', 
      calls player:my_match_object("widget") to get the player's own idea
      of what "widget" should be.  Note that if I were carrying something 
      named "widget" and expecting to be programming a :foo() verb on it,
      it would be potentially disastrous should the room where I am decide
      for me to be programming something else (not even necessarily 
      called "widget").

Object Matching Failures
------------------------
As with other matching routines, one gets back 

  $failed_match in the case of no matching object
  $ambiguous_match in the case of more than one matching object
  $nothing in the case of a blank string argument

or an object-id.  In these first 3 cases, one usually wants to translate these nonresults to the player; this is what $command_utils:object_match_failed.  The standard idiom to mimic what the builtin parser does, say, with the direct object is

  dobj = foo:match_???(dobjstr);
  if($command_utils:object_match_failed(dobj, dobjstr))
    "...give up.  nothing to do.   error message has already printed...";
  else
    "...dobj is something useful.  Continue...";
    ...
  endif

===== help @opacity ======[GENERAL]==============================================

Syntax:
  @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 closed
   2:  The container is a black hole, and you can never see into it whether closed or open.  

The default @opacity is 1.

===== help page ======[GENERAL]==============================================
*subst*
Syntax:  page <player> [[with] <text>]

Sends a message to a connected player, telling them your location and, optionally, <text>.

Example:
Munchkin types:
        page Frebble with "Where are you?"
Frebble sees:
        You sense that Munchkin is looking for you in the Kitchen.
        He pages, "Where are you?"
Munchkin sees:
        Your message has been received.

Advanced Features:
Page refers to the following messages on the players involved (see 'help messages'):

@page_origin [%[$player.page_origin_msg]]
  Determines how the recipient is told of your location.

@page_echo   [%[$player.page_echo_msg]]
  Determines the response received by anyone who pages you.

@page_absent [%[$player.page_absent_msg]]
  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') except that in both cases the direct object (%d) refers to the recipent of the page and the indirect object (%i) refers to the sender.  You should only change these messages if you want to add to the Virtual Reality feel of the MOO for your character.

===== help @pagelength ======[GENERAL]==============================================

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, and ensure wrapping is on with @wrap
on.  (See help @linelength and help @wrap.)  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.

===== help @paranoid ======[GENERAL]==============================================

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.

===== help @parents ======[GENERAL]==============================================

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 Haakon
  Haakon(#2)   generic wizard(#218)   generic programmer(#217)   generic 
  player(#6)   Root Class(#1)

===== help @password ======[GENERAL]==============================================

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

Only the first 8 characters of a password are significant.

===== help pause ======[EDITOR]===============================================
SEE quit

===== help perish ======[EDITOR]===============================================
SEE unpublish

===== help @peek ======[GENERAL]==============================================
SEE @read

===== help petition ======[LAMBDA]===============================================
SEE petitions

===== help petition-commands ======[LAMBDA]===============================================
SEE petitions-commands

===== help petition-motivation ======[LAMBDA]===============================================
SEE petitions-motivation

===== help petition-process ======[LAMBDA]===============================================
SEE petitions-process

===== help petitions ======[LAMBDA]===============================================

On LambdaMOO, the wizards are intended to work purely as technicians, maintaining the MOO, fixing bugs, and implementing new core features requested by the users.  Some kinds of implementation requests, though, are very controversial because they involve attempted technical solutions for social problems.  The petitions and ballots mechanism is for making such requests in a form that fairly clearly represents a MOO-wide consensus, thus compelling the wizards to act.

Petitions and ballots, therefore, are for proposals that the wizards perform some set of purely technical actions that only wizards can perform, where those actions are intended to address some social goal.  For example, the actions might be intended
   --- to directly achieve some social goal (such as banishing some individual
       from the MOO or removing some person from the list of wizards),
   --- to grant some piece of wizardly power to the general MOO in some form
       that's intended to be used to address social problems in the future
       (such as creating a truly escape-proof jail or giving players a way to
       temporarily banish each other from the MOO),
   --- to restrict some or all players in some way that is believed will help
       to achieve some social goal (such as keeping guests from logging in
       anonymously or making it impossible for players to print out messages
       containing certain words), or
   --- to modify the petitions and ballots mechanism itself in some qualitative
       way (such as changing it to require fewer signatures on petitions or
       only a simple majority on ballots).
Petitions and ballots are *not* for simple requests that the wizards fix some bug in the core or, at the other end of the spectrum, are they for proposals that involve the wizards having to exercise some kind of social judgement role (such as demanding that the wizards banish anyone who's being abusive).

The detailed documentation on the petitions and ballots system is contained in the following help topics:

   petitions-process    -- step-by-step instructions on creating a petition and
                           ushering it through all of the stages through making
                           the entire LambdaMOO community vote on it
   petitions-motivation -- Haakon's original rationale for various details of
                           the petitioning and balloting process
   petitions-commands   -- a summary of all of the commands related to
                           petitions and ballots

===== help @petitions ======[LAMBDA]===============================================

Syntax:  @petitions [all]

Prints a list of all petitions that have been signed by someone (or, if the
argument `all' is given, all petitions) in tabular form, showing each
petition's author, object number, title, vetting status, and signature count,
along with an indication of whether or not you have signed it.

===== help petitions-commands ======[LAMBDA]===============================================

               Summary of Petition- and Ballot-Related Commands
               ------------------------------------------------

Creating and Monitoring Petitions and Ballots:

   @make-petition <name>,<name>,...
        Make a new petition.
   @petitions [all]
        List active petitions with signatures (or all petitions).
   @ballots [all]
        List open ballots (or all ballots).

Authoring Petitions

   @rename <petition> to <name>,<name>,...
        Change the names of the petition's associated mailing list.
   retitle <petition> as <new-title>
        Change the title of the petition, losing any signatures or vetting.
   @notedit <petition>
        Use the note editor to change the text of the petition, losing any
        signatures or vetting.
   burn <petition>
        Completely destroy the petition.
   submit <petition>
        Request that the wizards grant their approval to the petition.
   @options on <petition>
        See the current settings of the petition's authoring options.
   @set-option <option> on <petition>
   @unset-option <option> on <petition>
        Change the current setting of one of the petition's authoring options.

Manipulating Petitions

   look <petition>
        See how many signatures are on the petition and how many are needed to
        turn it into an open ballot.  Also shows the name of the petition's
        author and the names of its associated mailing list.
   read <petition>
        See the title and text of the petition.
   sign <petition>
        Affix your signature to the petition.
   unsign <petition>
        Erase your signature from the petition.
   list <petition>
        See a list of all of the signatures on the petition.

Manipulating Ballots

   read <ballot>
   list <ballot>
        Just like on petitions, since all ballots used to be petitions.
   look <ballot>
        See how many votes have been cast on the ballot (but not on which side
        or by whom) and when voting will close on it.
   vote yes on <ballot>
   vote no on <ballot>
   abstain on <ballot>
        Register your vote on the ballot.  You may change your vote as many
        times as you like before voting closes.

===== help petitions-motivation ======[LAMBDA]===============================================

              Why the Petitions and Ballots Process is Just So
              --------------------------------------------------

This article lays out Haakon's original motivations in designing the petitions and ballots process as he did.  For an overview of the system, see `help petitions' and for the details of the process, see `help petitions-process'.

The 30-day waiting period before voter eligibility was inspired by Jonny's and JoeFeedback's pre-system petitions to that effect; it seemed a good idea that people be required to have *some* experience with this place before they are allowed to vote on changing its rules.

The one-petition-per-voter limit is to keep the number of these things manageable; if you have two great ideas, it shouldn't be too hard to find someone else to create a petition for the second one.

The mailing-list associated with every petition is intended primarily to provide a forum for opponents to the proposal.  This provides a single point of reference for potential signers and voters to hear the `other' side of the argument.

Clearly, any change to the text or title of a petition could be enough to make some folks wish they hadn't signed or to lose the clearance of the wizards; thus the automatic loss of signatures and vetting on all text/title changes.

You need ten or more signatures before requesting a wizardly vetting simply to keep the wizards' time from being wasted vetting petitions that have no base of support whatsoever.

Vetting is required at all simply to save everyone's time, so that unworkable proposals don't get all the way through the process just to be discarded at the end.  The last condition (concerning conflicts with real-world laws and regulations) is legally necessary; Haakon is currently engaged in trying to get some legal advice concerning the liabilities incurred by running and/or administering LambdaMOO.  He'll make his findings known once he has some.

A lot of signatures are required to turn a petition into an open ballot, but this seemed reasonable; after all, if you want to change the rules of the universe, you really ought to need the support of a fair fraction of those who will have to live under those rules.  It was Haakon's expectation that you'd need to do some real footwork to get an open ballot on your issue, talking to a lot of players that you don't know and getting the issue discussed pretty broadly.  Think of this process as paralleling that of getting a voter-sponsored initiative on the ballot in the real world.

Abstentions are the mechanism by which players can both avoid stating a preference and avoid getting bothered about it every time they connect.

The 2/3 majority rule for passing ballots is to prevent the consternation caused by `close' votes common to simple majority rules.  There is no quorum for votes because the number of petition signatures required already fulfills that purpose.

===== help petitions-process ======[LAMBDA]===============================================

              How to Make a Vote Binding on the LambdaMOO Wizards
              ---------------------------------------------------

DEFINITION: An `eligible voter' at a certain time is a LambdaMOO player who (1) is not a wizard, (2) is not a guest, (3) is not a registered `second character', and (4) first connected to LambdaMOO more than thirty days before the time in question.

Suppose that you, an eligible voter, wish to have the LambdaMOO wizards do some programming job that requires their special permissions.  This is the procedure to follow in order to compel the wizards to do that job.  See `help petitions' for a more detailed description of what are and are not appropriate uses for petitions.

First, create a blank petition using the `@make-petition' command; type `help @make-petition' for details on the use of the command.  Petitions are note-like objects with a title and some text.  You will not technically `own' the blank petition you receive (and your quota will not be affected by creating it), but you will be the only person able to change the title or text.  Each voter may have only one petition at a time.

Note that every petition is also a mailing list, intended for discussion of the pros and cons of the proposal written on it.  Anyone can use the normal mail commands to subscribe to or read and write mail on the mailing list; the list name is `*Petition:xxxxxx', where `xxxxxx' is the name you gave in the `@make-petition' command.  The abbreviation `*P:xxxxxx' also works.  NOTE that you can change the name of your petition's mailing list at any time without losing either signatures or vetting (see below) simply using the normal @rename command.

Second, give the petition a title (using the `retitle' command) and write down your proposal on the petition (using the @notedit command, for example).  Be detailed and precise; this will be important later.  Note that it's in your best interest to get the text `right' early on; any edit to the text or title of the petition will wipe out any vetting or signatures you may have acquired (see below).

Third, get ten or more eligible voters to sign the petition, including yourself, using the `sign' verb on the petition.  Note that people do not need to be in the same room as the petition object to read or sign it; they can refer to it solely by object number if necessary.  Each voter can sign each petition at most once.  Any voter can erase their signature from a petition, using the `unsign' verb, at any time before it becomes an open ballot (see below).

Fourth, having gotten your initial ten or more signatures, submit your petition to the wizards for vetting, using the `submit' verb on the petition.  This will send mail to the *Wizards mailing list (and to the petition's mailing list) telling them about your petition.  As soon as possible, one of them will read over your petition, making sure that the proposal there is
   (1) appropriate according to the guidelines given in `help petitions',
   (2) sufficiently precise and detailed in its description of the desired
       effect or facility that the wizards can understand how to implement it
       (it is best however if you do not specify a particular implementation).
   (3) technically feasible for them to implement,
   (4) not likely, in their opinion, to jeopardize the functional integrity of
       the MOO, and
   (5) not likely, in their opinion, to bring the wizards, Pavel Curtis, or the
       Xerox Corporation into conflict with any real-world laws or regulations.
These are the *only* criteria to be used by the wizards in deciding whether or not to vet a petition; in particular, their personal opinions concerning the wisdom of the proposal is irrelevant to the vetting process.

If a wizard believes that all of these conditions are satisfied, they will mark the petition as `vetted' and thus cleared for potentially coming to a vote of the populace; regardless of the wizard's decision to vet or not, you will be notified by MOO-mail, with a copy sent to the petition's mailing list.  Note that you need not wait for the vetting to come through before collecting more signatures on your petition; remember, however, that if the wizard finds a problem and refuses to vet it, you'll have to edit the text to eliminate the problem and that will automatically erase any signatures.

Finally, having gotten your vetting from the wizards, you need to collect more signatures.  The number you need is 10% of the number of eligible voters who have connected to LambdaMOO within the past 30 days; you can see how many that is (and how many you've got) by looking at the petition object.  When you reach your goal, your petition will automatically be transformed into an `open ballot', ready for a formal vote of the populace.  A notice of this fact will be posted in the LambdaMOO newspaper and all connected players immediately notified.  Since your petition would no longer be a petition (or even yours, really), you could now create a new one if you so wished.

Once your petition has become an open ballot, eligible voters can start voting on it, using the `vote' or `abstain' verbs on the ballot.  Every voter who hasn't yet voted on the issue will be notified about it whenever they connect to the MOO.  Voting lasts for exactly two weeks, starting the moment that the petition gets its last signature.  During that period, each voter can change their vote as often as they like; each vote is either `for' the proposal, `against' it, or `abstaining'.  Note that those who signed the original petition must manually cast their votes like anyone else; they are not automatically considered to be in favor of the proposal.

At the end of the two-week voting period, the ballot is closed and the vote counts posted to the newspaper and as the last message sent to the original petition's mailing list.  These counts are entirely secret until the ballot is closed, and the identities of the people who voted each way are entirely secret forever.  The proposal is considered to have `passed' if and only if there are at least twice as many votes `for' it as `against' it.  There is no minimum number of votes required (no `quorum').  Any proposal that passes will be implemented by the wizards as soon as possible.

===== help $player_db ======[CORE]=================================================


Database of Players
-------------------
This is an instance of the Generic Database ($generic_db) that
holds the {name/alias,#objectid} pairs for every 
name and alias of every player in the MOO.

Verbs supplied include

  :find(string)        => player or $ambiguous_match or $failed_match
  :find_exact(string)  => player or $failed_match (does not do partial matches)
  :find_all(string)    => list of all matching players

  :insert(string,player) 
       records that string is now a name or alias of player
  :delete(string) 
       removes string from the db
  :available(string)
       returns 1 if string is available as a player name or alias,
       an object if string is in use, or 0 if string is otherwise unavailable.
  :load()
       resets the db, inserting all current player names and aliases.

The internal representation and all of the above verbs (except :load() and
:available()) are as described for $generic_db.

It should be noted that for any application that involves resolving a player name from a command line, you should be using $string_utils:match_player() rather than $player_db:find(), since the former will deal correctly with other ways of referring to players apart from their names and aliases (e.g., literal object numbers, "me", "$no_one"...).

:load() needs to be done periodically as it is possible for the player db 
to get out of synch with reality.  In particular, there is currently no way
to block someone writing his own player :recycle() verb that neglects to 
remove his names from the player db.

While a :load() is in progress the .frozen property is set to 1 to indicate that any results of :find*() are not to be trusted.

===== help player-names ======[GENERAL]==============================================
*subst*
A player name must be a single word, must not contain any spaces, backslashes, or quotes, nor can it begin with the characters #, *, (, or ).  Finally it cannot be one that is in use by any other player nor any of the words on the following list:

%;;lns={};for l in ($string_utils:columnize({@$player_db.stupid_names,@$player_db.reserved},6)) lns={@lns,"  "+l}; endfor return lns;

Note that these rules apply as well to your single-word aliases, since those can equally well be used to refer to you in commands that match on player names (@who, whereis, ...).  There are no restrictions on your multi-word aliases, however the commands that expect player names will not recognize them.

===== help players ======[GENERAL]==============================================

There are a number of commands for modifying various characteristics of the object representing you in the MOO, your 'player'.  Help on them is available in the following topics:

@describe -- setting what others see when they look at you
@gender -- changing your player's gender
@password -- changing your player's password
@sethome -- changing your designated home room
@rename -- changing your name and/or aliases
@linelength -- adding word-wrap to the lines you see

===== help precedence ======[PROGRAMMER]===========================================

The table below gives the relative precedence of all of the MOO operators; operators on higher lines in the table have higher precedence and those on the same line have identical precedence:

        !       - (without a left operand)
        *       /       %
        +-
        ==      !=      <       <=      >       >=      in
        &&      ||
        ... ? ... | ... (the conditional expression)
        =

Thus, the horrendous expression

        x = a < b && c > d + e * f ? w in y | - q - r

would be grouped as follows:

        x = (((a < b) && (c > (d + (e * f)))) ? (w in y) | ((- q) - r))

===== help prepositions ======[PROGRAMMER]===========================================

*prepositions*
The complete list of prepositions recognized by the command-line parser:


===== help prev ======[EDITOR]===============================================

Syntax:  p*rev [n] ["<text>]

Moves the insertion point up n lines.  If <text> is provided, a new line is inserted as with `say'.
Equivalent to `insert -n'.  As one might expect, n defaults to 1.

===== help @prev ======[GENERAL]==============================================

Syntax:  @prev [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.

===== help print ======[EDITOR]===============================================

Syntax:  pri*nt

Display your text without line numbers.

(MAIL ROOM)
Display your message including headers.

===== help privacy ======[GENERAL]==============================================

Some things you should be aware of:

 -*-*- OMNISCIENT WIZARDS AND SYSADMINS: -*-*-
Wizards can look at absolutely *anything* in the MOO database.  
The arch-wizard and the sysadmin for the MOO-server host have complete access not only to the MOO database itself but to many other possibly-relevant things.
The above mentioned parties (wizards et al), 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') 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.

===== help .program ======[PROGRAMMER]===========================================

Syntax:  .program <object>:<verb-name>
              :
              :
              <lines of MOO code>
              :
              :
         .

Provides or changes the MOO program associated with the named verb on the named object.

This command is mostly obsolete.  Use @program instead.  The only reason this command still exists is that it is a server builtin command that will continue to work in the (unlikely) event that @program gets trashed ...

This command works differently from most other MOO commands, in that it actually changes how the server will interpret later lines that you type to it.  After typing the '.program' line, you are in 'programming mode'.  All lines that you type in this mode are simply saved away in the server until you type a line containing only a single period ('.').  At that point, those lines are interpreted as a MOO program and are checked for syntax errors.  If none are found, a message to that effect is printed and the code you typed is installed as the program for the verb in question.  In any case, after typing the '.' line, you are returned to the normal input-handling mode.

===== help @program ======[PROGRAMMER]===========================================

Syntax:  @program <object>:<verb-name>
         @program <object>:<verb-name> <dobj> <preposition> <iobj>

Changes the MOO program associated with the named verb on the named object.
If you provide <dobj> <preposition> and <iobj> as in the second form of this command, then it is the first verb with matching direct object, preposition and indirect object specifiers that is the one getting the new program.  This is useful if you have several verbs matching the same name.

Typing the @program command always puts the server into a line-reading mode, in which each line you type is saved away without any action unless said line is one of the following:

  .
  @abort
  .<text>

A period on a line by itself ends the line-reading mode and continues with the command, in this case, the saved lines are considered as a program, checked for syntax errors and, if no errors are found, installed as the new program for the specified verb.  

@abort causes the command to terminate immediately with no change to any verb's program.  .<text> enters <text> literally as one of the lines to be saved, which is used for when, e.g., you want to enter the line `.' or the line `@abort'.

Note that this command *always* enters the line-reading mode, even if the indicated verb is not found.  In this case, lines of text are still read but they are ignored.  After any @program command, you always need to type a period or `@abort' to get back into the normal command-reading mode.

===== help @programmer ======[WIZARD]===============================================
*subst*
Syntax:  @programmer <player>

Sets the programmer flag on the indicated player and sends mail to $new_prog_log.  

If the player is not already a descendant of $prog, we @chparent him/her to $prog.  In this case, if $prog has a larger .ownership_quota than its ancestors, then we raise the player's quota by the difference between $prog.ownership_quota and the .ownership_quota of the common ancestor of player and $prog, be this $player or some intermediate class.

There are messages that one may set to customize how the granting of a programmer bit looks to the victim and to any onlookers.  After all, this is a seminal event in a MOOer's life...  Thus we have

@programmer  [%[$wiz.programmer_msg]]
  Printed to everyone in the room with the victim being @programmer'ed.

@programmer_victim  [%[$wiz.programmer_victim_msg]]
  Printed to the victim.

These are pronoun subbed with victim == dobj.

===== help programming ======[GENERAL]==============================================

MOO contains a rich programming language for the creation of interesting rooms, exits, and other objects.

Not every player is allowed to program in MOO, including (at the moment, anyway) you.  If you would like to be, find a wizard and convince them that you've got good ideas that the MOO needs.  Good luck!

===== help programming ======[PROGRAMMER]===========================================

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 -- a brief reference for the syntax and semantics of the MOO language
tasks -- a brief description of MOO tasks and their resource limits

@property -- adding a property to an object
@rmproperty -- removing a property from an object

@verb   -- adding a verb to an object
@rmverb -- removing a verb from an object
@args   -- changing the syntax of a verb
@copy   -- copying a verb from one object to another

.program/@program -- entering the program for a verb
@list -- printing a listing of the program for a verb
@edit -- editing verb code

@show     -- looking at all the details of an object, a property, or a verb
@parents  -- listing the ancestors of an object
@kids     -- listing the children of an object
@contents -- listing the contents of an object
@chmod    -- changing the permissions on an object, a property, or a verb
@chparent -- changing the parent of an object
@rename   -- changing the name of a verb or object

eval -- executing MOO statements and expressions without writing a verb

===== help programming ======[LAMBDA]===============================================

MOO contains a rich programming language for the creation of interesting rooms, exits, and other objects.

Not every player is allowed to program in MOO, including (at the moment, anyway) you.  If you would like to be, find a wizard and convince them that you've got good ideas that the MOO needs.  Good luck!

===== help pronouns ======[GENERAL]==============================================

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 %p knee."

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

As it happens, you can also refer to elements of the command line (e.g., direct and indirect objects) the object issuing the message, and the location where this is all happening.  In addition one can refer to arbitrary string properties on these objects, or get the object numbers themselves.

The complete set of substitutions is as follows:

        %% => `%'  (just in case you actually want to talk about percentages).
    Names:
        %n => the player
        %t => this object (i.e., the object issuing the message,... usually)
        %d => the direct object from the command line
        %i => the indirect object from the command line
        %l => the location of the player
    Pronouns:
        %s => subject pronoun:          either `he',  `she', or `it'
        %o => object pronoun:           either `him', `her', or `it'
        %p => posessive pronoun (adj):  either `his', `her', or `its'  
        %q => posessive pronoun (noun): either `his', `hers', or `its'
        %r => reflexive pronoun:  either `himself', `herself', or `itself'
    General properties:
        %(foo) => player.foo 
        %[tfoo], %[dfoo], %[ifoo], %[lfoo]
               => this.foo, dobj.foo, iobj.foo, and player.location.foo
    Object numbers:
        %#  => player's object number
        %[#t], %[#d], %[#i], %[#l]
            => object numbers for this, direct obj, indirect obj, and location.

In addition there is a set of capitalized substitutions for use at the 
beginning of sentences.  These are, respectively, 

   %N, %T, %D, %I, %L for object names, 
   %S, %O, %P, %Q, %R for pronouns, and
   %(Foo), %[dFoo] (== %[Dfoo] == %[DFoo]),... for general properties

Note: there is a special exception for player .name's which are assumed to
already be capitalized as desired.

There may be situations where the standard algorithm, i.e., upcasing the first letter, yields something incorrect, in which case a "capitalization" for a particular string property can be specified explicitly.  If your object has a ".foo" property that is like this, you need merely add a ".fooc" (in general .(propertyname+"c")) specifying the correct capitalization.  This will also work for player .name's if you want to specify a capitalization that is different from your usual .name

Example:  
Rog makes a hand-grenade with a customizable explode message.
Suppose someone sets grenade.explode_msg to:

  "%N(%#) drops %t on %p foot.  %T explodes.  
   %L is engulfed in flames."

If the current location happens to be #3443 ("yduJ's Hairdressing Salon"),
the resulting substitution may produce, eg.,

  "Rog(#4292) drops grenade on his foot.  Grenade explodes.  
   YduJ's Hairdressing Salon is engulfed in flames."

which contains an incorrect capitalization.  
yduJ may remedy this by setting #3443.namec="yduJ's Hairdressing Salon".

Note for programmers:  
 In programs, use $string_utils:pronoun_sub().
 %n actually calls player:title() while %(name) refers to player.name directly.

===== help @property ======[PROGRAMMER]===========================================

Syntax:  @property <object>.<prop-name>
         @property <object>.<prop-name> <initial-value>

Adds a new property named <prop-name> to the named object.  The initial value is given by the second argument, if present; it defaults to 0.  

Normally, a property is created with permissions 'rc' and owned by whoever types the command.  However, you may also specify these explicitly

         @property <object>.<prop-name> <initial-value> <permissions>
         @property <object>.<prop-name> <initial-value> <permissions> <owner>

Only wizards can create properties with owners other than themselves.

'@property' can be abbreviated as '@prop'.

===== help @prospectus ======[PROGRAMMER]===========================================

Usage:  @prospectus player [from number] [to number]

Like @audit, but displays more information.  The optional from and to arguments are for restricting the display to specific object numbers, if you happen to know the player only owns objects in the included range.

Example:
   Objects owned by Frand (from #0 to #54949):
     P[ 23]    #47 Frand                          [Hyperspace Hovel]
     T        #152 Frand's trio of shoes          [Frand]
   KfT[ 10]   #391 Frand's notifier class         [Nowhere]
     T[  8]   #393 Frand's chessboard             [The Dining Room]
   KfT[ 11]   #775 Frand's generic game board     [Nowhere]
     T[  6]   #893 Ghost game                     [The Dining Room]
     T[ 16]   #894 Frand's mind bender            [The Dining Room]
     C        #997 polka-dot hole                 [Hyperspace Hovel]
     R[  1]  #1002 Hyperspace Hovel              
     E      #11958 out                            Monster Cage->*Dr. Empirico's Lab
      ...

The K in the first column indicates that the object has children owned by other players.  A lowercase k indicates the object has children but owned only by the player.  The second column indicates whether the object is publicly readable or publicly parentable.  An r indicates readability.  A lowercase f indicates the object is both readable and allows children (is fertile).  An uppercase F indicates the object is not readable, yet allows children to be created.  (This is usually an error.)  If the object is readable by the issuer of the @prospectus command (that is, publicly readable or owned by the issuer), then the number in brackets indicates the number of verbs which have been defined on this object (not including any verbs from any parents).

The third column indicates what type of object this is.
        T       Thing
        E       Exit
        R       Room
        C       Container
        N       Note
        P       Player
        p       Parent object appropriate for players ("Player class")
        blank   Other

===== help publish ======[EDITOR]===============================================

Syntax:  pub*lish

By default, only you (and wizards) can read the text you are editing.
This command makes your text readable by the entire world (see `help view').
This is useful if you need help from someone or if you just want to show off your programming acumen.
Use `unpublish' to make your text private again.

===== help put ======[GENERAL]==============================================

Syntax:  put <object> into <container>
         insert <object> in <container>

Moves the named object into the named container.  Sometimes the owners of the object and/or the container will not allow you to do this.

===== help quit ======[EDITOR]===============================================

Syntax:  q*uit
         done
         pause  

(EDITOR)
Leaves the editor.  If you have unsaved text it will be there when you return (and in fact you will not be able to do anything else with this editor until you 'abort' or save the text).


===== help @quit ======[GENERAL]==============================================

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

===== help @quota ======[GENERAL]==============================================
SEE common_quota

To get a larger quota, talk to a wizard.  They will take a look at what you've done with the objects you've built so far and make a determination about whether or not it would be a net gain for the MOO community if you were to build some more things.  If so, they will increase your quota; if not, they will try to explain some ways in which you could build things that were more useful, entertaining, or otherwise interesting to other players.  Wizards may be more impressed by objects which are interactive and employ a fair number of verbs.

===== help @quota ======[LAMBDA]===============================================
(continued from help common_quota)
*subst*

To get a larger quota, you need to talk to some member of the Architecture Review Board.  They will take a look at what you've done with the objects you've built so far and decide whether or not they think it would be a net gain for the LambdaMOO community if you were to build some more things.

If so, they will take your case to the rest of the Board; some other members will also look and, if there's sufficient positive feeling, some wizard will increase your quota.  If not, they will try to explain some ways in which you could build things that were more useful, entertaining, or otherwise interesting to other players.  See `help quota-policy' for a statement of what board members are looking for in new building.

Here is a current list of the membership of the Architecture Review Board:

%;#1000:memberlist()

You can use the @arb command to find out which members of the board are logged on.

===== help @quota ======[WIZARD]===============================================
(continued)
 - - - - - - - - - - - - - - - - - - - - - - - - - -
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.

===== help quota-advice ======[LAMBDA]===============================================

The following was posted to *arb as a more comprehensive explanation of the reasoning behind how the ARB makes decisions, and advice on preparing a request for more quota.
-----
     Step one in getting more quota is to explain in detail what you've done already.

     The easier you make it for the ARB members to make up their minds (by giving them information that is easy to assimilate and understand) the quicker they can come to a decision.  If you make it hard for them to come to a decision, they'll just get lazy and you'll never get the votes.  This may seem somewhat wrong, but looking at it from their point of view, YOU know your creations in intimate detail, so why should they try to puzzle out what you've done by looking at the code?

       Let me give you a quick brief on how the whole quota policy thang works. The basic reason behind quota is that if we let anybody make as much stuff as they like, the database would soon take up gigabytes.  So everybody is started off with a set amount of quota.

       Now, the reasoning behind the ARB:  players will often make objects that make the whole MOO more fun for everybody.  However, this takes up space in their quota, so if they want to make something more, they eventually run out of quota.  Now... rather than have players recycle things that make the whole MOO more fun for everybody, the ARB was set up to handle giving these players more quota.  

      The ARB is NOT empowered to pass judgement on your plans for the future - that would amount to censorship and/or creative control over the players' efforts.  They only decide if what you've done so far is good enough that you should be given extra quota to play around with.

     The criteria the ARB uses to judge how "fun" an object is available in "help quota-policy", but a basic summary is:

      1)  Finish the projects you start.
      2)  Create objects with the public in mind.
      3)  Avoid TinyScenery.
      4)  Be original.
      5)  Don't violate the LambdaMOO theme.
      6)  Don't violate 'help manners'.

     The first one is pretty obvious, and it relates back to that whole censorship thing I mentioned.  The second one is also obvious, if you think about it - if it's private, it's not going to be much fun for the  MOO overall. The tinyscenery issue has been the source of flamage in the past, but it basically boils down to, don't create things and rooms and exits which exist primarily, or solely, for the sake of being pretty.   Be original is also fairly obvious - this doesn't mean you can't do something somebody else has already done, but make it better, more efficient,  or in some way different. Help manners is also obvious.

     The theme issue can be tricky.  Not everybody agrees on what the theme means, and some people interpret it more strictly than others. For the most part, if you try to make your creations fit within the LambdaMOO environment well enough to avoid jarring people's willing suspension of disbelief (which is what makes all of this fun), you'll pass on this.

     So, your best bet is to examine your creations, particularly new and interesting verbs, devices, etc, and then write up an explanation of what you've done, orienting it so you stress the "fun" things you've done.  Then send that to an ARBer - they're mostly pretty good people, so choose one you have had a chance to meet, or choose one who's online and go talk to him or her.  The ARBer should forward your request to the ARB mailing list.

Puff
 

===== help quota-policy ======[LAMBDA]===============================================

  The quota policy is still being reviewed by the Architecture Review Board.  This document is what they are currently working with, and you can expect that the final policy will be somehow related to this.  If you have any comments or questions, feel free to direct them to any member of the ARB.  (See `help @quota' for a list.)  Thanks!
  [Aside:  The purpose of quota is to encourage quality building.  The use of multiple characters for the explicit purpose of building despite being denied a quota increase (or not having asked for such an increase) by the ARB is considered improper.  See help multiple-characters for further details.]

------------------------------------------------------------------
Summary:
     1)  Finish the projects you start.
     2)  Create objects with the public in mind.
     3)  Avoid TinyScenery.
     4)  Be original.
     5)  Don't violate the LambdaMOO theme.
     6)  Don't violate 'help manners'.
------------------------------------------------------------------
     1)  Finish the projects you start.  If you decide to abandon a project,
do so completely, reusing the objects committed to that project.  If you come
to the ARB while you still have half-finished objects, the ARB will strongly
suggest to you that you finish them or reuse them before getting more quota.
     2)  Create and program with the MOO public in mind.  Objects that are
only usable by you, or are only useful by you, will not make brownie points
with the ARB.  Objects that any MOOer can use and have fun with will make
brownie points.  If you design generic objects that are useful to many 
other people, document these objects well; that way, other people can
benefit from your efforts and understand your objects thoroughly.
     3)  Avoid TinyScenery.  Objects that only have a description will not
impress the ARB; objects that have interesting and useful behavior will 
impress the ARB.  One of the most wonderful features of LambdaMOO is the
great freedom which programming provides.  To ignore that freedom and create
objects that look pretty but don't do anything is a waste.
     4)  Be original.  Don't merely clone generic objects for every object
you use within a project.  If you use generic objects, try to use them in an
original way.  Where possible/applicable, customize your copies of generic 
objects by adding behavior that the generics themselves do not have.  Keep
in mind the recommended 1:1 verb:object ratio.
     5)  Don't violate the LambdaMOO theme.  This MOO has a very definite and
well-defined theme; the theme is described in 'help LambdaMOO.'  The creators
of LambdaMOO would like to see that all new building holds to this theme; for
this reason, the ARB will be consdering the 'themeliness' of any building you
do.  So stick with the theme, and think of ideas that would fit well within
a large, sprawling mansion like this one.
     6)  Follow 'help manners.'  Don't create objects that will offend
people.  The users of this MOO come from a wide variety of backgrounds and
areas; what is commonplace to you may well be quite offensive to others.
Respect the privacy and property of others; don't create objects which allow
you to spy on people, for example. 
------------------------------------------------------------------

===== help quota-requests ======[LAMBDA]===============================================

INSTRUCTIONS FOR SUBMITTING A QUOTA INCREASE APPLICATION
--------------------------------------------------------
Before applying for quota, you should read the text contained in `help quota-policy' and you should consider whether your building fits the expectations detailed within. It might also be a worthwhile idea to speak with a member of the Architecture Review Board personally, to discuss your proposal.

The first thing you want to do is to grab a scrap of paper to write your note on. Check out the pad outside the Star Chamber (in #19808), and take a sheet from it:
  get paper from pad
... and you will get your very own note, which you can describe, rename, write on, edit, whatever, for a period of one full day. (You may well want to rename it; the default name is kinda big, although it's got a few usable aliases.) If you haven't trashed it or slipped it under the door after the end of that day, the text will be mailed to you and the note will be destroyed.

Edit the note however you please. Describe it, for the basic description is quite dull. (The real reason for this requirement is that the description of the note will be subject of your message.) It might be a good idea, in the body of your application, to include a summary of your present ownership as well as a brief bit on what you intend to do in future.

If you decide you don't want to use this note any longer, you can throw it in the wastebasket (also in the hallway outside the Star Chamber):
  throw <note> in trash

If you decide that you -do- want to submit this note to the ARB, just slip it under the door to the Star Chamber:
  slip <note> under door
... and it will be delivered to the Architecture Review Board promptly. A copy will also be mailed to you, for your records. You should receive feedback relatively quickly; feel free to page any ARB member (see `help @arb' for how to find them) and ask the status of your request. If you haven't heard anything, slip another note under the door and ask what's up.

(One word of advice -- be patient. The ARB members are not on the MOO for the sole purpose of doling out quota, and at times they like to have fun. Sometimes they have bad days. If you run into someone who isn't interested in helping at the time, just ask someone else or wait a little while longer.)

===== help ranges ======[EDITOR]===============================================

Most editor commands act upon a particular range of lines.
Essentially, one needs to specify a first line and a last line.
Line numbers may be given in any of the following forms
  
  n      (i.e., the nth line of text)
  n^     n-th line after/below  the current insertion point
  n_     n-th line before/above the current insertion point
  n$     n-th line before the end.

In the latter three, n defaults to 1, so that `^' by itself refers to the line below the current (i.e., the line that gets `^' printed before it), and likewise for `_' while `$' refers to the last line.  Note that the usage depends on whether you are specifying a line or an insertion point (space between lines). `^5' is the space above/before line 5, while `5^' is the fifth line after/below the current insertion point.

Ranges of lines may be specified in any of the
following ways:

  <line>                  just that line
  from <line> to <line>   what it says; the following two forms are equivalent:
  <line>-<line>            
  <line> <line>

With the `from l to l' form, either the from or the to can be left off and it will default to whatever is usual for that command (usually a line above or below the insertion point).  Actually I was thinking of punting the `from'/`to' specifications entirely because they're so verbose.  Opinions?

===== help read ======[GENERAL]==============================================

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.

===== help @read ======[GENERAL]==============================================

Syntax:  @read <message-number>
         @read
         @peek ...

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'.
As with the @mail command you may @read messages on any publically readable collection (child of $mail_recipient).

The @peek command is a variant of @read that works no differently except that it refrains from setting your `current message'.  This is useful, for example, if you want to see some particular message on a collection without losing track of where you are in it.

===== help @realm ======[GENERAL]==============================================

Syntax: @realm [owners] [from root] [missing descendants]

Displays a part of the parenting tree of objects on the MOO, i.e. all
the descendants of a given object owned by particular players.

owners:      a list of players whose objects you are interested in. If
             one of these is * or !, @realm will display objects only if
             they belong to players you didn't mention. (defaults to you)
root:        the object which is an ancestor of all the objects you are
             interested in. (defaults to $root_class).
descendants: a list of objects (descendants of root) which you are not
             interested in. Neither they nor their descendants will be
             displayed.

@realm also displays the objects which are ancestors of root, and, if it
is not redundant, the owners of all objects. @realm has a habit of
running out of ticks if you try displaying large chunks of the MOO.

===== help receiving-mail ======[CORE]=================================================

Receiving Mail
--------------
By definition a recipient "receives" a mail message when its :receive_message verb is called with that message as an argument.

:new_message_num()
=> number that will be assigned to the next incoming message.
By default this returns the maximum of the message numbers appearing in 
messages or .messages_going, incremented by 1.  If the recipient is a player
then the value returned will be 1 higher if it conflicts with the player's 
current message number for him/herself.

:receive_message(msg,sender)
By default this first calls this:new_message_num to obtain a message number to assign to the incoming message and then appends {num,msg} to this.messages.  
`sender', the original sender, is supplied in case one wants different 
action depending on who is sending the message (e.g., mail-gagging).
The return value should be an error or string if :receive_message is considered to have failed in some way.  Otherwise, a number should be returned --- this number is given to any :notify_mail routines that are called and is expected to either be 0 or the number assigned to the incoming message.

Note that :receive_message can do arbitrary things, including resending the same message to a new destination.  Hacking :receive_message to resend messages is different from using .mail_forward in the following respects
  (1) the resent message is considered to be a distinct message having this 
      object as its "author" --- i.e., the From: line will necessarily be 
      different.
  (2) since this "forwarding" is invisible to the mailsystem, 
      there is no protection against loops and multiple copies.


===== help @recreate ======[GENERAL]==============================================

Usage: @recreate <object> as <parent> named <name spec>

This is a combination of @create and @chparent.  It takes an existing object, completely strips it of any verbs, properties, and values for inherited properties.  This object is then reshaped into a child of the parent specified, as though @create had been called, but retaining the same object number as the original.

The <parent> and <name spec> arguments are as in @create.

===== help @recycle ======[GENERAL]==============================================

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

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

===== help @recycle ======[WIZARD]===============================================
(continued)
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.

===== help recycle() ======[LAMBDA-PROG]==========================================
(continued from programmers' manual help)
 - - - -
On LambdaMOO, in the vast majority of situations, $recycler:_recycle is more appropriate. With the same syntax as the server builtin, $recycler:_recycle(object) has the advantage of -not- destroying the object utterly and irrevocably. Similarly, in player verbs, you may want to use player:_recycle(object), which will serve the same function, with a slight change to take into account whether the player is using the recycler.

When one calls $recycler:_recycle(object), and one has permission to recycle said object, ownership of the object is taken from its previous owner and changed to Hacker (with a corresponding change in the former owner's .ownership_quota and .owned_objects), the object's :recycle verb is called, it's stripped of verbs and properties and chparent()'d to $garbage and stored in the $recycler for use by another player later.

When one calls player:_recycle, the value of the player's .recreate_enabled property is checked; if this value is one, as is the default, the recycler will be used. If not, the server builtins will be used, and objects that player recycles will be recycled forever.

===== help $recycler ======[CORE]=================================================

$recycler
---------
Rather than having the server built-in recycle() and create() functions handle the creation and destruction of objects, a recycling center has been created to simulate these actions by  changing objects that would have been recycled into children of $garbage (The Generic Garbage Object) and making them owned by Hacker, and then when they're needed again, to avoid a raw create() command, those objects are given to whoever's asking for them.

Most Useful Verbs
-----------------
$recycler:_recycle( object )
  This will effectively recycle an object. (As a point of fact, it changes ownership of the object to Hacker and makes the object a child of $garbage.)  It handles .ownership_quota and .owned_objects properly.  Generally, use this instead of a recycle() in your verbs.

$recycler:_create( parent object [ , new owner object ] )
  This effectively creates an object (with the specified parent, if possible, and with the specified owner, if possible; these are the same restrictions as on the server create() builtin).  This is what should generally be used instead of create() in your programming.

$recycler:valid ( object )
  This is a variant of the server built-in valid() except that it handles the $garbage objects as well.  It returns a 1 if the object specified -is- valid and is -not- a $garbage object.

Other Notes
-----------

request <object> from <recycler>
  This is not an internal verb (it's !x).  It is, however, a command-line verb that can be used to request a specific object from the recycler.  It's also useful for the creation of objects like a Magic Number Repository.  When the object is removed from the recycler, the .announce_removal_msg is announced to the room if it's set (it's piped through $string_utils for pronoun substitution).

show-history <recycler>
  This is a wizardly verb which allows wizards to check the `history list' of the recycler. The history maintains the latest ($recycler.nhist) entries.

$recycler.orphans
  This maintains a list of objects for which the recreation process got mangled. It ought to be checked every once in a while to see what's up.

===== help redlist ======[WIZARD]===============================================
SEE blacklist

===== help @redlist ======[WIZARD]===============================================
SEE @blacklist

===== help @refusal-reporting ======[LAMBDA]===============================================

[See help @refuse for a discussion of the refusal facility]

    @refusals
    @refusals for <player>

List the players and actions you are refusing, or the players and actions that another player is refusing. For example, you can see if
Stupid_Jerk is refusing your mail too: '@refusals for Stupid_Jerk'.

Normally refusal works without your awareness. You don't even notice when Stupid_Jerk attempts to send you mail. If you would rather be
notified when it happens (so you can thumb your nose), then do

    @refusal-reporting on

Actually, all you need to type is '@refusal-r on'. You will see a message like 'Mail from Stupid_Jerk (#34567) refused.' as soon as
Stupid_Jerk types 'send' in the mail editor.

Refusal reporting only works for some actions. It works for page, whisper, and mail, but not for move, join or accept. Sorry.

You will only be notified if you are connected when the refusal happens. If you are not connected when Stupid_Jerk tries to send you mail,
you won't know about it, no matter whether refusal reporting is on or off.

You can turn off refusal reporting with '@refusal-r off'. You can check whether it is on or off with '@refusal-r'. Here's the list:

    @refusal-reporting on     - turn on refusal reporting
    @refusal-reporting off    - turn off refusal reporting
    @refusal-reporting        - see whether it is on or off

===== help @refuse ======[LAMBDA]===============================================


The refusal facility allows you to ignore specific actions by players. You can ignore all mail that Stupid_Jerk (#34567) sends you, for
example, or you can ignore all whispers and pages, no matter who they are from.

There are three basic refusal commands. They are explained below.

    @refuse <action> from <player>
    @unrefuse <action> from <player>
    @refusals

The actions you can refuse are page, whisper, mail, move, join, and accept. These are explained in a table farther down.

For example, '@refuse mail from Stupid_Jerk'. Any future mail that Stupid_Jerk sends you will be dropped on the floor, and Stupid_Jerk will
be told that you refused to receive it. The refusal stays active for a week; after the week is over, Stupid_Jerk's mail will again get
through. (If you want the refusal to last a longer or shorter time, keep on reading.)

You can refuse more than one action at a time. '@refuse page whisper from Stupid_Jerk' refuses both pages and whispers.

You can also refuse actions from everybody.

    @refuse <actions>

For example, '@refuse page' refuses every page. These refusals are listed as refusals of 'everybody' when you use the @refusals command,
below.

See `help @unrefuse' and `help @refusal-reporting' for information on undoing refusals and finding out what you're refusing.

 - the actions

The actions everybody can refuse are page, whisper, mail, move, and join.
refuse other things as well, depending on your player class.

 refuse this      to prevent somebody from doing this
 -----------      -----------------------------------
    page        - tell you a message with the 'page' command
    whisper     - tell you a message with the 'whisper' or 'murmur' command
    mail        - send you a MOOmail message via @send
    move        - teleport you
    join        - enter the same room as you (only works in a some rooms)
    accept      - hand you an object (or teleport it to you)
    all         - all of the above

Refusing move is a little tricky. The player will not be able to teleport you, but you will not be able to pass through any special exits
that the player may have programmed either. Refusing move means refusing *all* movement, including movement through programmed exits.
Fortunately most exits are plain exits, and you will always be able to pass through them. Only specially programmed exits by the player you
are refusing move from are barred to you.

Refusing join only works in special rooms that support it.

 - time limits

Refusals expire after a certain amount of time has gone by. Unless you say otherwise, they expire after a week. You can add '... for
<time>' to the end of a @refuse command:

    @refuse <action> from <player> for <time>
    @refuse <action> for <time>

For example, '@refuse join from Stupid_Jerk for 3 days'.

The <time> is always a number followed by a unit, like '10 weeks' or '45 seconds'. The possible units are second, minute, hour, day, week,
and month.

===== help registration ======[LAMBDA]===============================================
*subst*
%[$login:registration_string()]

===== help regular-expressions ======[PROGRAMMER]===========================================

Regular expression matching allows you to test whether a string fits into a specific syntactic shape.  You can also search a string for a substring that fits a pattern.

A regular expression describes a set of strings.  The simplest case is one that describes a particular string; for example, the string `foo' when regarded as a regular expression matches `foo' and nothing else.  Nontrivial regular expressions use certain special constructs so that they can match more than one string.  For example, the regular expression `foo%|bar' matches either the string `foo' or the string `bar'; the regular expression `c[ad]*r' matches any of the strings `cr', `car', `cdr', `caar', `cadddar' and all other such strings with any number of `a''s and `d''s.

Regular expressions have a syntax in which a few characters are special constructs and the rest are "ordinary".  An ordinary character is a simple regular expression that matches that character and nothing else.  The special characters are `$', `^', `.', `*', `+', `?', `[', `]' and `%'.  Any other character appearing in a regular expression is ordinary, unless a `%' precedes it.

For example, `f' is not a special character, so it is ordinary, and therefore `f' is a regular expression that matches the string `f' and no other string.  (It does *not*, for example, match the string `ff'.)  Likewise, `o' is a regular expression that matches only `o'.

Any two regular expressions A and B can be concatenated.  The result is a regular expression which matches a string if A matches some amount of the beginning of that string and B matches the rest of the string.

As a simple example, we can concatenate the regular expressions `f' and `o' to get the regular expression `fo', which matches only the string `fo'.  Still trivial.

The following are the characters and character sequences that have special meaning within regular expressions.  Any character not mentioned here is not special; it stands for exactly itself for the purposes of searching and matching.

`.'  is a special character that matches any single character.  Using
     concatenation, we can make regular expressions like `a.b', which matches
     any three-character string that begins with `a' and ends with `b'.

`*'  is not a construct by itself; it is a suffix that means that the preceding
     regular expression is to be repeated as many times as possible.  In `fo*',
     the `*' applies to the `o', so `fo*' matches `f' followed by any number of
     `o''s.

     The case of zero `o''s is allowed: `fo*' does match `f'.

     `*' always applies to the *smallest* possible preceding expression.  Thus,
     `fo*' has a repeating `o', not a repeating `fo'.

     The matcher processes a `*' construct by matching, immediately, as many
     repetitions as can be found.  Then it continues with the rest of the
     pattern.  If that fails, it backtracks, discarding some of the matches of
     the `*''d construct in case that makes it possible to match the rest of
     the pattern.  For example, matching `c[ad]*ar' against the string
     `caddaar', the `[ad]*' first matches `addaa', but this does not allow the
     next `a' in the pattern to match.  So the last of the matches of `[ad]' is
     undone and the following `a' is tried again.  Now it succeeds.

`+'  is like `*' except that at least one match for the preceding pattern is
     required for `+'.  Thus, `c[ad]+r' does not match `cr' but does match
     anything else that `c[ad]*r' would match.

`?'  is like `*' except that it allows either zero or one match for the
     preceding pattern.  Thus, `c[ad]?r' matches `cr' or `car' or `cdr', and
     nothing else.

`[ ... ]'
     `[' begins a "character set", which is terminated by a `]'.  In the
     simplest case, the characters between the two brackets form the set.
     Thus, `[ad]' matches either `a' or `d', and `[ad]*' matches any string of
     `a''s and `d''s (including the empty string), from which it follows that
     `c[ad]*r' matches `car', etc.

     Character ranges can also be included in a character set, by writing two
     characters with a `-' between them.  Thus, `[a-z]' matches any lower-case
     letter.  Ranges may be intermixed freely with individual characters, as in
     `[a-z$%.]', which matches any lower case letter or `$', `%' or period.

     Note that the usual special characters are not special any more inside a
     character set.  A completely different set of special characters exists
     inside character sets: `]', `-' and `^'.

     To include a `]' in a character set, you must make it the first character.
     For example, `[]a]' matches `]' or `a'.  To include a `-', you must use it
     in a context where it cannot possibly indicate a range: that is, as the
     first character, or immediately after a range.

`[^ ... ]'
     `[^' begins a "complement character set", which matches any character
     except the ones specified.  Thus, `[^a-z0-9A-Z]' matches all characters
     *except* letters and digits.

     `^' is not special in a character set unless it is the first character.
     The character following the `^' is treated as if it were first (it may be
     a `-' or a `]').

`^'  is a special character that matches the empty string -- but only if at the
     beginning of the string being matched.  Otherwise it fails to match
     anything.  Thus, `^foo' matches a `foo' which occurs at the beginning of
     the string.

`$'  is similar to `^' but matches only at the *end* of the string.  Thus,
     `xx*$' matches a string of one or more `x''s at the end of the string.

`%'  has two functions: it quotes the above special characters (including `%'),
     and it introduces additional special constructs.

     Because `%' quotes special characters, `%$' is a regular expression that
     matches only `$', and `%[' is a regular expression that matches only `[',
     and so on.

     For the most part, `%' followed by any character matches only that
     character.  However, there are several exceptions: characters that, when
     preceded by `%', are special constructs.  Such characters are always
     ordinary when encountered on their own.

     No new special characters will ever be defined.  All extensions to the
     regular expression syntax are made by defining new two-character
     constructs that begin with `%'.

`%|' specifies an alternative.  Two regular expressions A and B with `%|' in
     between form an expression that matches anything that either A or B will
     match.

     Thus, `foo%|bar' matches either `foo' or `bar' but no other string.

     `%|' applies to the largest possible surrounding expressions.  Only a
     surrounding `%( ... %)' grouping can limit the grouping power of `%|'.

     Full backtracking capability exists for when multiple `%|''s are used.

`%( ... %)'
     is a grouping construct that serves three purposes:

       1. To enclose a set of `%|' alternatives for other operations.  Thus,
          `%(foo%|bar%)x' matches either `foox' or `barx'.

       2. To enclose a complicated expression for a following `*', `+', or `?'
          to operate on.  Thus, `ba%(na%)*' matches `bananana', etc., with any
          number of `na''s, including none.

       3. To mark a matched substring for future reference.

     This last application is not a consequence of the idea of a parenthetical
     grouping; it is a separate feature that happens to be assigned as a second
     meaning to the same `%( ... %)' construct because there is no conflict in
     practice between the two meanings.  Here is an explanation of this
     feature:

`%DIGIT'
     After the end of a `%( ... %)' construct, the matcher remembers the
     beginning and end of the text matched by that construct.  Then, later on
     in the regular expression, you can use `%' followed by DIGIT to mean
     "match the same text matched by the DIGIT'th `%( ... %)' construct in the
     pattern."  The `%( ... %)' constructs are numbered in the order that their
     `%(''s appear in the pattern.

     The strings matching the first nine `%( ... %)' constructs appearing in a
     regular expression are assigned numbers 1 through 9 in order of their
     beginnings.  `%1' through `%9' may be used to refer to the text matched by
     the corresponding `%( ... %)' construct.

     For example, `%(.*%)%1' matches any string that is composed of two
     identical halves.  The `%(.*%)' matches the first half, which may be
     anything, but the `%1' that follows must match the same exact text.

`%b' matches the empty string, but only if it is at the beginning or end of a
     word.  Thus, `%bfoo%b' matches any occurrence of `foo' as a separate word.
     `%bball%(s%|%)%b' matches `ball' or `balls' as a separate word.

     For the purposes of this construct and the five that follow, a word is
     defined to be a sequence of letters and/or digits.

`%B' matches the empty string, provided it is *not* at the beginning or end of
     a word.

`%<' matches the empty string, but only if it is at the beginning of a word.

`%>' matches the empty string, but only if it is at the end of a word.

`%w' matches any word-constituent character (i.e., any letter or digit).

`%W' matches any character that is not a word constituent.

===== help remove ======[GENERAL]==============================================
SEE take

===== help @remove-entrance ======[GENERAL]==============================================

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.

===== help @remove-exit ======[GENERAL]==============================================

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.

===== help @remove-feature ======[GENERAL]==============================================
SEE @add-feature

===== help @remove-feature ======[PROGRAMMER]===========================================
SEE @add-feature

===== help @rename ======[GENERAL]==============================================

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.

Note that for renaming players, more stringent rules apply.  See `help player-names'.  Certain other kinds of objects (e.g., mail recipients) also enforce their own rules w.r.t what they can be named.

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.

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.

===== help @renumber ======[GENERAL]==============================================

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'), these will be expunged.

===== help @reply ======[GENERAL]==============================================
SEE @answer

===== help reply-to ======[EDITOR]===============================================

Syntax:  reply-to [<recipients>]

(MAIL ROOM)
Reports the current contents of the Reply-to: field of your message.
With arguments, adds (or changes) the Reply-to: field.

When someone @answers a message, the Reply-to: field is checked first when determining to whom the reply should be sent --- see `help @answer'.

To clear the Reply-to: field, do

         reply-to ""

===== help @request-character ======[GENERAL]==============================================

Usage:  @request <player-name> for <email-address>

This command available to Guest characters only.

The @request command requests a new character, registered for your email address. Please use your primary address for this, as your password will be sent to the address provided.

===== help @request-character ======[LAMBDA]===============================================
(continued)
Generally, only one character per person, please. Please read `help multiple-characters' for the full policy.

===== help @resident ======[GENERAL]==============================================

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.

@resident player adds that player to the list.  
@resident !player removes that player from the list.
@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.

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.

===== help @rmalias ======[GENERAL]==============================================

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.

===== help @rmmail ======[GENERAL]==============================================

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-sequence' for the full list of possible arguments.
You get the message numbers for use here by typing the '@mail' command.

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

===== help @rmproperty ======[PROGRAMMER]===========================================

Syntax:  @rmproperty <object>.<prop-name>

Removes the named property from the named object.  '@rmproperty' may be abbreviated as '@rmprop'.

===== help @rmroom ======[LAMBDA]===============================================
SEE @rooms

===== help @rmverb ======[PROGRAMMER]===========================================

Syntax:  @rmverb <object>:<verb-name>
         @rmverb <object>:<verb-name>  <dobj> <prep> <iobj>

Removes the named verb from the named object.
If there is more than one verb matching the given verb-name, this removes the most recently defined one.

With the 2nd form of the command the verb removed is the most recent one matching both the given verb-name *and* the given dobj/prep/iobj specifiers.

===== help @rmword ======[LAMBDA]===============================================

Usage: @rmword <word or words>

Will remove all words found from your personal dictionary, stored in player property ".dict".

===== help @rn ======[GENERAL]==============================================

Syntax:  @rn

For each collection of mail messages that you read other from your own, a last-read-time is kept.  This 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.

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

===== help $room ======[CORE]=================================================

The Generic Room ($room)
----------------

(1)  Announcements

:announce         (@text)         => broadcasts to all except player
:announce_all     (@text)         => broadcasts to all
:announce_all_but (objects,@text) => broadcasts to all except those in objects

say, emote


(2)  Command recovery

:huh            (verb,args) - server hook: last chance to make sense of verb
:here_huh       (verb,args) - room's last attempt to parse something
:here_explain_syntax (this,verb,args) - attempts to explain usage of verb


(3)  Residency

free_home  - true => @sethome allows anyone to set his .home to be here
residents  - objects on this list may teleport in and/or set their homes here.

:accept_for_abode(player) 
            => true iff player should be allowed to set .home to this room.

@resident*s


(4)  Looking

dark  - true => contents are not visible
ctype - 1..4 for four different styles of .contents lists

:match         (string)        => exit or object in room's .contents
:tell_contents (objects,ctype) - format objects according to ctype, tell player

l*ook


(5)  Topology and Movement via Exits

See `help $exit' for an explanation of how the generic $exit works.

free_entry     - true  => `teleporting' in is allowed
                  false => only residents may teleport in
exits          - list of invokable exits leading from this room
entrances      - list of recognized exits leading to this room
blessed_object - object currently entering via an exit
blessed_task   - task_id for entering object

:match_exit      (string) => exit whose name matches string
:bless_for_entry (object) - set up room to accept object arriving from entrance
:add_exit        (exit)
:add_entrance    (exit)
:remove_exit     (exit)
:remove_entrance (exit)

e/east/w/west/s/south/n/north/ne/northeast/nw/northwest/se/southeast/sw/southwest/u/up/d/down, go, @add-exit, @add-entrance, @remove-exit, @remove-entrance, @exits, @entrances 


(6)  Ejection

victim_ejection_msg/oejection_msg/ejection_msg
:*_msg()  messages

@eject


===== help room-messages ======[GENERAL]==============================================
*subst*
A few different messages can be set on a room object (see 'help messages' 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'.)  The standard pronoun substitutions are made on each message before it is printed; see 'help pronouns' for details.

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

@ejection  [%[$room.ejection_msg]]
  Printed to the player doing the ejecting.

@victim_ejection  [%[$room.victim_ejection_msg]]
  Printed to the object being ejected.

@oejection  [%[$room.oejection_msg]]
  Printed to others in the room from which the object is being ejected.

===== help rooms ======[GENERAL]==============================================

Rooms may be made by builders, using the DIG verb. By default, all rooms are instances of _the_ room, $room, or #3, which you can examine to see how it works. If you require a room to have a more specific behaviour, you can make a subclass of room.

===== help @rooms ======[LAMBDA]===============================================

When you aren't in the same room with an object, you have to refer to it by number. When teleporting, that means you usually have to give your destination as a number. To avoid this, Frand's player class provides a way for you to store a database of rooms by name. If the library is in your list of rooms, you can just '@go library' to teleport there. Or '@move book to lib' to teleport an object there.

  @rooms                     - see a list of the rooms you know by name
  @addr*oom <name> <number>  - remember a room by name
  @rmr*oom  <name>           - forget about a room's name

For example, to add the kitchen to your database of rooms, type '@addr Kitchen #24'. To remove it, type '@rmr kitchen'.

===== help rpg ======[LAMBDA]===============================================
*subst*
LambdaMOO's RPG is documented in various and sundry forms around the MOO.
If you wish to know about playing, we suggest reading the messages on
*RPG-Suggestions, the mailing list for RPG players, and the fridge notes
in the kitchen for some announcements about new areas.
The RPG help object is #17223, typing help rpg-index will generally
get you a list of RPG programing topics.
These people (among others) may be able to help you with any remaining
questions you may have:

%;#46:gmlist()

You can use the @gms command to find out which game-masters are logged in.

===== help save ======[EDITOR]===============================================

Syntax:  save [<note-object>]
         save [<object>.<property>]

(NOTE EDITOR)
Installs the freshly edited text.  If <note> or <object>.<property> is specified, text is installed on that note or property instead of the original one.  In addition the new note or property becomes the default for future save commands.

===== help say ======[GENERAL]==============================================

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

===== help say ======[EDITOR]===============================================

Syntax: say <text>
        "<text>

(EDITOR)
Adds <text> to whatever you are editing.
The second form is equivalent to the first except in that it doesn't strip leading blanks off of <text> (just as with the normal `say' and `"' commands).

The added text appears as a new line at the insertion point.  The insertion point, in turn, gets moved so as to be after the added text.  For example:

    >"first line
    Line 1 added.
    >"  second line"
    Line 2 added.
    >list
      1: first line
    __2_   second line"
    ^^^^

===== help security ======[GENERAL]==============================================

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 -- keeping a record of messages your character hears.
@check    -- looking at that record to determine responsibility for messages.
@sweep    -- checking who is listening in on your conversation.

===== help send ======[EDITOR]===============================================

Syntax:  send

(MAIL ROOM)
Send your message and exit the mail room.
If there are bogus addresses on your To: line, the message will not be sent.
It may be, however, that valid addresses on your To: line will forward to other addresses that are bogus; you'll receive warnings about these, but in this case your message will still be delivered to those addresses that are valid.

===== help @send ======[GENERAL]==============================================

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

===== help sending-mail ======[CORE]=================================================

Sending Mail
------------
$mail_agent:send_message(from,recipients,headers,body)
  from:        sender of the message 
               (this must be you or something you own; otherwise => E_PERM)
  recipients:  object or list of objects (must all be players or 
               $mail_recipient descendants)
  headers:     either a string (contents of the Subject: line) 
               or a list {subject,replytos} replytos is a list 
               of objects designated to receive replies.
               Use {"",replytos} to have a Reply-to: without a Subject:

This is the canonical way to send a mail message from a program.
This calls $mail_agent:make_message to format the arguments into an actual message (see `help mail-format') and then $mail_agent:raw_send to do the actual sending which goes as follows:

  (1) Call :mail_forward on all recipients add any new recipients thus obtained to final recipient list, keep calling mail:forward on the new recipients until we obtain no additional recipients.  If one of the initial recipients is invalid, is not a player or $mail_recipient, or has its mail_forward return a string error, then we print the error message and abort at this point with no mail being sent.  If one of the later recipients bombs similarly, error messages are printed, but in this case mail still goes out to the other recipients.

  (2) Call :mail_notify on all recipients encountered in stage (1) to get a list of objects to notify.

  (3) All final recipients receive the message (see `help receive-mail')
  (4) All notifications are delivered (using :notify_mail())

We return {0, @failed_recipients} if we bombed out at step 1.
Otherwise return {1, @actual_rcpts} indicating what mail was sent.

===== help @set ======[GENERAL]==============================================
SEE @setprop
@set is a valid abbreviation for @setprop.

===== help @setenv ======[PROGRAMMER]===========================================

Syntax:  @setenv <environment string>

Defines the environment for eval (property player.eval_env).  See "help eval"
for more information.  This is mostly useful when one's .eval_env is broken
and prevents one from using eval to reset it.

===== help @sethome ======[GENERAL]==============================================

Syntax: @sethome

Sets your designated home (see `help home') to be the room you're in now.  If the current room wouldn't allow you to teleport in, then the `@sethome' command nicely refuses to set your home there.  This avoids later, perhaps unpleasant, surprises.  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.

===== help @setprop ======[GENERAL]==============================================

Syntax:  @set <object>.<prop-name> to <value>

Changes the value of the specified object's property to the given value.
You must have permission to modify the property, either because you own the property or if it is writable.

===== help @shout ======[WIZARD]===============================================

Syntax:  @shout <text>

Broadcasts the given text to all connected players.

===== help @show ======[PROGRAMMER]===========================================

Syntax:  @show <object>
         @show <object>.<prop-name>
         @show <object>:<verb-name>

Displays quite detailed information about an object, property or verb, including its name, owner, permission bits, etc.  The information displayed for an object can be quite long.

See also @display, which displays different information and is controlled differently.

===== help @shutdown ======[WIZARD]===============================================

Syntax:  @shutdown [in <m>] [<text>]

This is the friendly way to do a server shutdown; it arranges for the actual shutdown to take place `m' minutes hence (default two).  Shutdown is preceded by a sequence of warnings to all connected players.  Warnings are likewise given to all players who connect during this time.  <text>, if given is included in these warning messages, perhaps as an explanation for why the server is being shut down.

Shutdown may be aborted at any time by using @abort-shutdown.

===== help $site_db ======[WIZARD]===============================================

Database of places
------------------
i.e., places people have connected from.

  :add(sitename,player)
      records the fact that player connected from sitename.
  :load()
      clears the db and reloads all of the player connection info.

  .domain
      default domain for unqualified sitenames given to :add.
      
For each domain we keep a list of players and subdomains. 
For example, :add("doc.ic.ac.uk",#666) enters #666 on the lists for "doc.ic.ac.uk", and, if we have to create an entry for "doc.ic.ac.uk", we enter "doc" on the list for "ic.ac.uk", "ic" on the list for "ac.uk", etc....  In this case, :find("ic") will return the "ic.ac.uk" list if there is no other domain in $site_db starting with "ic".  Note that the "ic.ac.uk" list may contain both objects, i.e., namely players that have connected from the site "ic.ac.uk", and strings, i.e., subdomains of "ic.ac.uk" like "doc".

  :find_exact(string)    => player/subdomain list or $failed_match
  :find_all_keys(string) => list of all domains that begin with string
  :find_key     (string) => unique domain that begins with string, 
                            $ambiguous_match or $failed_match

The other $generic_db functions (:find, :find_all) are also available, though admittedly less useful.

===== help @skip ======[GENERAL]==============================================

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.

===== help @sort-owned ======[GENERAL]==============================================

Syntax:  @sort-owned

Sorts your .owned_objects property so @audit shows up sorted.  See help @audit for more information.

===== help @spell ======[LAMBDA]===============================================

Syntax: @spell <any number of words>
           - will check the words from the command line.
        @spell object.property
           - will spellcheck the contents of a prop. Must be a string or
             list of strings.
        @spell object:verb
           - will check everything within quoted strings in a verb. E.g.,
             only the quoted part of player:tell("Spellchecking is fun.");
             will be examined for errors.

Refer to Help Spelling for general information about the spell checker.

===== help spelling ======[LAMBDA]===============================================

The MOO has a built in spelling checker and dictionary.  There are several player commands which access the database, as well as some programming features available.  Additional documentation is available under individual commands.

The current dictionary only contains about 20,000 words, and thus is somewhat incomplete.  Words may be added to a personal dictionary, as well as to the main dictionary (only a few people can add to the main dictionary).

@spell a word or phrase - Spell check a word or phrase.
@spell thing.prop - Spell check a property. The value must be a string or a list of strings.
@spell thing:verb - Spell check a verb. Only the quoted strings in the verb are checked.
@spellproperties object - Spell check all text properties of an object.
@spellmessages object - Spell check only message properties of an object.
@cspell word - Spell check a word, and if it is not in the dictionary, offers suggestions about what the right spelling might be. This actually works with thing.prop and thing:verb too, but it is too slow to be useful--it takes maybe 30 seconds per unknown word.
@complete prefix - List all the word in the dictionary which begin with the given prefix. For example, '@complete zoo' lists zoo, zoologist, zoology, and zoom.
@addword word - Add a word to your personal dictionary.
@rmword word - Remove a word from your personal dictionary.
@adddict word - Add a word to the global dictionary.
@rmdict word - Remove a word from the global dictionary.

For programmers, the verb $spell:random() is available -- returns a word, at random, from the dictionary.

Questions and comments should be directed to waffle on LambdaMOO.

===== help @spellmessages ======[LAMBDA]===============================================

Syntax: @spellproperties <object>
        @spellmessages <object>
These commands will spellcheck all properties or messages, respectively, on an object.  The object must be owned or readable by the user.  Messages and properties will be spellchecked if they contain a string or a list of strings; others will be ignored.

Refer to help spelling for general information about the spellchecker.

===== help @spellproperties ======[LAMBDA]===============================================
SEE @spellmessages

===== help spoofing ======[GENERAL]==============================================
SEE security

===== help statements ======[PROGRAMMER]===========================================

The following kinds of statements exist in the MOO programming language:

        ;
The null statement does nothing.

        expression ;
The expression statement evaluates the expression and then discards the value.

        IF ( expression ) statements ENDIF
        IF ( expression ) statements ELSE statements ENDIF
        IF ( expression )
          statements
        ELSEIF ( expression )
          statements
        ...
        ELSE
          statements
        ENDIF
The conditional statement evaluates each expression in turn and executes the statements associated with the first one to return a true value; the ELSE statements are executed if none of the expressions returns a true value.  There can be any number of ELSEIF clauses and the ELSE part is optional.  See 'help truth' for the definition of 'true value'.

        FOR name IN ( expression ) statements ENDFOR
The list iteration statement first evaluates the expression, which must return a list.  It then executes the statements once for each element of that list, each time with the named variable having the value of the corresponding list element.

        FOR name IN [ expression .. expression ] statements ENDFOR
The numeric iteration statement first evaluates the two expressions, both of which must return numbers; call those numbers N1 and N2, respectively.  The statements are then executed once for each integer I such that N1 <= I <= N2, in increasing order; each time, the named variable has the corresponding value of I.

        WHILE ( expression ) statements ENDWHILE
The indefinite iteration statement repeatedly evaluates the expression and, each time it returns a true value, executes the statements.  The loop stops the first time that the expression returns a false value.  The definitions of 'true' and 'false' values is in 'help truth'.

        RETURN ;
        RETURN expression ;
The return statement evalautes the expression, if any, and returns the resulting value (or 0 if there is no expression) to the verb that called the current one.  Execution of the current verb is immediately terminated.

        FORK ( expression ) statements ENDFORK
        FORK name ( expression ) statements ENDFORK
The fork statement first executes the expression, which must return a number; call that number N.  It then creates a new MOO task that will, after at least N seconds, execute the statements.  When the new task begins, all variables will have the values they had at the time the FORK statement was executed.  The task executing the FORK statement immediately continues execution.  If a variable name is given after the FORK keyword, then it is assigned the 'queue ID' of the newly-created task.  The value of this variable is visible both to the task executing the fork statement and to the statements in the newly-created task.  See 'help tasks' for more information about forked tasks.

===== help subject ======[EDITOR]===============================================

Syntax:  subj*ect [<text>]

(MAIL ROOM)
Specifies a Subject: line for your message.  If <text> is "", the Subject: line is removed.

===== help @subscribe ======[GENERAL]==============================================

Syntax:  @subscribe *<collection>
         @subscribe

The first form of this command does two things:

(1) it sets up a current message and a last-read-time for the given mail 
    collection so that when next you log in, 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>

(2) adds you to the .mail_notify list for that collection, so that you will
    be notified *immediately* whenever new mail is sent there.

You can only @subscribe to collections that are readable by you.
The second form of the command gives a list of collections available to 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...

===== help @subscribed ======[GENERAL]==============================================

Syntax: @subscribed

Like @rn, but shows you ALL mailing lists to which you are subscribed, even those which have new messages.

===== help subst ======[EDITOR]===============================================

Syntax:  s*ubst/<str1>/<str2>[/[g][c][<range>]]

Substitutes <str2> for <str1>, in all of the lines of <range>.
Any character (not just `/') may be used to delimit the strings. 
If <str1> is blank, <str2> is inserted at the beginning of the line.  
(For inserting a string at the end of a line use emote/:).

Normally, only one substitution is done per line in the specified range, but if the 'g' flag is given, *all* instances of <str1> are replaced.
The 'c' flag indicates that case is not significant when searching for substitution instances.
<range> defaults to the line *before* the insertion point.

You do *not* need a space between the verb and the delimeter before <str1>.
[Bug: If you omit the space and the first whitespace in <str1> is a run of more than one space, those spaces get treated as one.  Likewise, quotes and backslashes occuring in the first word of the command (i.e., the "verb") need to be escaped with `\'.  The fix on this will have to wait for a new command parser.]

===== help @suggest ======[GENERAL]==============================================
SEE @typo

===== help summary ======[GENERAL]==============================================

Help is available on the following general topics:

introduction -- what's going on here and some basic commands
index -- index into the help system

players -- setting characteristics of yourself
movement -- moving yourself between rooms
communication -- communicating with other players
manipulation -- moving or using other objects
miscellaneous -- commands that don't fit anywhere else

building -- extending the MOO
programming -- writing code in the MOO programming language
editors -- editing text and code in the MOO

@pagelength -- what to do if lines scroll off your screen too fast
@linelength -- what to do if lines are truncated
tinymud -- a list of equivalences between MOO and TinyMUD concepts/commands

===== help summary ======[LAMBDA]===============================================
(continued)
LambdaMOO -- the `theme' of LambdaMOO, what new building should be like
manners -- the commonly-accepted rules of behavior on this MUD
wizard-list -- current list of LambdaMOO wizards
defense -- how to protect yourself from nasty users

===== help summary ======[EDITOR]===============================================

You are inside an editor.  Do

look          -- for list of commands
what          -- to find out what you're editing.
list          -- to list out some portion of the text
say / emote   -- to add new text to whatever you're editing

help edit-index -- for a full list of editor help topics
help editors    -- for a general discussion about editors
help moo        -- for the general MOO help summary (i.e., what you get by 
                   typing `help' with no arguments from outside the editor).

===== help @sweep ======[GENERAL]==============================================

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 wizards, who presumably wouldn't stoop to bugging.

===== help take ======[GENERAL]==============================================

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') into your inventory.  As before, sometimes the owner of an object will not allow you to do this.

===== help tasks ======[PROGRAMMER]===========================================

A task is an execution of a MOO program.  There are five ways for tasks to be created in LambdaMOO:
   + Every time a player types a command, a task is created to execute that command; we call these 'command tasks'.
   + Whenever a player connects or disconnects from the MOO, the server starts a task to do whatever processing is necessary, such as printing out 'Munchkin has connected' to all of the players in the same room; these are called 'server tasks'.
   + The FORK statement in the programming language creates a task whose execution is delayed for at least some given number of seconds; these are 'forked tasks'.
   + The suspend() function suspends the execution of the current task.  A snapshot is taken of whole state of the execution, and the execution will be resumed later.  These are called `suspended tasks'.
   + The read() function also suspends the execution of the current task, in this case waiting for the player to type a line of input.  When the line is received, the task resumes with the read() function returning the input line as result.  These are called `reading tasks'.

The last three kinds of tasks above are collectively known as `queued tasks' or `waiting tasks', since they may not run immediately.

To prevent a maliciously- or incorrectly-written MOO program from running forever and monopolizing the server, limits are placed on the running time of every task.  One limit is that no task is allowed to run longer than 15 seconds; this limit is, in practice, never reached.  The reason is that there is a second limit on the number of operations a task may execute.

The server counts down 'ticks' as any task executes.  Roughly speaking, it counts one tick for every expression evaluation (other than variables and literals), one for every `if', `fork' or `return' statement, and one for every iteration of a loop.  If the count gets all the way down to zero, the task is immediately and unceremoniously aborted.  All tasks begin or resume with an store of 30,000 ticks; this is enough for almost all normal uses.

Because queued tasks may exist for long periods of time before they begin execution, there are commands to list the ones that you own and to kill them before they execute.  These commands are covered in the following help topics:

@forked -- listing the forked tasks that you own
@kill -- killing a particular forked task

===== help teleport-messages ======[LAMBDA]===============================================

Teleporting using @go, @move, or @join causes various messages to appear. The messages are defined on you as properties. Here are the messages, who sees them, and when.

 when you teleport -  yourself      a player        a thing

           you see -  self_port     player_port     thing_port
        others see -  oself_port    oplayer_port    othing_port
  destination sees -  self_arrive   player_arrive   thing_arrive
   teleportee sees -                victim_port     object_port

When you @join a player, your join message is printed to you.

You can set the messages with commands like '@oself_port me is "vanishes in a shimmering haze."', '@join me is "You visit %n."', and so on.

The messages to you are printed as they stand. The messages to others are printed after your name. If you set a message to "", the null string, nothing will print for that message. But if you have a non-empty message which does not include your name, then your name will be added in front of the message. You can use the usual pronoun substitutions, like '%n' to refer to the object you are teleporting. You can also use the special substitutions %<from room> and %<to room> to refer to the original and destination rooms for the teleport.

If you are leaving your name out of the messages, and relying on its being inserted automatically, you have to be careful about the substitutions you use. If Frand has an oself_port message "jumps to %<to room>.", for example, and Frand teleports to Frand's MOOhome, the message printed will be "jumps to Frand's MOOhome." My name is there, so it isn't added in. If you want to include your name as a substutition, the one to use is %t, 'this'. "%t jumps to %<to room>." will work.

===== help theme ======[LAMBDA]===============================================
SEE LambdaMOO

===== help thing-messages ======[GENERAL]==============================================
*subst*
Several kinds of messages can be set on 'things', objects that have $thing as an ancestor (see 'help messages' 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' for details.

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

@take_failed  [%[$thing.take_failed_msg]]
  Printed to a player who fails to take the object.

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

@take_succeeded  [%[$thing.take_succeeded_msg]]
  Printed to a player who succeeds in taking the object.

@otake_succeeded  [%[$thing.otake_succeeded_msg]]
  Printed to others in the same room if a player succeeds in taking the object.

@drop_failed  [%[$thing.drop_failed_msg]]
  Printed to a player who fails to drop the object.

@odrop_failed [%[$thing.odrop_failed_msg]]
  Printed to others in the same room if a player fails to drop the object.

@drop_succeeded  [%[$thing.drop_succeeded_msg]]
  Printed to a player who succeeds in dropping the object.

@odrop_succeeded  [%[$thing.odrop_succeeded_msg]]
  Printed to others in the room if a player succeeds in dropping the object.

===== help throw ======[GENERAL]==============================================
SEE drop

===== help tinymud ======[GENERAL]==============================================

This is yduJ's table of tinymud commands and their equivalents in LambdaMOO.  A longer document, with discussions of the different verbs and how they have changed, is available via FTP from parcftp.xerox.com as pub/MOO/contrib/TinyMUD-LambdaMOO-equivs.  All the commands mentioned here have help nodes on LambdaMOO.

The following commands are basically the same in MOO and MUD.

    drop(throw), get(take), go, help, home, inventory, look, news, say (",:)


The following commands have no equivalent:

    kill, rob, score, @force


The following commands have the same names and do similar things, but are changed in some way (both syntactic and semantic differences, sometimes quite substantial differences):

    @examine, give, page, read, whisper, @create, @dig,
    @lock, @password, @unlock, @describe


The following commands have rough equivalents in LambdaMOO but the name is different:

    TinyMUD name            LambdaMOO name
    ------------            --------------
    QUIT                    @quit
    gripe                   @gripe
    goto/move               go
    WHO                     @who
    @fail                   @take_failed, @nogo, @drop_failed
    @find                   @audit
    @link                   @dig, @sethome, @add-exit, @add-entrance
    @name                   @rename
    @ofail                  @otake_failed, @onogo, @odrop_failed
    @open                   @dig
    @osuccess               @oleave, @oarrive, @otake_succeeded, 
                            @odrop_succeeded
    @success                @leave, @arrive, @take_succeeded
                            @drop_succeeded
    @teleport               @move


Here are some commands for which no equivalent exists, or for which the equivalent is a complicated set of actions.

    @set, @stats, @unlink


Documentation on most of the LambdaMOO commands mentioned above can be acquired using 'help <command-name>'.  A notable exception is the commands like @oarrive and @take_failed that set textual messages on objects.  These are described under 'help messages'.

===== help to ======[EDITOR]===============================================

Syntax:  to [<recipients>]

(MAIL ROOM)
Specifies a new set of recipients (the To: line) for your message.
Recipient names not beginning with * are matched against the list of players.
Recipient names beginning with * are interpreted as mailing-lists/archives/other types of non-person addresses and are matched against all such publically available objects (see `help showlists').  If the list you want to use isn't in the database (i.e., isn't located in the database ($mail_agent)) you need to refer to it by object id.

===== help @toad ======[WIZARD]===============================================
*subst*
Syntax:  @toad   <player>  [graylist|blacklist|redlist]
         @toad!  <player>
         @toad!! <player>

Resets the player flag of <player> (thus causing <player> to be booted), resets the .programmer and .wizard flags, chowns the player object to $hacker, and removes all of its names and aliases from $player_db.

You must give either the player's full name or its object number.
Also, this command does not let you @toad yourself.

In some cases you may wish to add the player's last connected site to the site graylist, blacklist or redlist --- see `help blacklist' --- in order to invoke various kinds of blocking on that site (e.g., if player creation is enabled, you may want to enter the player on the blacklist to keep him from immediately creating a new character).  Specifying one of the listnames `graylist', `blacklist' or `redlist' will do this.

@toad!  <player>  is synonymous with  @toad <player> blacklist
@toad!! <player>  is synonymous with  @toad <player> redlist

There are messages that one may set to customize toading.  After all, a toading is (supposed to be) a rare event and you will doubtless want to put on a good show.  Thus we have

@toad  [%[$wiz.toad_msg]]
  Printed to everyone in the room in which the victim is being @toaded.
  If you're worried about accidentally toading yourself in the process of
  setting this message, see above.

@toad_victim  [%[$wiz.toad_victim_msg]]
  Printed to the victim.

These are pronoun_subbed with victim == dobj.

===== help topology ======[GENERAL]==============================================

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 -- creating new rooms and exits
@add-exit -- adding other players' exits from your rooms
@add-entrance -- adding other player's entrances to your rooms
@exits -- listing all of the conventional exits from your rooms
@entrances -- listing all of the conventional entrances to your rooms
@resident -- listing or changing the residents of your rooms

===== help truth ======[PROGRAMMER]===========================================

Several kinds of statements, expressions, and functions in the MOO programming language use a notion that some MOO values are 'true' and others 'false'.

The only values that are considered true are non-zero numbers, non-empty strings, and non-empty lists.

All other values (i.e., 0, "", {}, objects, and errors) are considered false.

===== help @typo ======[GENERAL]==============================================

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.

If you're sending a bug report to someone because you got an error traceback when you used some object of theirs, please give them enough information to work on the problem.  In particular, please tell them *exactly* what you typed and *all* of the error messages that were printed to you, including the entire traceback, up to the line `(End of traceback.)'.  Without this information, it is nearly impossible for the programmer to discover, let alone fix, the problem.

The usual mail editor is only invoked for this command when in rooms that allow free entry, i.e., rooms that are likely to allow you back after you are done editing your message.  Otherwise these commands will require <text> and only let you do one-line messages.  
Most adventuring scenario rooms fall into this latter category.

===== help @ungag ======[GENERAL]==============================================

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' for an explanation of gagging in general.

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

===== help @unlock ======[GENERAL]==============================================

Syntax:  @unlock <object>

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

===== help @unlock_for_open ======[GENERAL]==============================================

Syntax:
  @unlock_for_open <container>

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

See 'help containers' for information on containers.

===== help @unnewt ======[WIZARD]===============================================
SEE @denewt

===== help unpublish ======[EDITOR]===============================================

Syntax:  unpub*lish
         depub*lish
         perish

This command reverses the effects of `publish', making your text readable only by you.

===== help @unrefuse ======[LAMBDA]===============================================

Syntax:
    @unrefuse <actions> from <player>

If Stupid_Jerk reforms, you can change your mind. '@unrefuse mail from Stupid_Jerk' will remove the refusal.

'@unrefuse' can also be called '@allow', for those who prefer English over clarity.

    @unrefuse <actions>

If you don't mention a player, you remove only refusals that apply to everybody. '@unrefuse page' turns off any '@refuse page' command you
gave before, but does not affect refusals of specific players. You will still be refusing pages from Stupid_Jerk, if you were before.

    @unrefuse everything

 If you '@unrefuse everything', all your refusals are removed. This command asks if you are sure before erasing them all.

===== help @unrmmail ======[GENERAL]==========================================

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.

===== help @unsubscribe ======[GENERAL]=======================================
SEE @skip

===== help @untoad ======[WIZARD]=============================================

Syntax:  @untoad <object> [as <name>,<alias>,<alias>...]

Synonym: @detoad

Turns the object into a player.  
If the name/alias... specification is given, the object is also renamed.
In order for this to work, the object must be a nonplayer descendant of $player and the new object name (or the original name if none is given in the command line) must be available for use as a player name.  As with ordinary player @renaming, any aliases which are unavailable for use as player names are eliminated.

If the object is a descendant of $guest, then it becomes a new guest character.
Otherwise the object is chowned to itself.  In the latter case, it is advisable to check that the .password property has something nontrivial in it.

If the object is a descendant of $prog, then its .programmer flag is set.
Note that the .wizard flag is not set under any circumstances.

===== help @uptime ======[GENERAL]============================================

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.

===== help utilities ======[PROGRAMMER]=======================================

The core database has a number of objects serving as libraries of useful verbs.
More detailed information can be obtained for (some of) these, via `help $whatever_utils'

$building_utils -- 
$code_utils     -- parsing and manipulating verb code
$command_utils  -- reporting matching errors to the player
$gender_utils   -- managing gendered objects
$list_utils     -- list manipulation
$set_utils      -- set manipulation
$lock_utils     -- key expression manipulation
$match_utils    -- 
$object_utils   -- object information 
                  (inheritance/location hierarchy, verb/property lists)
$perm_utils     -- permissions
$string_utils   -- string manipulation
$time_utils     -- time (numeric and verbal) manipulation
$trig_utils     -- trigonometric and other numerical utilities

===== help @verb ======[PROGRAMMER]===========================================

Syntax:  @verb <object>:<verb-name(s)>
         @verb <object>:<verb-name(s)> <dobj> [<prep> [<iobj>]]

Adds a new verb with the given name(s) to the named object.  If there are multiple names, they should be separated by spaces and all enclosed in quotes:

        @verb foo:"bar baz mum*ble"

The direct and indirect object specifiers (<dobj> and <iobj>) must be either 'none', 'this', or 'any'; their meaning is discussed in the LambdaMOO Programmer's Manual.  The preposition specifier (<prep>) must be either 'none', 'any', or one of the prepositional phrases listed in `help prepositions' (a prepositional phrase with more than one word must be enclosed in quotes ("")).  All three specifiers default to 'none'.

It is also possible to specify the new verb's permissions and owner as part of the same command (rather than having to issue separate @chmod/@chown commands)

     @verb <object>:<verb-name(s)> <dobj> <prep> <iobj> <permissions>
     @verb <object>:<verb-name(s)> <dobj> <prep> <iobj> <permissions> <owner>

<permissions> are as with @chmod, i.e., must be some subset of "rwxd".  They default to "rd" (specifying "w" for a verb is highly inadvisable).  The owner defaults to the player typing the command; only wizards can create verbs with owners other than themselves.

You may also use "tnt" in place of "this none this" for the dobj prep iobj arguments.  "this none this" is used to indicate non-command verbs, since the parser can't possibly interpret a command as "this none this".  For these verbs, the permissions default to "rxd"; the "x" bit is set so that they can be called from other programs.  (If they couldn't be used as commands, and they couldn't be called from programs, they wouldn't be good for anything!)

===== help @verify-owned ======[GENERAL]======================================

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 for more information.

===== help @version ======[GENERAL]===========================================

Syntax:  @version

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

===== help view ======[EDITOR]============================================

Syntax:  view <player> [<range>] [nonum]
         view

Prints some subset of the specified player's text.
Said player must have previously made his text readable with `publish'.
<ranges> are specified as in other commands (see `help ranges').
References to the insertion point refer to wherever the other player has set his/her insertion point; you have no control over it.
The default range is as in list.

If no arguments are given, this lists all of the players that have published anything in this editor.

===== help what ======[EDITOR]===============================================

Syntax:  w*hat

Prints information about the editing session.

===== help whereis ======[GENERAL]============================================

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.

===== help whisper ======[GENERAL]============================================

whisper "<text>" to <player>
sends the message "<yourname> whispers, "<text>" to you " to <player>, if they are in the room.

===== help who ======[EDITOR]===============================================

Syntax:  who 
         who <rcpt>...

(MAIL ROOM)
Invokes $mail_agent's mail-forwarding tracer and determines who (or what) is actually going to receive your message.  The resulting list will not include destinations that will simply forward the message without :receive_message()'ing a copy for themselves.

The second form expands an arbitrary list of recipients, for if e.g., you're curious about the members of particular mailing list.

===== help @@who ======[WIZARD]===============================================
SEE @net-who

===== help @who ======[GENERAL]===============================================
*subst*
Syntax: @who
        @who <player> [<player> ... ]

The first form lists all of the currently-connected players, along with the amount of time they've been connected, the amount of time they've been idle, and their present location in the MOO.

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

@who refers to the @who_location message (see 'help messages') 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').  The default value is "%[$room.who_location_msg]" (i.e., the room name).

===== help @who-calls ======[WIZARD]==========================================
SEE @grepcore

===== help wizard-list ======[GENERAL]========================================
*subst*

%;this:wizard_list()

===== help wizard-list ======[LAMBDA]=========================================
(continued)
*subst*
See `help wizards' for some more detail about what wizards actually do.

While wizards may on occasion be in a mood to answer questions about programming or to offer general help, there are plenty of other players around that are willing and able to do this.  Since there are currently %[length(players())] players, the amount of time any given wizard can spend answering basic questions is necessarily limited, if not nonexistent --- don't take it personally.  You should feel free, though, to contact the wizards about potential bugs in the core verbs, problems or deficiencies in the help system, or other things that non-wizards can't help you with.

Tips:  
       When paging, just page the question.  You don't need to start with "Can I ask you a question?"  (Answer:  you can and you just *did* --- this is an example of a real-life courtesy that actually becomes counterproductive when translated to the MOO; if one sees an actual question, it is possible to deal with it relatively quickly, whereas if the page is merely a "mind if I interrupt?", time is lost waiting for the actual question to appear).  

       Keep in mind that the person you're paging may be idle or busy.  

       When sending mail, if you send to *Wizards (or use the @gripe command) any of the wizards can respond or act on it.  Some matters, e.g., problems with the core routines and general policy questions where open discussion is warranted, are best sent to one of the public mailing lists, *Core-Issues or *Theme-Issues, where others can see them.

       When reporting a bug, you should be as specific as possible about what you did that triggered the bug.  Mentioning object numbers and actual verbnames is useful.  If you saw a traceback, try to include that if you can.

===== help wizards ======[LAMBDA]=============================================

`Wizards' are the MOO-counterpart to real-life system administrators or janitors; in short, we maintain the place.  The `archwizard' is the one with his finger on the power switch.  The list of tasks we handle includes, but is by no means limited to

(1) fixing bugs in verbs on core objects, e.g., verbs on $player, $prog, $room,
    $exit, $anything_utils, etc..., not to mention extending and improving the
    core database.

(2) dealing with questions of player status.  This includes creating and
    registering new players and granting programmer bits.

(3) linking in newly constructed areas to the main house.  Note that if you
    want to ask for a quota increase or discuss possible projects to build, you
    should go to someone on the Architecture Review Board (see `help @quota'
    and `help quota-policy').  The wizards' involvement in this process is
    usually only at the very end: i.e., granting an ARB-approved quota increase
    and actually making the links when construction is finished.

(4) dealing with bugs on other verbs where necessary.  
    In general, the task of maintaining non-core verbs is left to the
    individual programmers who wrote them.  Any problems should be reported
    first to the programmer (e.g., with the @bug command).  However, in cases
    where an object is being particuarly annoying to a large number of people
    or disruptive to the server, some sort of action on our part may be
    unavoidable --- particularly if the programmer is nowhere to be found or
    otherwise unresponsive --- whether this be to kill runaway tasks, banish
    the offending object to #-1 or some other safe place, or perhaps to
    actually fix the code if the fix is obvious and we have time to figure it
    out.

Problems you have, especially in these areas, should be brought to our attention; if none of us happen to be around, send mail to *Wizards (see `help mail').  Feedback on any of our policies is likewise welcome.

PLEASE NOTE that the wizards are *not* the MOO equivalent of police officers; it is not our job to punish users that you find offensive or obnoxious or to try to prevent people from being that way.  The responsibility for this lies with the general LambdaMOO populace.  You can demand that the wizards implement a particular technical solution for social problems by using the petition and ballot mechanism; see `help petitions' for more information.

`Help wizard-list' gives a list of the current LambdaMOO wizards.

===== help @wrap ======[GENERAL]==============================================
SEE @linelength

===== help write ======[GENERAL]==============================================

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.

===== help zombie-messages ======[GENERAL]====================================
SEE @unrmmail

===== INDEX ==================================================================
"
#
:
::
;
?
 - - A - -
abort
@abort-shutdown
@add-entrance
@add-exit
@add-feature
@add-feature
@add-owned
@addalias
@addroom
@addword
alias
also-to
@answer
@arb
@args
@audit
 - - B - -
ballots
@ballots
$biglist
blacklist
@blacklist
@bug
building
building
burn
 - - C - -
cc
@check
@check-chparent
@check-property
@chmod
@chown
@chparent
@classes
@clearproperty
commands
@comment
common_quota
communication
compile
@complete
$container
container-messages
containers
@contents
copy
@copy
@count
cracking
@create
creation
@cspell
 - - D - -
@dbsize
decrypt
defense
delete
delete
@denewt
depublish
@describe
descriptions
@detoad
@dig
@disinherit
@disown
@display
@display-options
@displayoptions
done
drop
@dump
@dump-database
 - - E - -
edit
@edit
@edit-options
@editoptions
editors
@egrep
@egrep
@eject
emote
emote
encrypt
enter
@entrances
erase
$error
errors
eval
examine
examine
@examine
exit-messages
$exit
@exits
expressions
 - - F - -
features
features
features
@features
fill
find
@find
@forked
@forward
functions
 - - G - -
@gag
gagging
@gaglist
@gender
$generic_db
$generic_editor
$generic_help
$generic_options
get
give
@gms
go
@go
@grant
graylist
@graylist
@grep
@grep
@grepcore
@gripe
@guests
 - - H - -
hand
help
help
$help
home
$housekeeper
 - - I - -
@idea
information
insert
insert
introduction
inventory
 - - J - -
join
@join
 - - K - -
key-representation
keys
@kids
@kill
 - - L - -
LambdaMOO
language
@lastlog
letters
@linelength
list
@list
@listgag
@locations
@lock
@lock_for_open
locking
@log
$login
look
 - - M - -
mail
mail
@mail
$mail_agent
mail-format
mail-forwarding
@mail-options
$mail_recipient
mail-resolve
mail-system
@mailoptions
make-core-database
@make-guest
@make-petition
@make-player
manipulation
manners
@memory
message-sequences
messages
@messages
miscellaneous
mode
@more
move
@move
@move
move()
movement
MR-access
MR-naming
MR-reading
MR-searching
MR-sequences
MR-subscribing
MR-writing
multiple-characters
 - - N - -
name
negative_quota
@net-who
news
@newt
next
@next
$no_one
@notedit
notes
notify()
 - - O - -
object-matching
@opacity
 - - P - -
page
@pagelength
@paranoid
@parents
@password
pause
perish
@peek
petition
petition-commands
petition-motivation
petition-process
petitions
@petitions
petitions-commands
petitions-motivation
petitions-process
$player_db
player-names
players
precedence
prepositions
prev
@prev
print
privacy
.program
@program
@programmer
programming
programming
programming
pronouns
@property
@prospectus
publish
put
 - - Q - -
quit
@quit
@quota
@quota
@quota
quota-advice
quota-policy
quota-requests
 - - R - -
ranges
read
@read
@realm
receiving-mail
@recreate
@recycle
@recycle
recycle()
$recycler
redlist
@redlist
@refusal-reporting
@refuse
registration
regular-expressions
remove
@remove-entrance
@remove-exit
@remove-feature
@remove-feature
@rename
@renumber
@reply
reply-to
@request-character
@request-character
@resident
@rmalias
@rmmail
@rmproperty
@rmroom
@rmverb
@rmword
@rn
$room
room-messages
rooms
@rooms
rpg
 - - S - -
save
say
say
security
send
@send
sending-mail
@set
@setenv
@sethome
@setprop
@shout
@show
@shutdown
$site_db
@skip
@sort-owned
@spell
spelling
@spellmessages
@spellproperties
spoofing
statements
subject
@subscribe
@subscribed
subst
@suggest
summary
summary
summary
@sweep
 - - T - -
take
tasks
teleport-messages
theme
thing-messages
throw
tinymud
to
@toad
topology
truth
@typo
 - - U - -
@ungag
@unlock
@unlock_for_open
@unnewt
unpublish
@unrefuse
@unrmmail
@unsubscribe
@untoad
@uptime
utilities
 - - V - -
@verb
@verify-owned
@version
view
 - - W - -
what
whereis
whisper
who
@@who
@who
@who-calls
wizard-list
wizard-list
wizards
@wrap
write
 - - Z - -
zombie-messages
