root/1.8.3/trunk/game/txt/hlp/penntop.hlp

& help
This is the index to the MUSH online help files.

  For an explanation of the help system, type:    help newbie

  For the list of MUSH commands, type:            help commands
  For the list of MUSH topics, type:              help topics
  For an alphabetical list of all help entries:   help entries 
  For a list of entries that match a pattern:     help <wildcard>
  For information about PennMUSH:                 help code
  
  For a list of flags:                            help flag list
  For a list of functions:                        help function list 
  For a list of attributes:                       help attribute list
  To see the configuration of this MUSH:          @config

  On many MUSHes, list local commands with:       +help

If there are any errors in the help text, please notify a wizard in the
game, or send mail to pennmush-bugs@pennmush.org, which is the address
of the team who develop PennMUSH (and its distributed help files) but
probably have no relation to this MUSH in particular.

& newbie

  If you are new to MUSHing, the help files may seem confusing. Most of
  them are written in a specific style, however, and once you understand
  it the files are extremely helpful.

  The first line of a help file on a command or function will normally be
  the syntax of the command. "Syntax" means the way the command needs to
  be typed in. In the help files, when the syntax of a command is described,
  square brackets [] mean that that part of the command is optional and
  doesn't have to be typed in. Also, pointy brackets <> mean that that part
  of the command needs to be replaced with a specific piece of information.
  
  You should not type the [] or <> brackets when entering a command.
  
(continued in help newbie2 -- type 'help newbie2' without the single quotes)
  
& newbie2

  For example, the syntax of the help command is:
  
  help [<topic>]
  
  What this means is that to get help, you would type first the word "help" and
  then you could optionally type the name of a more specific topic in order
  to get help on that topic. Just typing "help" will work too (that's why the
  <topic> part is optional).
  
  Some common commands that you should look at help for are:
  
    look   say    go    page    pose    take     give    home
  
  Just type help <command> for help. Example: help page
  
(continued in help newbie3)
& newbie3

  There is help available on every standard MUSH command. If you see a command
  or someone mentions one to you that you want to know more about, try just
  typing: help <command name> -- that will most likely bring up the help
  file on it.
  
  Please note that just because there is help available on a command does
  not necessarily mean that the command can be used on this MUSH. The
  siteadmin of the MUSH can choose to turn off some commands. If there's
  something that you would like available, and it isn't, please ask a wizard
  why not.
  
  It is also highly recommended that any new player read the MUSH manual,
  written by Amberyl. It is available by anonymous FTP from:
     ftp.pennmush.org
  in the directory:
     /pub/PennMUSH/Manuals

& topics
Help is available on the following topics:

  ACTION LISTS             ANCESTORS                ANONYMOUS ATTRIBUTES
  ATTRIB-OWNERSHIP         ATTRIBUTES               BEING KILLED
  BOOLEAN VALUES           CHAT                     CLIENTS
  CONTROL                  COPYRIGHT                COSTS
  CREDITS                  DBREFS                   DROP-TO
  ENACTOR                  EVALUATION               EXECUTOR
  EXITS                    FAILURE                  FLAGS
  FUNCTIONS                GENDER                   GLOBALS                  
  HERE                     HOMES                    INTERIORS                
  LINKING                  LISTENING                LISTS                    
  LOOPING                  MASTER ROOM              MATCHING

(continued in help topics2)
& topics2
  ME                       MONEY                    MUSHCODE
  NON-STANDARD ATTRIBUTES  PARENTS                  POWERS
  PUPPETS                  QUEUE                    REGEXPS
  REGISTERS                SEMAPHORES               SETTING-ATTRIBUTES       
  SPOOFING                 STACK                    STRINGS                  
  SUBSTITUTIONS            SUCCESS                  SWITCHES                 
  TYPES OF OBJECTS         USER-DEFINED COMMANDS    VERBS                    
  WARNINGS                 WILDCARDS                ZONE MASTER ROOMS        
  ZONE MASTERS             ZONES  
  
Type "help <topic name>" for help.
& ACTION LISTS
  Action lists are simply lists of actions that are all executed at once.
  You can have an action list in a user-defined command, in one of the
  a-attributes, or in many other commands. Action lists may not be
  executed directly from a client, except in the case of a command
  which forces a re-insertion into the queue such as @switch or
  @dolist.

  Actions in an action list are separated by semicolons. Each action is 
  simply a separate MUSH command. If part of the action (such as the text
  in an @emit, for example) contains a semi-colon or comma, you may need
  to enclose that part in curly braces {}. You can also nest action lists
  inside each other by enclosing each action list in braces {}.

  Substitution will be performed on the contents of action lists before
  they are executed.

(continued in help action2)
& ACTION2
  Example 1:
    > @asuccess Gift = @pemit %#={The box pops open; surprise!} ; 
        @name me=New Toy ; @desc me={A shiny new toy, just for %N!}
    > take gift
    The box pops open; surprise!
    > look new toy
    New Toy
    A shiny new toy, just for Cyclonus!
            
  Example 2:
    > &TEST me=$test:@emit {Testing; testing; one, two.} ; 
        @dolist 1 2 3={think {Test ##, success.} }
    > test
    Testing; testing; one, two.
    Test 1, success.
    Test 2, success.
    Test 3, success.

See also: ATTRIBUTES, SUBSTITUTION, @asuccess, @dolist
& ANCESTORS
  ANCESTORS

  Objects can inherit attributes from other objects through the
  use of parents. An object's parent, its parent's parent, its 
  parent's parent's parent, etc. constitute the object's "parent chain"
  and lookups work the way up the chain until an inheritance occurs.

  Ancestors are "virtual parents" that are assumed to be last on every
  parent chain. There is one ancestor for each object type (room, exit,
  thing, player), and @config lists the dbref of each ancestor object
  (@config ancestor_room, etc.) Under normal circumstances, if an attribute
  can't be retrieved from an object or any of its explicit parents,
  the attribute will be looked for on the appropriate ancestor.
  The ORPHAN flag may be set on an object to cause lookups on that 
  object to ignore ancestors (like the pre-ancestor behavior).

  Ancestors may themselves have parent chains, but these are (obviously)
  not virtually terminated by ancestors.

  Note that the choice of which ancestor to look up is based on the 
  type of the *child* object, as is the check of the ORPHAN flag.
  Also note that ancestors are *not* checked for $-commands or
  ^-commands; you should use the master room for global commands,
  instead.

See also: PARENTS, ORPHAN
& ANONYMOUS ATTRIBUTES
& LAMBDA
& #LAMBDA
  In many cases where a function expects a object/attribute pair
  that refers to an attribute to evaluate, you can use the form

  #lambda/<code>

  instead, and the code will be treated as an attribute's body.
  The code will normally be parsed twice, so special characters 
  should be escaped where needed.

  These anonymous attributes should be used for short and simple
  pieces of code. Anything long or complicated should go in an
  actual attribute, for readability and maintainability.

  See 'HELP ANONYMOUS2' for examples.
& ANONYMOUS2
  A typical usage of anonymous attributes would be to convert
  a list of dbrefs to names, as so:

  >say map(#lambda/name(\%0), #3 #12 #23)
  You say, "Joe Robert Sally"

  Because the code is parsed twice, you can actually build parts of
  it in place, which is very convenient. Consider this implementation
  of a lattrval function, which is like lattr() but it only returns
  non-empty attributes:

  &lattrval me=
   filter(#lambda/hasattrval([secure(before(%0, /))], \%0), lattr(%0))
  
  The first time '#lambda/hasattrval([secure(before(%0, /))], \%0)' is
  parsed in a call like 'u(lattrval, #1234)', it is turned into
  '#lambda/hasattrval(#1234, %0)', thus avoiding the need for a setq() or
  the like to store the top-level %0 for use in a real attribute called by
  filter(). However, this can lead to problems with evaluating un-trusted
  code. Use secure() or escape() where neccessary.

  See 'HELP ANONYMOUS3' for another example.
& ANONYMOUS3
  
  You can also use lit() to avoid having the code evaluated twice, if
  needed. For example, this code, which returns all unlinked exits in
  a room:

  &lunlinked me=filter(lit(#lambda/strmatch(loc(%0), #-1)), lexits(%0))

  This approach is useful both for security in making it harder to evaluate
  a string that shouldn't be, and for making the code look nicer by not
  having to escape percent signs, brackets, and other special
  characters. However, it also makes it harder to build the code string on
  the fly. Use what's most appropriate.
     
  See 'HELP ANONYMOUS4' for a list of functions that support anonymous
  attributes.
& ANONYMOUS4
  The following functions support anonymous attributes:
  
  filter()    filterbool()   fold()      foreach()   map()      mapsql()
  mix()       munge()        sortby()    sortkey()   step()
& ATTRIB-OWNERSHIP
  ATTRIBUTE OWNERSHIP
  
  The latest person to set an attribute on an object is the owner
  of that attribute. If you lock an attribute, using the @atrlock command,
  only the person who owns the attribute will be able to alter the
  attribute. This allows you to create standard commands on objects and
  then @chown them to others without letting them alter them. 

  Attribute ownership is NOT changed when the object itself is @chown'ed.
  To change attribute ownership, you must use the @atrchown command.

  You must control an object in order to set attributes on it.

See also: @atrlock, @atrchown, ATTRIBUTES
& ATTRIBUTES
& ATTRIBUTES LIST
& ATTRIBUTE LIST
  Attributes with (*) after them are special, cannot be set by players,
  and may only be visible to wizards or admin. For those attributes, there
  is no @-command, so you can just type 'help <attribute name>' for help.
  For all other attributes, type 'help @<attribute name>' for help.

Standard Attributes: (see @list/attribs for the complete list)
  AAHEAR        ACLONE        ACONNECT      ADEATH        ADESCRIBE
  ADISCONNECT   ADROP         AEFAIL        AENTER        AFAILURE
  AHEAR         ALEAVE        ALFAIL        AMHEAR        AMOVE
  APAYMENT      ASUCCESS      AWAY          CHARGES       COST 
  DEATH         DESCRIBE      DROP          EALIAS        EFAIL         
  ENTER         FAILURE       FORWARDLIST   HAVEN         IDESCRIBE     
  IDLE          LALIAS        LAST (*)      LASTIP (*)    LASTLOGOUT(*) 
  LASTSITE (*)  LEAVE         LFAIL         LISTEN        MOVE          
  ODEATH        ODESCRIBE     ODROP         OEFAIL        OENTER        
  OFAILURE      OLEAVE        OLFAIL        OMOVE         OPAYMENT      
  OSUCCESS      OXENTER       OXLEAVE       OXMOVE        PAYMENT       
  QUEUE (*)     RQUOTA (*)    RUNOUT        SEX           STARTUP       
  SUCCESS       TFPREFIX

(continued in help attributes2)
& ATTRIBUTES2
  An attribute is part of the code on an object that makes it unique. An
  attribute can contain any sort of text -- from a single word, to a long
  paragraph, to a piece of MUSHcode. Some attributes are standard in 
  PennMUSH. That means that their effects are pre-set. 

  Standard attributes can be set using one of the following commands:
    @<attribute name> <object>=<content>
    @set <object>=<attribute name>:<content>
    &<attribute name> <object>=<content>

  It is also possible to have non-standard attributes, which can be named 
  anything you like. Please see 'help NON-STANDARD ATTRIBUTES' for more 
  information on those. 

(continued in help attributes3)
& ATTRIBUTES3
  Any attribute name can be shortened, but a shorter forms run the risk
  of conflicting with other attribute names.  This could result in you
  setting an unwanted attribute. 

  For example:
    @adesc me=think %N looks at you.
  will set your ADESCRIBE attribute just as
    @adescribe me=think %N looks at you.
  would.

  To see the attributes that are set on you or on any of the objects you own,
  you should use the "examine" command. See 'help examine'.
  
(continued in help attributes4)
& ATTRIBUTES4
  Attributes can be owned by someone other than the object they are set on.
  This allows the person to change the content of just that attribute while 
  not the rest of the object. Attributes can also be locked, which prevents
  them from being changed by anyone.

  In addition to the standard attributes with pre-set effects, there are
  some special attributes that date from the days before you could set
  non-standard attributes with any name you wanted. These are the 
  attributes VA-VZ, WA-WZ, XA-XZ. These attributes have no pre-set effects,
  and were just to allow players to store any text or MUSHcode that they
  wished in those attributes. Now that non-standard attributes are available,
  it is highly recommended that you instead use them, since you can use
  longer and descriptive names for attributes, which makes it much easier
  to examine and work on objects.

See also: ATTRIB-OWNERSHIP, @set, examine, @atrchown, @atrlock, hasattr(),
  get(), v(), NON-STANDARD ATTRIBUTES, SETTING-ATTRIBUTES, ATTRIBUTE TREES

& BEING KILLED
 
  Getting killed is no big deal. If you are killed, you return to
  your home, and  all things you carry return to their homes. You 
  also collect 50 pennies in insurance money (unless you have >= 10000 
  pennies or you were killed via the Wizard slay command). See 'MONEY'.  
  Generally, killing is not encouraged unless absolutely necessary.
  It can be extremely rude and annoying.

  Many MUSHes choose to disable the kill command.

See also: kill, slay, @death
& BOOLEAN VALUES 

  A boolean variable, for those of you not familiar with programming, 
  is a variable that is either true or false. Normally, a value of
  1 is considered "true" and a value of 0 is considered "false". Many
  MUSH functions return either 1 if they are true or 0 if false.
  For example, the hasflag() function tests to see if an object has
  a certain flag set on it. If
        hasflag(<object>,<flag name>) 
  is true (the object has the flag), it will return 1. If it is false, 
  it will return 0. 

  Other functions expect to operate on boolean values. What they
  consider "true" or "false", however, depends on the setting of
  the "tiny_booleans" config option (@config tiny will show this).  

(continued in help boolean2)
& BOOLEAN2 
  If tiny_booleans is...
  no                       FALSE: null string, 0, any negative db
                           TRUE:  everything else
  yes                      TRUE:  numbers other than 0
                                  strings beginning with numbers other than 0
                           FALSE: everything else 
  
  Or, put another way:
  Value                 tiny_booleans=no        tiny_booleans=yes  Gotcha
  0                     FALSE                   FALSE
  non-zero number       TRUE                    TRUE 
  #<non-negative>       TRUE                    FALSE               *
  #<negative>           FALSE                   FALSE                

  null string           FALSE                   FALSE
  0<non-numbers..>      TRUE                    FALSE               *
  <non-numbers...>      TRUE                    FALSE               *

(continued in help boolean3)
& BOOLEAN3

  Examples (assuming tiny_booleans is "no"):     
    not(foo) = 0  
    not(<null string>) = 1
    not(-66) = 0
    not(0) = 1
    not(#-1) = 1
    not(#12) = 0
  And so on...
  (note: These rules only apply when a function expects a Boolean
  value, not for strings that expect other values.)

See also: BOOLEAN FUNCTIONS, not(), t()
& CLIENTS
  Clients are special software programs that you can use to connect to 
  MUSHes. They are usually much nicer to use than raw telnet and give you
  many additional features, such as larger text buffers (so you can type
  more), backscroll, history of previous commands, macros, and so on. 

  Here is a list of common clients and the web sites where they can be
  found.  Please note that the below sites are subject to change.  The
  below are listed solely for your information and possible benefit.
  The developers of PennMUSH have nothing to do with the clients.

  OPERATING
  SYSTEM          CLIENT      WEB SITE
  -----------------------------------------------------------------------
  UNIX            Tinyfugue   http://tinyfuge.sourceforge.net
  WINDOWS         MUSHClient  http://www.mushclient.com
                  SimpleMU    http://simplemu.onlineroleplay.com
                  MuckClient  http://www.xcalibur.co.uk/MuckClient/
  MAC OS X        Savitar     http://www.heynow.com/Savitar/
                  Atlantis    http://www.riverdark.net/atlantis/
                  Unix clients will also run on OS X.
& CONTROL
  Controlling an object basically means that you have the power to change
  the object's characteristics such as flags and attributes. It may also
  mean that you have the ability to destroy it.

  Here are the conditions under which object O controls victim V:
  1. If V is God, O must be God
  2. If V is Wizard, O must be Wizard or God
  3. If O is a Wizard, O controls V
  4. If V is Royalty, O must be Royalty, Wizard or God
  5. If O is MISTRUST, O must be V to control V
  6. If V and O are owned by the same player:
     6a. If V is not TRUST, O controls V
     6b. If V is TRUST, O must be TRUST or the player must be TRUST
  7. If V is on a zone, and isn't a player and isn't TRUST,
     O controls V if O passes the zone-lock of the zone.
  8. If V is owned by a SHARED player, and V isn't a player and isn't set
     TRUST, O controls V if O passes the zone-lock of the SHARED player.

  Step 7 is skipped if config(zone_control_zmp_only) is on.
  There's also one special case: anyone can @link an unlinked exit
  (at which point the exit is @chowned to the linker).

See also: controls(), TRUST, MISTRUST, ZONES, SHARED PLAYERS
& COSTS
  These are usually:
  
          kill: 10 pennies (or more, up to 100 pennies)
          page: 0 pennies
          @dig: 10 pennies
          @create: 10 pennies (or more)
          @find: 100 pennies
          @search: 100 pennies
          @entrances: 100 pennies
          @link: 1 penny (if you  didn't already own it,
                          +1 to the previous owner).
          @open: 1 penny (2 pennies if linked at  the same time)
  
  Type '@config/list costs' to get the costs for the MUSH you are on.

See also: MONEY, money(), score
& CREDITS
  Maintainer: Raevnos [SW]
  Developers: Javelin, Ervin Hearn III [EEH], Greg Millam [GM]
  Past Porters: Nick Gammon [NJG] (win32), Dan Williams [DW] (MacOS), 
           Sylvia (OS/2)
  Former developers: Rhyanna [RLM], Trivian [TN], Halatir [LdW], Talek [TAP]
 
  The original TinyMUSH 1.0 code was written by Lawrence Foard, and
  was based upon James Aspnes' TinyMUD server. Since then, the code
  has been modified by the programmers of MicroMUSE (then MicroMUSH),
  and Joseph Traub (Moonchilde of PernMUSH).  From January 1992 to
  January 1995, Lydia Leong (Amberyl of PernMUSH / Polgara of
  Belgariad) maintained the code currently known as PennMUSH 1.50.
  From January 1995 until July 2006, Alan Schwartz (Paul of DuneMUSH /
  Javelin elsewhere) maintained this code, along with a development
  team. From July 2006 on, Raevnos has been the maintainer.

  Big thanks to the developers of TinyMUSH 2.0, 2.2 [2.2], 3.0 [3],
  MUX2, and Rhost [Rhost] servers, as well as to the players of
  Belgariad MUSH, DuneMUSH, and M*U*S*H, and everyone else using this
  server!

See also: help code, help license
& DATABASE
& DBREFS
& DBREF NUMBER
& DBREF #
  You will find the term "dbref" or "dbref number" used frequently in these
  help files and in MUSHcode. It is an abbreviation of "database reference
  number".
  
  The database is the part of MUSH that stores all the information about 
  this particular MUSH. Players, things, rooms, and exits are all objects
  in the database. Each object in the database has a unique dbref number
  that is set when the object is created. You can use the dbref number to
  refer to an object that is not in your current location, and it is 
  especially important for global code.

  Using DBREFs is also faster than using names, even if the object is
  in your location. This is because whenever you try to do something with
  an object (such as look at it, take it, etc.), the MUSH first has to
  locate the object. Since the dbref is unique, it can immediately find
  the object rather than checking through all the contents of your area
  to see if one matches the name.

(continued in help dbref2)
& DBREF2
  
  If you own or control an object, you will see its dbref number listed
  right after its name when you look at it (unless you are set MYOPIC).

  Example:
    > look me
    Cyclonus(#3PWenAMc)
    A very short desc.

  The dbref number is indicated by the number/pound sign (#). Cyclonus's
  dbref is #3. The letters following the dbref are the abbreviations of
  the flags set on the object. NOTE: the abbreviation of the OPAQUE
  flag is 'O' (o), which looks like '0' (zero) on some clients. Make sure 
  you have the right number before using it in your code!

See also: MYOPIC, OPAQUE, MUSHCODE
& DROP-TOS

  When you use the @link command on a room, it sets another room or
  object as the DROP-TO location. By default, any non-STICKY object that
  someone drops in the room will automatically be transported to the
  drop-to location, rather than staying in the room. Any STICKY object
  droped in the room will go to its home.

  If the room is set STICKY, objects dropped in the room will stay there
  until the last player leaves/disconnects, at which point they will be
  transported as described above.

  If the room has a @lock/dropto set on it, only objects that pass the
  lock will be transported (either immediately or when the last player
  leaves if the room is STICKY). This can be used to prevent the dropto
  from acting on, say, objects containing connected players.

  Drop-tos are useful for keeping rooms uncluttered. 

See also: @link, STICKY, LINK_OK, @lock
& %#
& %N
& %~
& %:
& ENACTOR
  The enactor is the object that does something (enacts something :).
  This is an important concept in MUSH, because the way many commands
  work will depend on who enters the command (ie, who the enactor is).
  Any type of object can be an enactor. 

  There are five %-substitutions that involve the enactor:
    %# = the enactor's dbref
    %N = the enactor's name, first letter capitalized
    %n = the enactor's name, first letter as-is
    %~ = the enactor's accented name
    %: = the enactor's unique identifier, like objid(%#)

  If, for example, you have an @osucc on an object that includes the
  %n symbol, whenever someone picks up the object, that %n will be 
  replaced with the name of the enactor (the person who typed 'get <object>'
  in this case). 
  
See also: EXECUTOR, SUBSTITUTION, DBREF
& EVALUATION ORDER
  Whenever some text is entered by an object or thing, the MUSH program
  attempts to match it against a valid game command in the following 
  order of possible commands:

    Special game commands: WHO, QUIT, etc.
    Single-token commands: ", :, ;, +, \, #
    Exits in the room
    @-commands and &attribute setting
    Regular game commands: get, inventory, etc.
    Enter aliases
    Leave aliases
    User-defined commands on nearby objects. All such $commands are matched
      and executed.
    If there are no user-defined commands nearby:
      If the zone of the player's location is a zone master room,
        Zone master room exits
        Zone master room user-defined commands
      Else
        User-defined commands on the zone of the player's location

(continued in help evaluation2)
& EVALUATION2
    If still nothing is matched:
      User-defined commands on the player's personal zone
    If nothing, including zone commands, has been matched:
      Global exits
      Global user-defined commands: all $commands in the Master Room are
        matched. Local commands are always checked first and ALWAYS negate
        global commands.

  Because local commands overrule global commands, you can easily prevent
  a global command from working in a specific room by setting a copy of
  the global command in that room. Alternatively, if a global command is
  oddly not working in a room, you should check for copies of the command
  word in the room (using @scan).
& %!
& EXECUTOR
  The executor of a command is the object actually carrying out the command.
  This differs from the enactor, because the enactor is the object that sets
  off the command. In some cases, the enactor and the executor will be the
  same. There is a %-substitution, %!, that is replaced by the dbref # of
  the executor of the command.

  For example:
    @emit %N is the enactor and %! is the executor!
    > Cyclonus is the enactor and #6 is the executor!
    @create Box
    > Created: Object #10
    &DO_EMIT box=$emit:@emit %N is the enactor and %! is the executor!
    emit
    > Cyclonus is the enactor and #10 is the executor!

  In the first case, Cyclonus directly entered the command and was therefore
  both the enactor and the executor. In the second, Cyclonus set off the 
  command on the box, so Cyclonus was still the enactor, but the box was
  the object that was actually doing the @emit, and was thus the executor.

See also: ENACTOR, SUBSTITUTION
& EXITS
  An exit is a one-way link that takes you from its source room to its 
  destination room. To open an exit from a room, you must control that room.
  To open an exit to a room, you must either control the room or it must be 
  set LINK_OK. If an exit is set DARK is will not show up in the list of 
  obvious exits in a room.

  If an exit is set TRANSPARENT, someone who looks at the exit will also
  see the description and contents of the destination room. If an exit is 
  set CLOUDY, someone who looks at the exit will also see the contents of 
  the room beyond, but not its description. If an exits is set -both-
  CLOUDY and TRANSPARENT, the description but not the contents will be seen.
   
  If you have code on an exit (In an @asuccess or the like), note that
  [loc(exit)] is the exit's destination, and [home(exit)] is the exit's
  starting point. If an exit @emit's something, it will be heard in the
  source room.
   
(continued in exits2)
& EXITS2
  You can create an exit that sends those who go through it to their homes
  by typing '@link <EXIT>=home'.

  Starting with PennMUSH version 1.50p10, exits can have more than one 
  destination. To make an exit with a variable destination, open the exit 
  (using @open),  then type '@link <EXIT>=variable'. Finally, add an 
  attribute named 'DESTINATION' to the exit (&destination <EXIT>), which 
  will be evaluated for the dbref # of the destination room when the exit 
  is used. 
   
  For example:
  @open South <S>;s;south
  @link s=variable
  &destination s=[switch(rand(3),0,#100,1,#101,2,#102)]
   
  This exit would take you to either room #100, #101, or #102 depending on 
  the random number. 

  Anyone can create variable exits, but the destinations must be to places
  that the exit can normally @link to.

See also: @link, @open, link_ok, CLOUDY, TRANSPARENT, @firstexit
& FAILURE
  FAILURE  

  A "failure" usually occurs when you try to do something that is 
  governed by an @lock and you don't pass the lock. If you try to
  take a player or thing, and you don't pass their @lock, you will
  set off their @fail/@ofail/@afail attributes. If you try to go
  through an exit, and you don't pass its @lock, you will similarly
  set off its @fail/@ofail/@afail. Other failure sets include:

  Failing to enter an object (@efail, @oefail, @aefail)
  Failing to leave an object (@lfail, @olfail, @alfail)
  Failing to use an object (@ufail, @oufail, @aufail)
  Other failures (&<lock>`FAILURE, &<lock>`OFAILURE, &<lock>`AFAILURE)
    where the <lock> can be: FOLLOW_LOCK, PAGE_LOCK

  Many other things can also be locked -- see @lock and locktypes for 
  more information. However, there are failure messages at this time
  only for the above.

See also: @lock, @fail, @efail, @lfail
& GENDER
& SEX
  Gender on a MUSH is entirely up to you. You can set yourself (or any
  of your objects) to be male, female, neuter, or plural. If whatever
  is in the SEX attribute is not recognizable, the MUSH will assume 
  the object is neuter. Setting a gender attribute will enable 
  pronoun substitution by the MUSH. The SEX attribute is visual to
  anyone who wants to see it.

See also: @sex, SUBSTITUTION
& GLOBALS
& GLOBAL COMMANDS
  A command is "global" if it can be used anywhere in the world of the
  MUSH. The standard MUSH commands are all global, so this term is 
  usually used to refer to user-defined commands on objects in the
  Master Room of the MUSH. Global commands very greatly from MUSH to
  MUSH, but you can usually find MUSH-specific help on them by
  typing "+help". 

See also: MASTER ROOM, USER-DEFINED COMMANDS, EVALUATION
& HERE
  The word 'here' refers to the room you are in. For example,
  to rename the room  you're in (if you control it), you could enter 
  "@name here= <new name>". 
& HOMES
& HOME
  Every thing or player has a home, which is usually the room where
  it was created. You can reset your home or the home of any object
  you own with the @link command: @link <me|object>=<location>. You
  must also control <location>, unless that location (room or thing)
  is set ABODE or LINK_OK.

  When a player types 'home', s/he is sent back to the home room. When 
  a thing with the STICKY flag set on it is dropped, it also goes to 
  its home location. Note that if the FIXED flag is set on a player, 
  he/she cannot use the 'home' command.

  You can create an exit that sends players home by doing:
        @link <exit name>=home
  You can set the drop-to in a room to home by doing:
        @link <room dbref or "here">=home

See also: DROP-TOS, @link, STICKY, LINK_OK, FIXED, EXITS
& INTERIORS
  Here's a quick description of how to make things that can be entered:
        
  @create Car
  @desc Car=A shiny red car.
  @idesc car=You are sitting inside a luxurious sportscar.
  @set Car=enter_ok
  @oxleave car=climbs out of the car.   { The 'ox' messages are shown to 
  @oxenter car=climbs into the car.     { those OUTSIDE the object.
  @oenter car=joins you inside the car. { The 'o' messages are shown to 
  @oleave car=gets out of the car.      { those INSIDE the object
  @enter car=You get into the car.      { The plain messages are shown to 
  @leave car=You get out of the car.    { the one entering or leaving 
       
(continued in help interiors2)
& INTERIORS2
  Now, if you want people inside to be able to hear and communicate with 
  the outside, you also need to do the following.
   
  @set car=audible  (lets people outside hear what's being said in the car.
  @listen car=*     (lets people inside hear what's being said outside.
  @prefix car=From inside the car,
  @inprefix car=From outside,
  @filter car=* has arrived.,* has left.,joins you inside the car.,
    gets out of the car.
  @infilter car=* has arrived.,* has left.,* climbs out of the car.,
    * climbs into the car.

  (The filters will keep people on the outside from seeing the 'o'
  messages and people on the inside from seeing the 'ox' messages which
  is a good thing.)

See also: enter, leave, @prefix, @filter, AUDIBLE, @listen
& LAST & LASTLOGOUT
  LAST and LASTLOGOUT

  These attributes show the last times you connected and disconnected from
  the MUSH. 
& LASTSITE
& LASTIP 
  LASTSITE and LASTIP

  The LASTSITE attribute gives the name of the site you last connected from.
  The LASTIP attribute gives the IP address you last connected from.
  Mortals cannot set them.
& LINKING  

  You can link to a room if you control it, or if it is set 
  LINK_OK or ABODE. Being able to link means you can set the homes of
  objects or yourself to that  room if it is set ABODE, and can set 
  the destination of exits to that room if it is LINK_OK.

See also: LINK_OK, ABODE, @link
& LISTENING
  
  There are two basic ways to trigger action on the MUSH. The basic way
  is to type in commands such as 'look' or '@emit'. These commands are not
  seen or heard by other players, although the results of the commands may
  be.

  The other way is to "listen" for something said/emitted in your hearing.
  There are two ways to listen for something in a room. The easiest way
  is to use a combination of @listen and @ahear/@aahear/@amhear. 

  For example:
    > @listen Welcome Mat=* has arrived.
    > @ahear Welcome Mat="Welcome, %N!
    Breaker has arrived.
    Welcome Mat says, "Welcome, Breaker!"

(continued in help listening2)
& ^
& LISTENING2
  If you need an object to "listen" for more than one pattern, you can
  also use ^-patterns.  These work similar to user-defined commands, 
  using ^ instead of $. An object must be set MONITOR to have ^-patterns
  activated.

  Syntax:  &<attribute> <object> = ^<pattern>:<action list>

  For example:
  > @set Welcome Mat = MONITOR
  > &greet Welcome Mat = ^* has arrived.:"Welcome, %N!
  > &goodbye Welcome Mat = ^* has left.:POSE says as %N leaves, "Bye!"
  Grimlock has arrived.
  Welcome Mat says, "Welcome, Grimlock!"
  Grimlock has left.
  Welcome Mat says as Grimlock leaves, "Bye!"

  Such attributes can also be @triggered as if the ^<pattern>:
  did not exist.

(continued in help listening3)
& LISTENING3
  By default, ^-patterns work like @ahear. To have them work like
  @amhear, set the AMHEAR attribute flag on the attribute; to have
  them work like @aahear, set the AAHEAR attribute flag on the attribute
  (Note that the triggering object is whatever happens to be %#, so, for
  example, when you @set an object MONITOR, you are %# with regard to the
  "Object is now listening" message, and this message can be picked up
  with an ^pattern.)

  Additionally, unlike $-commands, @listen and ^-patterns are NOT
  inherited via @parent, unless the LISTEN_PARENT flag is set on the
  listener.

  Listen patterns are checked after the object's normal @listen attribute.

See also: @listen, @ahear, @amhear, @aahear, MONITOR, LISTEN_PARENT,
  USER-DEFINED COMMANDS

& LISTS
  The word "list" is used in the help files to refer to a string that
  is a series of smaller strings separated by one or more spaces. A list
  can also have its elements separated by some other kind of character --
  the separating character is called the "delimiter". 
  For example, the following are all lists:

    #6 #10 #14 #12
    Rumble|Krystal|Bobatron|Rodimus Prime   ('|' is the delimiter here)
    foo bar whee blarg 
    -eek- .boing. yawp #5 7
  
  Lots of MUSHCode depends on lists and manipulating them. Normally, a list
  is made up of similar items (so the fourth list in the example is NOT a 
  typical one).

See also: STRINGS, List Functions
& LOOPING
  Looping in an object can have its good parts and its bad parts.
  The good part is when you activate part of a program multiple times
  to exhaustively perform an operation.  This can be done like this:

    &PART1 object=<action list> ; @trigger me/PART2
    &PART2 object= @select <test for being done>=<false>,@trigger me/PART1

  Looping can be a problem when it goes on without stopping.  The @ps
  command can be used to see if you are looping.  Beware!  A looping
  machine that isn't @halt'd will drain your pennies while you are away
  from the mush!

See also: @ps, HALT, COSTS, @trigger
& MASTER ROOM
  
  The Master Room enables global commands and exits. Exits in the Master
  Room may be used from any location on the MUSH. All objects left in the
  Master Room are checked for user-defined $commands. Those $commands are
  considered global, meaning that they can be used anywhere on the MUSH. 
  Normally, only wizards will have access to the Master Room; if you have
  a global command that you would like to see enabled for the MUSH, speak
  to a wizard.
  
See also: EVALUATION, GLOBAL COMMANDS
& ME
  The word 'me' refers to yourself. Some things to do when 
  starting out: 
  1) give  yourself a description:      @desc me=<description>
  2) check your desc.:                  look me
  3) lock yourself:                     @lock me==me
  4) set your gender:                   @sex me=<male|female|neuter|plural>

See also: help newbie, help @lock, help @describe, help @sex
& MONEY
  The MUSH has a built-in money system, which gives a starting amount
  of money to new players and hands out a daily allowance thereafter.
  MUSH money (the default name is "pennies", but this may be different
  depending on the particular MUSH) is spent on some MUSH commands
  that are computationally expensive or alter the database. In 
  addition, every time you "queue" a command, it costs you a certain
  amount of money -- this prevents looping from getting out of control,
  since when all your money is spent, you can't queue any more commands.

  The money system can also be used on player-created objects by giving 
  them @cost/@payment/@opayment/@apayment attributes. When someone then
  pays the object by giving it the right number of pennies, the attributes
  are triggered.

See also: COSTS, give, @cost, @pay, @opay, @apay
& MUSHCODE
& SOFTCODE

  MUSHcode is the programming language available within the MUSH itself
  with which you can create user-defined commands and macros.  It is 
  sometimes called "softcode" to distinguish it from "hardcode", which is 
  the language that the source code for the MUSH server is written 
  in. (Incidentally, hardcode is written in the C programming language.)
  
  At its most basic, writing MUSHcode is just stringing together a series
  of commands that you would otherwise just type in one at a time.  You
  can store MUSHcode in attributes on any type of object you own or control
  (including yourself!).  The series of commands can be triggered by using 
  a user-defined command or by using @trigger.
  
(continued in help mushcode2)
& MUSHCODE2

  If you would like to learn more about mushcoding and how to create macros
  for yourself, the following help files may be useful.  However, the best
  way to learn is by obtaining a copy of Amberyl's MUSH manual and following
  the examples described there.  The manual is available by anonymous FTP
  from: ftp.pennmush.org in the directory /pub/PennMUSH/Manuals

  Related Help Topics (in no particular order)
  -------------------
  ATTRIBUTES    SUBSTITUTION    NON-STANDARD ATTRIBUTES 
  ENACTOR       EXECUTOR        USER-DEFINED COMMANDS
  DBREFS        EVALUATION      TYPES OF OBJECTS
  WILDCARDS     STRINGS         LISTS           
  ACTION LISTS

& NON-STANDARD ATTRIBUTES
  While there are many standard attributes in MUSH, objects can also have
  an unlimited number of attributes, with any name you wish to use. In the
  past, you were limited to attributes named VA-VZ, WA-WZ, XA-XZ; these
  are still available as standard attributes. However, it is strongly
  recommended that you use non-standard attributes and meaningful names
  in order to make maintaining your MUSHCode easier.

  To set a non-standard attribute, you can use these formats:
      &<attribute name> <obj> = <value>  OR
      @_<attribute_name> <obj> = <value> OR
      @set <obj> = <attribute_name>:<value>

  You can get the value of attributes using the functions v(), get(), and
  xget(). You can evaluate attributes using u(), eval(), and get_eval().
  All attributes can be used in attribute locks and can be 'owned' 
  independent of object ownership. 
  
See also: ATTRIBUTES, ATTRIB-OWNERSHIP, Attribute Functions, ATTRIBUTE TREES
& PARENT
& PARENTS
& OBJECT PARENTS
  
  Objects may have "parent" objects, from which they can inherit attributes.
  Once an object is given a parent, it may use the attributes on the parent
  just as if the attributes were on the object itself, including checking for
  $commands. Use the @parent command to change the parent of an object.

  Objects may have multiple levels of parents - thus, if #100 is the
  parent of #101, which is the parent of #102, object #102 checks itself,
  #101, and #100 for attributes. Attributes are checked on the object
  itself first, followed by its parent, followed by that parent's parent,
  and so forth. There is a (configurable) maximum length of the parent
  chain for an object; the default is 10.

  After the parent chain is exhausted, the type-specific ancestor is
  also checked in similar fashion.  See 'help ANCESTORS' for more about
  ancestors.

(continued in help parents2) 
& PARENTS2
 
  Note that the only properties inherited are attributes. In particular,
  flags and exits are NOT inherited from the parent object. Also, commands
  which walk the attribute list (such as "examine", the LATTR() function,
  the HASATTR() function, @set, and @edit) only affect attributes that are 
  on the object itself.
 
  There are some limitations to the use of @parent. The most important is
  that ^-pattern checking is not done on the parent of an object, unless the
  object is set LISTEN_PARENT. For the purposes of automated game checks, 
  the following attributes are not inherited: CHARGES, EALIAS, LALIAS, LAST, 
  LASTSITE, LISTEN, QUEUE, RQUOTA, SEMAPHORE, and STARTUP. 
    
  The attributes inherited from the parent are treated just like its
  own attributes by the child. Thus, when a $-command or @trigger is
  executed, "me", for example, refers to the child, not the parent,
  and the $-command's associated actions are performed by the child.

(continued in help parents3)
& PARENTS3
  Attributes with $-commands _are_ inherited from the parent and
  previous generations. Conflicts are resolved not by the $-command 
  name, but by the attribute name. If two attributes are in "conflict", 
  the child's attribute is used.

  For example:

  > &TEST #10=$test:@emit I'm the parent
  > &TEST #11=$check:@emit I'm the child
  > @parent #11=#10
  > test
  (nothing happens)
  > check
  I'm the child

(continued in help parents4)
& PARENTS4
  If a parent has the same $-command name in a different attribute, however,
  BOTH the parent and child commands will execute:

(continued from previous example)
  > &CHECK #10=$check:@emit No, I'm the parent!

  > check
  I'm the child
  No, I'm the parent!
 
  @parent is most useful when several objects use common attributes.
  It is slightly faster to have $commands on the child object which
  in turn @trigger or otherwise retrieve attributes inherited from
  the parent object, rather than having the $commands checked on the
  parent object.

(continued in help parents5)
& PARENTS5
 
  Parent-object $-command checking is at its most efficient when there
  are few or no attributes on the child. Also, each additional level
  of parents further reduces efficiency.  Finally, note that ancestors
  are *not* checked for $-commands.
 
  If you are "mass-marketing" your objects, you can create blank copies, 
  and @parent those copies to a template object. You can then customize 
  necessary attributes on the copy. When a buyer @chowns his copy, the 
  parent does not change, so unless you're putting data into the parent 
  that you want to make impossible to read, it's safe to allow the
  purchasers of your object to @chown their copy.

See also: @parent, $-COMMANDS, ATTRIBUTES, ANCESTORS
& POWERS LIST
  Powers can be granted only by wizards, using the @power command. 
  Powers cannot be granted to guest characters or players who are set
  UNREGISTERED. Powers normally give the player the ability to use a 
  limited set of wizard/admin powers.

  announce              Can use @wall command.  
  boot                  Can use @boot command.
  builder               Can use Builder commands.
  chat_privs            Can use Admin channels.
  debit                 Can use give with a negative amount.
  functions             Can use @function command.
  guest                 Guest. Restricted command set.
  halt                  Can @halt others' objects and do @allhalt.
  hide                  Can hide on the WHO list.
  hook                  Can use the @hook command.
  idle                  No inactivity timeout.
  link_anywhere         Can @link an exit to anyplace.
  login                 Not subject to login restrictions.
  long_fingers          Can do things remotely, like "get".
  many_attribs          Can exceed max_attrs_per_obj.

(continued in help powers2)
& POWERS2
& POWERS LIST2
  no_pay                Doesn't need money for anything
  no_quota              Has an unlimited quota
  open_anywhere         Can @open a link from any room.
  pemit_all             Can @pemit to HAVEN/ulocked players.
  player_create         Can use @pcreate command.
  poll                  Can use @poll command.
  pueblo_send           Can use xch_cmd and send pueblo tags
  queue                 Has queue limit equal to the size of the database.
  quota                 Can use @quota commands on other players.
  search                Can do @search, @stats, and @entrances on anything.
  see_all               Sees everything as if it were Visual.
  see_queue             Can do @ps on anyone, and @ps/all.
  sql_ok                Can perform SQL queries
  tport_anything        Can @teleport anything.
  tport_anywhere        Can @teleport to anywhere.
  unkillable            Can not be killed
  can_nspemit           Can use @nspemit and nspemit()

See also: help @power, and especially @power/list
& PUPPETS
  A thing is turned into a puppet by setting the PUPPET flag on it.
  A puppet object is an extension of its owner and relays everything
  it sees and hears to its owner, except if it is in the same room as
  the owner (a puppet with the VERBOSE flag will relay even if it's in
  the same room). Things relayed by the puppet will be prefixed by the 
  name of the puppet.

  Puppets are useful for keeping track of what is going on in two
  rooms at once, as extensions of a player (such as a pet, for example),
  or for testing code. 

&n