Builder Help

$mail_recipient

See: $mail_recipient in General Help

@accept

See: room-security

@add-entrance

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

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

Syntax:

@add-monitored <object> for here - to add an object to a room's list @remove-monitored <object> for here - to remove said object @list-monitored for here - shows you what objects are defined.

Sometimes, when you want to @add-monitored an object, the routine will tell you the object's home is improperly set. Use @sethome <object> to <object> to set that object's home. It can be to the room or to a container within the room. This is where the object will be returned when it is finished.

Related messages (in the room):
   @monitored_return here is ... - the message the forgetful person sees when leaving the room.
   @monitored_gohome here is ... - the message that should be seen in the room where the object should stay.

@add-owned

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.

Related Topics:
@audit -- list the objects you own

@add-owner

Add or remove an additional owner for the specified object. You must be an owner of the object to use this command. Ownership for character (user) objects can only be changed by wizards.

Additional owners have most of the same building abilities and control over the given object as the primary owner does. They can rename the object, change its description, message, and properties, and can perform any owner-only operations/commands that the object is designed to support. Programming restrictions (such as changing verbs, adding or removing properties, etc) are not affected, however.

@audit

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

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').
If "with bytes" is included, and byte measurement is implemented, includes object sizes in bytes since their last measurement.

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 person are preceded by a *.

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

Related Topics:

@prospectus -- similar, but gives some additional information
@verify-owned -- checks if all objects on your "owned_objects" list are yours
@add-owned -- adds an object to your "owned_objects" list, if it was missing
@sort-owned --sorts your owned objects list by object number
@auditDB -- less efficient version of @audit, searches database directly
@audit-weight -- size in bytes of an object or all someone's objects

@audit-weight

This command shows the size in bytes of the specified <object> or if <object> is a user character, shows the sizes of all the objects that person owns. It uses the most recently measured size for the object, which may not be completely up to date.

If no <object> is given, it defaults to the user character of the person issuing the command.

If a <match-string> is given, only objects whose name contains that string are listed.

Related Topics:
@audit -- list objects someone owns; it has a "with bytes" option
@measure -- similar to @audit-weight but with more options; also it
            can force a remeasurement of an object's size to update
            the saved value

@auditDB

Returns a list of objects owned by <person>, optionally with object
numbers between <start> and <end>, and with a name containing
<matching string>. If <person> is omitted, the person issuing the
command is taken as default.

@auditDB functions like @audit, but instead of using the person's "owned_objects" list it searches the entire database directly. This is inefficient, and should only be used if there is a reason to think the person's owned objects list is corrupted.

Related Topics:
@audit -- a more efficient method of getting a list of a person's owned objects

@backup

  Saves information about the <object> that can be used to recreate
it in the event of its destruction. The "to mail" format sends the
backup text to the user by e-mail. It is sent to the user's e-mail
address (if valid) irregardless of their mail options settings. The
"to <note>" format requires the the user be able to write to the
note.

@chparent

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

The administrators 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.

Note that unless it has been modified by the local administration, the @classes command only identifies objects associated with the original eduCore.

@close

See: room-security

@contents

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

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 character object is owned by you as well, even though you didn't create it in the usual way.

The @countDB form searches the whole database for objects you own, which is less efficient, but can be useful to determine if your "owned_objects" list is incorrect. The results from @count and @countDB should be identical, else there are errors in your "owned_objects" list.

@countDB

See: @count

@create

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.

@del-owner

See: @add-owner

@deny

See: room-security

@dig

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 people 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 "<names> or "<names>|<names>" should have no spaces in it at all (see the examples below).

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. If you are digging from a public space (a hallway in a building for instance), you can contact any wizard to connect you.

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

@disinherit

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.

@disown

See: @disinherit

@display

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

@eject

This command is used to remove unwanted objects from places you own. People thus removed are unceremoniously dumped in their homes (unless that's this room, in which case they are dumped in the default character starting place). Other kinds of objects are checked for a .home property and sent there if possible, otherwise they get thrown into $nowhere. 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.

`@eject <object>' removes <object> from the current room, whereas `@eject <object> from <place>' removes the object from the specified location (in most cases, <place> will need to be specified 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.

The verbs @eject! and @eject!! are provided for those rare situations in which @eject does not work. @eject! does not check for .home properties, sending the offending object to #-1 immediately, but with a notification. @eject!! is just like @eject! but provides no notification to the object.

See 'help room-messages' for a list of messages one can set regarding the @eject command.

@eject!

See: @eject

@eject!!

See: @eject

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

@exclude

See: room-security

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

@invitations

See: @invites

@invite

Invite the specified person to join you in your current location. This is often used as the response to a @knock. <time>, if provided specifies the amount of time that the room should be held open for the person to enter. It should be a time interval in the format "<number> <unit> [<number> <unit>]", where <number> is a number and <unit> specifies hours/minutes/seconds/etc. (such as "1 hour 20 minutes"). The time interval may range from seconds to weeks, months, and years.

The @invite command allows you to bypass the room's current security settings (if you control the room) for the specified amount of time, letting an invited person in regardless of how the other security on the room is set up. After the time interval expires, the security settings automatically revert to normal (basically, like a temporary @accept that you don't have to worry about forgetting to undo).

If you do not specify a <time>, the default is 15 minutes.

There are a couple of settable messages you can use to customize your invitations:
  @invitation me is "<message>" - What the invitee sees when you invite them.
                                  %@ is substituted with the time interval.
  @oinvite me is "<message>" - What others in your room see when you invite
                                  someone into the room.

@invites

Syntax:

@invites or @invitations

You may only see the invitation lists of rooms you control or own.

Please consult "help @invite" and "help @uninvite" for more information.

@kids

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)

@locations

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

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.

Related Topics:
keys -- how to create a <key-expression> for locks
@unlock -- clearing the lock on an object
@security -- a sophisticated room security system, outlined here

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

eduCore: A vastly improved security system is available for rooms through the @security system. We suggest you use only the @security system for room security and not apply any @lock or other outdated schemes.

@lock_for_open

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.

@measure

A collection of routines to measure the sizes in bytes of objects in the database. This provides a good measure of just how much real memory space objects are taking up. Note that object sizes are cached and only updated periodically. You can force an immediate remeasurement with the "@measure object" varient.

@measure object - updates the stored object size and reports the result
@measure summary - reports total owned object size in bytes, and the time last surveyed
@measure new - measures objects the <person> owns that have not ever been measured
@measure breakdown - gives detailed technical info on sizes of each part of an object

Related Topics:
@audit -- You can also append "with bytes" to the @audit command to see byte sizes
@audit-weight -- a quick sorted summary of objects' sizes in bytes

@newmessage

Add a message property to an object (default is the character issuing the command), and optionally set its value. For use by non-programmers, who aren't allowed to add properties generally.

Related Topics:
@unmessage -- removes a message property from an object

@opacity

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.

@open

See: room-security

@parents

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)

@personal

  This command can be used to list or mark objects that are personal.
Using "@personal" alone lists your objects that are marked personal.
If you specify a person then that person's personal objects are
listed. If you specify an object however, it toggles that object as
being either personal or part of a project.
  Check the help information for "project-system" for more details on
personal and project objects and quota. Note that once the project
system is fully implemented, the @personal command will be extraneous
and removed.
  Synonymous command: @private

@private

See: @personal

@publicize

This command sets all your owned objects "readable" in the sense that programmers can then examine the characteristics of it that aren't specifically set unreadable. This does not allow people to read note text, for instance, since that is specifically set to be unreadable even if the object itself is "readable."

This command is generally only relevent for programmers who have been making unreadable objects, and now wish to enable other programmers to be able to examine their work.

@quota

Also see: quota in Local Help

@realm

Displays a part of the parenting tree of objects on the MOO, i.e. all
the descendants of a given object owned by particular people.

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

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

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

Until the object has been recreated in some new form, it is available to the "@unrecycle" command.

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

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.

@residents

Adds or removes a person 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 people to use that room as their home.

Some other systems besides @sethome use a room's residents list. For instance, self-cleaning rooms will often assume that any object listed among a room's residents shouldn't be ejected. The @resident command will accept any object, and not just people's characters.

@resident <person> - adds that person to the list.
@resident !<person> - removes that <person> from the list.
@resident with no arguments (or just @residents) simply displays the current list (which may be "none", indicating no additional people besides the owner may use that room as their home).

Related Topics:
@sethome -- set a particular room as your character's home

@security

See: room-security

@set

Changes the value of the specified object's property to the given value.

If no <value> is given, then the user is prompted for lines of text. This can be used for setting a text property.

You must have permission to modify the property, either because you own the property or if it is writable.

@set is a valid abbreviation for @setprop.

Also see: @setprop

@set-domain

This command (and it's alias @setdomain) set the domain for the
specified room. The <room> can be omitted to mean "where I am." The
first form sets the domain directly, while the second invokes an
interactive domain setting session. Use "help domain-system" for
more complete information on the domain system in general.

Related Topics:

@domain - shows what domain a person or object is in
@domains - shows the domplete set of enclosing domains

@setprop

Changes the value of the specified object's property to the given value.

If no <value> is given, then the user is prompted for lines of text. This can be used for setting a text property.

You must have permission to modify the property, either because you own the property or if it is writable.

@sort-owned

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

@uninvite

Syntax:

@uninvite <person>

This only works from within rooms you own, of course, which means that you can only revoke invitations you made yourself. You can alway obtain an inivtation list for a room you own with @invites.

Also see "help @invite" and "help @invites".

@unlock

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

@unlock_for_open

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

See 'help containers' for information on containers.

@unmessage

Remove a message property from an object (default is the character issuing the command).

Related Topics:
@newmessage -- adds a message property to an object

@unrecycle

Restores a previously recycled object and information stored on it, if it is still available. As the term "recycling" suggests, objects that undergo that process will be available to be used again by any user. Once an object you recycled is used for a new object you can not restore it.

You can only unrecycle objects you previously recycled (and hence owned).

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

builder-index

builder-summary

creation -- making, unmaking, and listing your rooms, exits, and other objects
ownership -- an explanation of object ownership
descriptions -- setting the names and descriptive texts for new objects
topology -- making and listing the connections between rooms and exits
room-security -- describes the available advanced room security features
exits -- extensive notes on exits for builders
domain-system -- details of the domain system that groups rooms
locking -- controlling use of and access to your objects
VSPO -- management of VSPO characters
mail-recipients -- creating and managing mail folders and mail lists
misc-builder-info -- things that didn't fit into any other catagory

building

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

Also see: building in Local Help

common_quota

Each person has a limit as to how many objects that person 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 person 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 VR worlds: 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 people to experiment and learn while simultaneously keeping random building to acceptable levels.

container-messages

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

@empty[It is empty.]
  Printed in place of the contents list when the container is empty.

@open [You open %d.]
  Printed to the person who successfully opens the container.

@oopen [opens %d.]
  Printed to others in the same room if the person successfully opens the container.

@open_fail [You can't open that.]
  Printed to the person who cannot open the container.

@oopen_fail []
  Printed to others in the room when a person fails to open a container.

@close [You close %d.]
  Printed to the person who closes a container.

@oclose [closes %d.]
  Printed to others in the room when a person closes a container.

@put [You put %d in %i.]
  Printed to a person when an object is successfully placed in a container.

@oput [puts %d in %i.]
  Printed to others in the room when a person successfully places an object in a container.

@put_fail [You can't put %d in that.]
  Printed when a person fails to put an object in a container.

@oput_fail []
  Printed to others in the room when a person fails to place an object in a container.

@remove [You remove %d from %i.]
  Printed when a person succeeds in removing an object from a container.

@oremove [removes %d from %i.]
  Printed to others in the room when a person succeeds in removing an object from a container.

@remove_fail [You can't remove that.]
  Printed when a person fails to remove an object from a container.

@oremove_fail []
  Printed to others in the room when a person fails to remove an object from a container.

containers

@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.
@create -- command for creating new objects

Containers have a large number of messages which get printed when people act upon them.
container-messages -- describes the various messages you can set on containers

Containers have opacity.
@opacity -- describes the various opacity settings for containers

Also see: containers in General Help

creation

inheritance -- summary of how inheritance works in object-oriented
               systems like the MOO
ownership -- describes object ownership, listing relevent commands
@dig -- conveniently building new rooms and exits
@create -- making other kinds of objects
@recycle -- destroying objects you no longer want
@unrecycle -- restore an object if it hasn't already been used for
              something else
@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 people
@move -- moving your objects from place to place
@recreate -- recreate an object you own into something else

decrypt

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

domain-system

Also see: domain-system in General Help

encrypt

Restricts the set of people who can read the named note or letter to those for whom the given key expression is true. Only the owner of a note may do this.

Related Topics:
keys -- how to specify a <key-expression> for encryption

exit-messages

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

@leave [You go %t.]
  Printed to the person just before they successfully use the exit.

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

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

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

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

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

@see_thru []
  Printed to someone before the destination room description when
they look through a transparent exit (%d is subbed with the name of
the destination room).
exit-transparency -- See "help exit-transparency" for more info on
                     transparent exits.

exit-transparency

The most basic way is simply to give your exit a description with the @describe command. Any exits with their own descriptions are considered to be "opaque" and will only show their own descriptions when people look at them. To make an exit transparent again, you can simply set its description to nothing ('@describe <exit> as ""').

You can change the message that gets displayed by a transparent exit before the room description by setting the 'see_thru' message on the exit (see 'help messages' for info on how to set messages on objects). In the see_thru message, all pronoun substitutions are as normal except that "%d" is substituted to the name of the destination room.

You can also change what type of room description the exit displays. To do this, type '@set <exit>.transparency to <number>', where the <number> is one of the following:
 -1 - The word "Nothing." is displayed for the room description, regardless
      of what the room actually looks like.
  0 - Nothing at all is displayed for the room desc, regardless of what the
      room actually looks like (thus the see_thru messaged is the only text
      displayed)
  1 - The brief description (what people would see if they entered the room
      with their 'brief' setting on) is displayed. This typically includes
      the room's title, exits, and contents, but no description.
  2 - The room's .description text is displayed (but no title, exits,
      contents, etc)
  3 - The room's full description is displayed (the same as if you had typed
      'look' while inside the room)

(3 is the default setting for exit transparency)

exits

  New builders are often surprised to find that exits are actual MOO
objects (child objects of $exit). In addition, each exit object
handles only one-way travel, so exits are typically created in pairs,
which gives the functionality of a two-way exit. Although it adds a
level of complexity, having exits be objects and one-way provides
immense flexibility for builders (even if most of us never take
advantage of that).
  Most of the time, you'll create exits using the "@dig" command,
which creates exits, creates a room if needed, and then links up the
exits appropriately. One common builder task is to connect rooms
owned by two different people. To prevent people from adding exits
to and from rooms against the room owner's wishes, the MOO's security
system allows you to build such exits but doesn't register them with
the attached room unless the exit's creator is also the room owner.
If someone else creates an exit from your room, and you wish to
register it as a valid exit, you'd enter "@add-exit <object_number>"
while standing in that room. Similarly, an exit leading to your room
(an entrance) would be registered with the "@add-entrance" command.
As usual, you can retrieve the exit's object number by using the
"@audit" command.
  Exits have various properties you can set, including a moderate
number of messages (use "@messages <exit name>") to see them. The
help text for "exit-messages" provides a detailed description of what
each message is used for.
  In addition, exits have two other properties: obviousness and
transparency. An "obvious" exit is one that people will see when
they look around the room or use the "ways" command. By default, all
exits are obvious, but you can change the setting with:
    @set <exit>.obvious to 0
Setting the "obvious" property to 1 restores it to obviousness.
  "Transparency" is the property that controls what people see when
they specifically look at the exit. A transparent exit is like an
open door, and looking "at" it lets you see what's in the room it
leads to. The help topic "exit-transparency" details how to use the
transparency property.

Related topics
@exits -- available to the room owner for listing all a room's
                 exits
@dig -- the primary tool for building rooms and connecting
                 them with exits
@add-entrance -- add an exit owned by someone else to your room's
                 entrances list
@remove-entrance -- remove the entrance
@add-exit -- add an exit owned by someone else to your room
@remove-exit -- remove the exit
exit-messages -- what messages can be set on exits
exit-transparency -- details of setting exit transparency
@set -- a general command for setting properties on objects

Also see: exits in General Help

fertile-objects

To make an object you own fertile, you can use either of:

    @set <object>.f to 1
or
    @chmod <object> +f

Additional topics:
@create -- the main command for creating new objects from existing templates
inheritance -- about object inheritance in the MOO

gopher

Also see: gopher in General Help

inheritance

Related Topics:
@create -- create a new object from an existing parent object
@kids -- list an object's child objects
@parents -- list an object's parent objects
@chparent -- change the parent of one of your objects
@disinherit -- @chparent an object to its grandmother (grandfather?)
@disown -- same as @disinherit

keys

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 character 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, people 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 people 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'.]

letters

Also see: letters in General Help

locking

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.

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
room-security -- summary of advanced room security features

mail

Also see: mail in General Help

mail-recipients

Given that, most of the time, people wish to establish a mail folder that anyone can post to and anyone can read. The procedure for this is:

   1. Create a child of $mail_recipient. The names and aliases should have no spaces (use underlines or hypens instead). Test the name and each alias beforehand (using "@mail on *<name>") to make sure no other mail folder already has that name or alias.
   2. Give your new <mail folder> a decription. This should generally be one or two sentances describing what the mail folder is for.
   3. For a free posting/free reading folder, enter: @set <mail folder>.readers to 1
   4. Finally, if you want the folder to appear in the "@subscribe" listing, use: @move <mail folder> to $mail_agent

Mail recipients can be made much more specific about who can post and who can read postings. There are several commands available for changing who can do various things to/with your mail recipient:

@restrict/@unrestrict <folder> - Specify whether the list is readable by
                                    everyone or only specific people.
@moderate/@unmoderate <folder> - Specify whether the list is postable by
                                    everyone or only specific "moderators".
@add-<type> <person> for <folder> - Add someone to the list of <type> people
                                    for the mail recipient, or..
@del-<type> <person> for <folder> - Remove the specified person from the
                                    <type> list.

<type> can be any of the following:
  reader - Person can read messages on the list (implies @restrict)
  writer - Person can remove or renumber messages on the list, or perform
              other administrative operations (such as use these commands)
  moderator - Person can post mail to the list (implies @moderate)
  forward - Person (or mail recipient) is automatically forwarded a copy
              of any message posted to the list
  notify - Person is notified immediately when new mail is posted to the
              list
  blocked - Person is specifically restricted from posting to the list

It is also possible to view your mail recipient's current configuration with the command:
  @setup for <folder>

messages

Related Topics:
@messages -- show the messages on an object
@newmessage -- very occasionally needed to allow builders to add new types of messages
@unmessage -- removes a messsage added with @newmessage

Also see: messages in General Help

misc-builder-info

negative_quota

You can, however, re-use your over-quota objects by using the @recreate
command instead (see `help recreate').

ownership

  In addition to a primary owner, objects may have "additional
owners" who have limited ownership priviledges for the object. For
instance, additional owners can edit an object's description. The
set of abilities additional owners have depends on the particular
object. Only an object's primary owner can add additional owners.
You can find out an object's owner and additional owners using the
"examine" command.

Related Topics:
@audit -- list owned objects
@add-owner -- add an additional owner
@del-owner -- remove an additional owner
@prospectus -- similar, but gives some additional information
@verify-owned -- checks if all objects on your "owned_objects" list are yours
@add-owned -- adds an object to your "owned_objects" list, if it was missing
@sort-owned --sorts your owned objects list by object number
@auditDB -- less efficient version of @audit, searches database directly

project-system

room-messages

The available messages are as follows:

 @ejection - What you see when you eject something from the room.
 @victim_ejection - What the ejected object sees.
 @oejection - What everybody else in the room sees.
 @inside_repel - Told to an object trying to illegally enter a room from
                    "inside" (see `help room-security').
 @pinside_repel - Told to the person trying to move the object (if the person
                    isn't the same as the object itself).
 @oinside_repel - Told to everyone in the room when an object tries to enter
                    illegally from "inside".
 @walk_repel - Told to an object trying to enter illegally through a
                    registered entrance to the room.
 @pwalk_repel - Told to the person responsible for moving it...
 @owalk_repel - Told to everyone in the room...
 @teleport_repel - Told to an object trying to illegally teleport into a
                    room from "outside".
 @pteleport_repel - Told to the person responsible for moving it...
 @oteleport_repel - Told to everyone in the room...
 @who_location - Text appended to room's name in @who listing

Related Topics: messages - How to set customizable messages on objects.
           pronouns - How to use pronoun substitution within messages
           room-security - Restricting access to a room.
           @eject - Forceably remove an object from a room.

room-security

The commands that control general room security are:
  @open - Make the room open to everyone and everything.
  @close - Make the room only accept things according to the security
                  settings established with @accept, @deny, and @exclude.
  @security - List the current security settings on the room.
  @accept <people/things> for <types>
                - Add or remove people or things from the "accept" list for
                  specified type(s) of entry. (see below for a more detailed
                  explanation of security lists)
  @deny <people/things> for <types>
                - Add or remove people or things from the "deny" list for
                  specified type(s) of entry.
  @exclude <people/things> for <types>
                - Add or remove people or things from the "exclude" list for
                  specified type(s) of entry.

Security Types
--------------
There are several different types of entrance to a room, and you can define different parameters for each type of entry. The available options are as follows:

  walk - Who/what can enter through a registered entrance to the room.
  teleport - Who/what can enter by teleporting to the room from outside.
  inside - Who/what can be dropped or moved into the room by
             someone/something already there.
  general - restrictions that apply if none of the above do.

Thus it is possible to specify that nobody can teleport into the room from outside, but that certain people can walk into a room via an entrance and put things there.

Note that none of these security restrictions have any effect on the owner of the room or any object in the @residents list for that room, which are always allowed in.

Note: While inside/outside checking is fairly thorough, due to limitations in the MOO system it is not foolproof, and it could appear under unusual situations as though something was entering from "inside" when in fact it was not. Thus requirements dependent on "inside" vs. "outside" should not be used when absolute security is required.

@accept, @deny, and @exclude
----------------------------
For each type of entry you can specify an "accept", "deny", and "exclude" list. Whether something is allowed into a room, based on these lists, is evaluated as follows:

 o If the accept list isn't empty, then the entering object must be on the
    list in order to enter.
 o If the object is on the deny list, then it is not allowed to enter (even
    if it is also on the accept list).
 o If the object is a descendant of any of the objects on the exclude list,
    is owned by anyone on the exclude list, or is being moved by anyone on
    the exclude list, it is not allowed into the room.

The accept and deny lists allow you to explicitly allow or disallow specific objects into your room. The exclude list allows you to specify not to let in certain types of objects, or objects owned by certain people. (Warning: It is probably a bad idea to put wizards on the exclude list, as they generally own a good portion of the generic objects on the MOO)
The key difference between the @deny and the @exclude commands is that @deny will keep out a specific object or person. Using @exclude will keep out the specified object or any of its decendent objects, and is therefore appropriate for keeping out "all objects descended from the generic following dog" for instance. The @exclude command also keeps out all objects owned by the specified object, so if the excluded object is a person, that person and all they own will be restricted from entering the room.

To change one of these lists, you must use the @accept, @deny, or @exclude command in the following manner:

  @accept/@deny/@exclude <people/things> for <types>

Where <people/things> is a list of people and things to add to the appropriate list, and <types> is a list of one or more types of entry, as specified in 'security types', above. For each entry in <people/things>, if you put an exclamation mark (!) before it it will remove that object from the list, instead of adding it.

Example: @deny Bad_Person !Person_Who_Apologized Annoying_Geek for general
 ..would add Bad_Person and Annoying_Geek to the "deny" list for "general" access, and would remove Person_Who_Apologized from that list.

Note: You can also specify 'all' as one of the people or things to accept/deny/exclude, which will apply to everyone and everything. Thus you can '@deny all for teleport' to keep everyone from teleporting into the room.

Related Topics:
  room-security-examples -- Some examples of these commands, with
                              explanations
  room-messages -- Customizable messages for rooms.
  Movement -- Getting around the MOO.
  @eject -- Forceably remove an object from a room.
  @residents -- Add or remove registered residents of a room.
  @invite -- Temporarily open the security for a specified person
  @invites -- shows who is invited
  @uninvite -- Revoke the @invite for a person

room-security-examples

@security
Shows what the current security of the room is. Note that if you have not activated the security (with @close) then it will inevitably show that anyone may enter. You'll only see the security settings you've added if you first @close the room and then use @security to check.

@close
Turns on whatever room security you've set. If absolutely nothing has been set, then "@deny all for general" is assumed, meaning no uninvited people may enter.

@open
Deactivates the room security, allowing anyone and anything to enter.

@deny Hooligan for general
The person named "Hooligan" is not allowed into the room.

@deny Hooligan for teleport
Hooligan may enter the room only through mechanisms other than teleporting. Command for teleporting include @go and @join. Non-teleporting mechanisms include using the room's entrances/exits.

@exclude Hooligan for general
Neither Hooligan, the horse he rode in on, nor any other things Hooligan owns may enter the room.

@exclude !Hoolian for general
OK, take Hoolian off the @exclude list.

@accept Glenda for general
Even when room security is active, Glenda will always be permitted in the room.

@deny all for teleport
People may only enter the room through non-teleporting means (presumably an exit/entrance).

@accept all for walking
Essentially equivalent to "@deny all for teleport" but the precise meaning is "Even when room security is on, anyone not otherwise excluded may enter if they do so using a room entrance/exit.

Related Topics:

@security -- All those show the "room-security text"
@accept --
@deny --
@close --
@open --
@resident -- Set who is considered a resident, and thus always entitled to enter

rooms

Also see: rooms in General Help

thing-messages

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

@take_failed [You can't pick that up.]
  Printed to a person who fails to take the object.

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

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

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

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

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

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

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

topology

@dig -- creating new rooms and exits
@add-exit -- adding exits owned by other people from your rooms
@add-entrance -- adding entrances owned by other people 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