Builder Help Topics

Builder Help Topics (#122)
==========================

@add-entrance	    @contents		@kids		    @remove-entrance
@add-exit	    @count		@locations	    @remove-exit
@add-owned	    @create		@lock		    @set
@audit		    creation		@lock_for_open	    @setprop
@build-options	    @dig		locking 	    @sort-owned
builder-index	    @dump		messages	    thing-messages
building	    @entrances		@messages	    topology
@check-chparent     @examine		@move		    @unlock
@check-property     exit-messages	@parents	    @unlock_for_open
@chparent	    @exits		@realm		    @verify-owned
@classes	    key-representation	@recreate	    
connectivity	    keys		@recycle	    


@ADD-ENTRANCE
=============

Syntax:  @add-entrance <exit-object-number>

Add the exit with the given object number as a recognized entrance to the
current room (that is, one whose use is not considered teleportation). 
Usually, @dig does this for you, but it doesn't if you don't own the room in
question.  Instead, it tells you the object number of the new exit and you have
to find the owner of the room and get them to use the @add-entrance command to
link it up.

@ADD-EXIT
=========

Syntax:  @add-exit <exit-object-number>

Add the exit with the given object number as a conventional exit from the
current room (that is, an exit that can be invoked simply by 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.

@ADD-OWNED
==========

Syntax:  @add-owned <object>

Adds an object to your .owned_objects property in case it managed not to get
updated properly upon creation of that object.	Checks to ensure that the
objects is really owned by you and otherwise belongs in your .owned_objects
property.  See help @audit for more information.

@AUDIT
======

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

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

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.
For rooms, the third column shows any entrances owned by someone else.
Object location, exit sources and destinations owned by another user are
preceded by a *.

@audit uses a property .owned_objects on the user, 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.

@BUILD-OPTIONS
==============

Syntax:  @build-option
	 @build-option <option>

Synonyms:  @buildoption, @builder-option @builderoption

The first form displays all of your builder options.
The second displays just that one option, which may be one of the flags listed
below.	The builder options control various annoying details of your building
commands (e.g., @create, ...)

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

	 @build-option create_flags [is] <flags>
	 @build-option create_flags=<flags>
	 @build-option -create_flags
		      (equivalent to create_flags="")

where flags is some substring of "rwf".  This option determines the
read/write/fertility permissions of an object freshly created with @create (see
`help @create' and `help @chmod').  E.g., to make every object you create
henceforth readable by default, do

	 @build-option create_flags=r

For controlling the behavior of @dig, we have

	 @build-option	dig_room=<room>
	 @build-option	dig_room [is] <room>
	 @build-option -dig_room
		      (equivalent to dig_room=$room)
	 @build-option	dig_exit=<exit>
	 @build-option	dig_exit [is] <exit>
	 @build-option -dig_exit
		      (equivalent to dig_exit=$exit)

The following respectively set and reset the specified flag option

	 @build-option +<option>
	 @build-option -<option>
	 @build-option !<option>	   (equivalent to -<option>)

Currently the only builder flag option available is
 -bi_create	@create/@recycle re-use object numbers.
 +bi_create	@create/@recycle call create()/recycle() directly 

we prefer that you not use +bi_create, since this drives up the object numbers.

BUILDING
========

There are a number of commands available to users 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

@CHECK-CHPARENT/@CHECK-PROPERTY
===============================

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.

@CHPARENT
=========

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 user does not own <new parent>, it must have been set `fertile'. 
<object> must be owned by the user.  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.

@CLASSES
========

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.

CONNECTIVITY
============

To dig a disconnected room:

    @dig <name>
 or @dig <name1>,<name2>,...

To make a room connected to the room you're in, though, the syntax is
different.

    @dig <direction-name> to <name>
 or @dig <direction-name1>,<direction-name2>,... to <name>

This will make a new room called <name> and an exit from the current room to
that room.  But usually you don't want this either since usually you want an
exit back.  To do that, you do:

    @dig <direction-name>|<reverse-direction-name> to <name>

This will create three objects: the room (named <name>), an exit from the room
you're in to the new room (named <direction-name>), and an exit from the new
room back to the room you're in (named <reverse-direction-name>).

@dig does not move you to the room you dug.  So if you want to dig another room
from there, you should move to there (using your new exit) first.

Almost always, you should give multiple names to the directions. e.g.,

    @dig south,s|north,n to "My New Room"

That way, people can use either name "south" or "s" to get there, and they can
use either the name "north" or "n" to get back.

To connect to an existing room instead of making a new one, use the object
number of the room instead of a name.  e.g., to connect to a room with object
number #123456, you might do:

    @dig south,s|north,n to #123456

You cannot dig to or from rooms that you do not own without getting help from
the owner.  (@dig will remind you of this if you try.)	For an exit to work,
both the owner of the source of the exit and the owner of the destination of
the exit must agree.  An owner can add an entrance or exit from your room to
theirs by going to that room and using @add-entrance or @add-exit.  So if you
make an exit #987654 that goes to #123456 but it can't be connected because you
don't own it, the owner can go to room #123456 and do:

   @add-entrance #987654

Or if you tried to @dig an exit (#987654) from someone else's room to one of
yours and it couldn't be connected, the owner of the room you tried to dig from
can go to their room and do:

   @add-exit #987654

For more information, do `help topology'.

@CONTENTS
=========

Syntax:  @contents object

A quick way to find out the contents of an object.  Prints out the names and
object numbers of all direct contents.	This can be useful when you need to
refer to something by object number because something is wrong with its
aliases.

Example:
  @contents here
  The Entrance Hall(#19) contains:
  Strasbourg Clock(#71)   mirror at about head height(#7444)

@COUNT
======

Syntax:  @count

Prints out the number of objects you own.  Do not be surprised if this is one
larger than you think it should be: remember that your user object is owned by
you as well, even though you didn't create it in the usual way.

@CREATE
=======

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.

CREATION
========

The primary means for users 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 space is left to you to 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 users
@move -- moving your objects from place to place

@DIG
====

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 users 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 user's current location to the
new room; users 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 users 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 user's current room to #7164, which must be an
existing room.

@DUMP
=====

Syntax:  @dump <object> [with [id=#<id>] [noprops] [noverbs] [create]]

This spills out all the properties and verbs on an object, calling suspend at
appropriate intervals.
   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.

@ENTRANCES
==========

Syntax:  @entrances

Prints a list of all recognized entrances to the current room (but only if you
own the room).	A recognized entrance is one whose use is not considered to be
teleportation.

@EXAMINE
========

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

EXIT-MESSAGES
=============


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 user making the
attempt and a single space character.  The standard pronoun substitutions (with
respect to the user) 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	[0]
  Printed to the user just before they successfully use the exit.

@oleave  [has left.]
  Printed to others in the source room when a user successfully uses the exit.

@arrive  [0]
  Printed to the user just after they successfully use the exit.

@oarrive  [has arrived.]
  Printed to others in the destination room when a user successfully uses the
exit.

@nogo  [You can't go that way.]
  Printed to the user when they fail in using the exit.

@onogo	[0]
  Printed to others when a user fails in using the exit.

@EXITS
======

Syntax:  @exits

Prints a list of all conventional exits from the current room (but only if you
own the room).	A conventional exit is one that can be used simply by typing
its name, like 'east'.

KEY-REPRESENTATION
==================

The representation of key expressions is very simple and makes it easy to
construct new keys on the fly.

Objects are represented by their object numbers and all other kinds of key
expressions are represented by lists.  These lists have as their first element
a string drawn from the following set:
	"&&"	 "||"	  "!"	  "?"
For the first two of these, the list should be three elements long; the second
and third elements are the representations of the key expressions on the left-
and right-hand sides of the appropriate operator.  In the third case, "!", the
list should be two elements long; the second element is again a representation
of the operand.  Finally, in the "?" case, the list is also two elements long
but the second element must be an object number.

As an example, the key expression
	#45  &&  ?#46  &&  (#47  ||  !#48)
would be represented as follows:
	{"&&", {"&&", #45, {"?", #46}}, {"||", #47, {"!", #48}}}

KEYS
====

LambdaMOO supports a simple but powerful notation for specifying locks on
objects, encryption on notes, and other applications.  The idea is to describe
a constraint that must be satisfied concerning what some object must be or
contain in order to use some other object.

The constraint is given in the form of a logical expression, made up of object
numbers connected with the operators 'and', 'or', and 'not' (written '&&',
'||', and '!', for compatibility with the MOO programming language).  When
writing such expressions, though, one usually does not use object numbers
directly, but rather gives their names, as with most MOO commands.

These logical expressions (called 'key expressions') are always evaluated in
the context of some particular 'candidate' object, to see if that object meets
the constraint.  To do so, we consider the candidate object, along with every
object it contains (and the ones those objects contain, and so on), to be
'true' and all other objects to be 'false'.

As an example, suppose the user 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, users 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 users 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'.]

@KIDS
=====

Syntax:  @kids <object>
	 @kids-f*ertil <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. Use the -fertil extention to get a report of
fertil direct kids.

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

@LOCATIONS
==========

Syntax:  @locations object

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

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

@LOCK
=====

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

Set a lock on <object> to restrict its use.  See 'help locking' 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.

@LOCK_FOR_OPEN
==============

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

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

See 'help containers' for information on containers.

LOCKING
=======

It is frequently useful to restrict the use of some object.  For example, one
might want to keep people from using a particular exit unless they're carrying
a bell, a book, and a candle.  Alternatively, one might allow anyone to use the
exit unless they're carrying that huge golden coffin in the corner.  LambdaMOO
supports a general locking mechanism designed to make such restrictions easy to
implement, usually without any programming.

Every object supports a notion of being 'locked' with respect to certain other
objects.  For example, the exit above might be locked for any object that was
carrying the coffin object but unlocked for all other objects.	In general, if
some object 'A' is locked for another object, 'B', then 'B' is usually
prevented from using 'A'.  Of course, the meaning of 'use' in this context
depends upon the kind of object.

The various standard classes of objects use locking as follows:
  + 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

MESSAGES
========

Most objects have messages that are printed when a user 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 user
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

@MESSAGES
=========

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.

@MOVE
=====

Syntax:  @move <thing> to <place>

Move the specified object to the specified location.  This is not guaranteed to
work; in particular, the object must agree to be moved and the destination must
agree to allow the object in.  This is usually the case, however.  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.

@PARENTS
========

Syntax:  @parents object

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

Example:
  @parents Wizard
  Wizard(#2)   generic wizard(#58)   generic programmer(#59)   generic 
  player(#6)   Root Class(#1)

@REALM
======

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

owners:      a list of users whose objects you are interested in. If
	     one of these is * or !, @realm will display objects only if
	     they belong to users 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.

@RECREATE
=========

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.

@RECYCLE
========

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

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

@REMOVE-ENTRANCE
================

Syntax:  @remove-entrance <entrance>

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

@REMOVE-EXIT
============

Syntax:  @remove-exit <exit>

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

@SETPROP/@SET
=============

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.

@SORT-OWNED
===========

Syntax:  @sort-owned

Sorts your .owned_objects property so @audit shows up sorted.  See help @audit
for more information.

THING-MESSAGES
==============

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 user making the attempt and a single
space character.  The standard pronoun substitutions (with respect to the user)
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  [You can't pick that up.]
  Printed to a user who fails to take the object.

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

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

@otake_succeeded  [picks up %t.]
  Printed to others in the same room if a user succeeds in taking the object.

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

@odrop_failed [tries to drop %t but fails!]
  Printed to others in the same room if a user fails to drop the object.

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

@odrop_succeeded  [drops %t.]
  Printed to others in the room if a user succeeds in dropping the object.

TOPOLOGY
========

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

@dig -- creating new rooms and exits
@add-exit -- adding other users' exits from your rooms
@add-entrance -- adding other user'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

@UNLOCK
=======

Syntax:  @unlock <object>

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

@UNLOCK_FOR_OPEN
================

Syntax:
  @unlock_for_open <container>

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

See 'help containers' for information on containers.

@VERIFY-OWNED
=============

Syntax:  @verify-owned

Checks that all the objects in your .owned_objects property are actually owned
by you, and effects repairs if needed.	See help @audit for more information.
MOOsaico: Multilingual Virtual Community
