Introduction

This is intended as a reference manual to playing a MUSH. It is specifically written for PennMUSH 1.50, however many of the commands and concepts would apply to other MUSHes or MUDs.

The material is presented in "most-useful first" order. In other words, it starts off describing commands needed to "get started" and eventually covers "Wizard" commands and other commands needed by experienced players.

Note that some MUSHes may not have all options enabled. If a particular option described here does not work on a particular MUSH then the God of the MUSH may have disabled it. You could contact the Wizards on that MUSH for more information.

Under development

These pages are under development, and thus may not be complete. In particular, the sections on creating "things" (as opposed to rooms) are not written yet.

Other links

Another well-written beginner's guide to MUSH is at: http://www.ta-veren.org/mush/basics.html - this covers some things not mentioned below, such as using the help system, and MUSH jargon.

A lot of interesting MUSH instruction is also at: The 101 Schoolhouse at M*U*S*H.

Fundamentals

Player levels
Connecting, creating a character, changing your password
Describe yourself and set your gender
Looking around
Communicating - saying and posing
Communicating - whispering and paging
Communicating - using the chat channels
Looking at and using things
Being idle, away, or on vacation

Building

Introduction to the database
Rooms and exits
Building a room
Building hints

Locks

Introduction to locks
Types of locks
Special locks
Examples of locks
Lock messages

Reference

This section describes reference material (eg. all the flags, powers etc) without putting them in any particular context.

Flags
Lock types
Special locks
Substitutions

Fundamentals

You can play MUSHes on various levels, grouped roughly as:

Player, or "mortal" (one who participates in the Virtual World, but does not change it)
Builder (a player who modifies the Virtual World)
Wizard (one with extra powers, who builds, enforces the "theme", helps other players, and arbitrates disputes)
God (the owner/controller of the MUSH)

It is not "good" or "bad" to play at a particular level. If you want to be the God of a MUSH, download a copy of the server and run it on your own PC. You might not necessarily have many players other than yourself, but at least you can do whatever you want. On the other hand, being a normal "mortal" player means that you can enjoy the fruits of the labours of others.

Connect

Connect to a MUSH by using Telnet or a MUSH client program (such as MUSHclient). You normally specify a "port" number in addition to a MUSH address.

After establishing a connection (and seeing various welcome messages) but before connecting to a character, you can type WHO to see who is online at present. This must be typed in upper case:

 WHO

Player Name  On For   Idle   Doing
 Nick         00:29   0s     Resting after a long laugh
 Gandalf      00:35   12s    Exploring the larger cave
There are 2 players connected.

To create a new character (your virtual reality character), type:

 create <name> <password>

for example:

 create Freddie swordfish

The password is case-sensitive, that is, upper and lower case letters are treated differently.

If you have played before on the MUSH, "connect" to your previous character, like this:

 connect Freddie swordfish

Guest logons

Some worlds allow you to connect as a "guest" character, normally by typing:

 connect guest guest

This is so you can explore the world and decide whether you like its theme before going to the trouble of creating a character. If you aren't sure if you are going to like playing on a particular MUSH, then using the "guest" character is courteous to the MUSH administrators. Otherwise you may create a character (and thus increase the size of the MUSH "database") which only gets used once.

Some MUSHes may not allow players to create characters on-the-fly (in other words, they may disable the "create" command).

There would be various reasons for not allow unrestricted character creation, some of them being:

• The world is very popular, and it is necessary to restrict the number of characters that play at one time
  There have been some "nuisance" players on the world. Even if the wizards "boot" them off the world, they can easily create another character and continue to harass other players. By forcing new players to register the wizards can control who plays.
  By registering via email, the wizards know who you are (or at least, your email address) so they have some redress if you are a nuisance.
  The world may be "under construction" and not yet open to the public.
  The world may be for a group of friends, and never intended to be opened to the public.
  The world may have "adult" or other content, making it unsuitable for general unrestricted players.
  The wizards may wish to enforce a "theme" and only allow players to play once they have agreed to the theme.
  The world may be for special purposes (eg. victims of sexual abuse) and not open to anyone who does not fall into that category.

On these worlds you normally request a character by emailing the wizards or administrators, who then create that character, and then email you back your character name and password. In some cases, you can connect as a "guest" and then page a wizard to ask for a character to be created.

If it is possible to have a player created this way, the "announce" message (which is displayed when you connect to the world but before you connect to a character) will normally tell you which method to use.

To leave the MUSH, just type:

 QUIT

The word QUIT must be typed in upper case.

Logging out

To disconect from your current character, and reconnect under a different one type:

 LOGOUT

The word LOGOUT must be typed in upper case.

You might use LOGOUT after exploring a world as a guest, and deciding you wanted to create your own character.

To change your password, type:

 @password oldpassword = newpassword

Give yourself a description and gender

Once connected you should describe yourself and assign a gender to your virtual character (not necessarily your "real" gender). By having a description and gender you make it easier for other players to "see" you, and relate to you. Try to make your description interesting, and "in character" with whatever you want to be in your virtual world.

@desc me = You see a lively-looking young man, wearing a long, brown coat. He has piercing blue eyes that seem to stare right through you. He has long, untidy hair, and a look of quiet desperation.
Do not press "enter" in the middle of your description, just let the program wrap around automatically. It is really one long "string" of text. If you want to insert line breaks inside the description, you can use "%r" which will insert a "return" when it is displayed.

To see your description, type:

 look me

Similarly, to see the description of someone else, type "look <their name>"

If you want to see when other people look at you, you can type:

 @adesc me = think %N just looked at you!

"Think" is a verb that just sends you a private message.

%N is a "message substitution" symbol that is replaced by the name of the person who looks at you.

@sex me = male

(Or female as the case may be).

Your (virtual) gender is used in various MUSH actions to customise the gender of someone's behaviour. For example:

 Gandalf picks up his sword.

It is also sensible here to "lock" yourself:

 @lock me = me

The reasons for this will become apparent later.

Type "look" (or just "L") on its own to see a description of the current location. For example:

look

The Town Square
         You are in the town square. All around you, peasants haggle over
         their wares as unwashed urchins scramble through the legs of tables 
         topped with smelly produce. 
         Contents:
         A fig tree
         Nick
         Obvious exits:
         north, south, pub, Travel Centre (TC) and caravan

The first line shows the "name" of the place (The Town Square). The next few lines are its description. Then follows a list of contents (if any) and obvious exits (if any). The contents can be people (other players) or things.

You can also look at people, things and exits by typing "look <thing>", for example:

 look me
 look Gandalf
 look Travel Centre
 look Gold Watch

It is worth being aware that other players may notice you looking at them (as in real life), so you should probably not look at them repeatedly. The method for doing this (in case you want to know if someone looks at you) is described under describing yourself.

To move around, you can normally type the name of an "obvious exit", like this:

 pub

The designer of a room may place an abbreviation for an exit (like TC for Travel Centre) as part of the exit description. In that case, you just have to type TC to go in that direction.

In many cases you can try using the directions of the compass (north, south, east, west) as well as up and down.

To see what you are carrying, type "inventory". For example:

 inventory
 You aren't carrying anything.
 You have 140 Pennies.

(You can abbreviate "inventory" to "invent" or just "i").

The currency, which can be Pennies, Dollars, Pounds, Yen, Bucks, or whatever the God of the MUSH has set up, is needed to build and to do certain other actions. You normally get an allowance of currency each (real) day that you connect.

You can talk out loud to others in the current room by using "say", for example:

 say Hello everyone!
 You say, "Hello everyone!"

Everyone else sees:

 Freddie says, "Hello everyone!"

Since "say" is used so often, you will probably want to use the abbreviated form, namely:

 "Hello everyone!

Putting a double-quote at the start of the line is shorthand for "say". You do not need to use a closing quote.

You can also "emote" by using "pose", like this:

 pose looks around and sighs quietly.
 Freddie looks around and sighs quietly.

The "pose" command, which is also used a lot, can be abbreviated as a colon:

 :smiles.
 Freddie smiles.

If you want no space after your name, use a semicolon, like this:

 ;'s watch beeps
 Freddie's watch beeps

Everyone in the same room with you will hear what you say, and see what you pose.

You may wish to have a private conversation with another player, and not be heard by others in the room. To do this, use "whisper" (or "wh"), for example:

 wh nick = Good to see you again.
 You whisper, "Good to see you again." to Nick.

You can also whisper a "pose", by adding a colon, like this:

 wh nick = :winks and smiles.
 Nick senses, "Freddie winks and smiles."

If there is someone you want to talk to, but who isn't in the same room as you, you can "page" them, like this:

page nick = Where are you?
 You paged Nick with 'Where are you?'.

Once you have paged someone, you can leave their name out in subsequent messages, like this:

 page = May I join you?
 You paged Nick with 'May I join you?'.

To check who you last paged, just type:

 page
 You last paged Nick.

"Page" may be abbreviated to "p".

You can also "pose" through a page, like this:

 p nick = :laughs!
 Long distance to Nick: Freddie laughs!

Nick will see:

 From afar, Freddie laughs!

Chatting

The MUSH has a built-in "chat" system. This lets you talk with other players who are not necessarily in the same room. This is useful if you are moving around and exploring, and more versatile than using "page" as everyone on that "chat channel" can hear what is being said.

Listing chat channels

To start, see what channels are available:

 @channel/list
 Name   Privs  Quiet
 Newbie Public  No
 Theme  Public  No
 OOC    Public  No

Choose an appropriate channel (Newbie for new players, Theme for messages "in theme", OOC for Out Of Character messages), and then join the channel, like this:

 @channel/on newbie
 Channel added.
 <Newbie> Freddie has joined this channel.

To talk on the chat channel, type a "+" followed by the channel name, like this:

 +newbie Hi all you newbies!
 <Newbie> Freddie says, "Hi all you newbies!"

Anything that identifies the channel uniquely will do, so you could say:

 +n meet you at the pub
 <Newbie> Freddie says, "meet you at the pub"

You can also "pose" using a colon, like this:

 +n :winks
 <Newbie> Freddie winks

Leaving a chat channel

To remove yourself from a chat channel:

 @channel/off newbie
 Channel deleted.

You can join more than one channel.

Look at a thing

If you see an object in the room with you that does not seem to be a player, try looking at it for more information:

 look fig
 A fig tree
 A medium size fig tree bearing many figs.

Taking things

 take fig
 The tree is firmly rooted to the ground!

In this case, the "take" has failed (because you didn't pass its "lock", explained later), so you haven't taken it.

However, taking something that doesn't fail looks like this:

 take key ring
 Taken.

You can now do an inventory to see that you have them:

 invent
 You are carrying:
 Key ring
 You have 130 Pennies.

You can drop the object if you wish:

 drop key ring
 Dropped.

Using things

You can try to "use" objects:

 use wand
 Used.
 There is a flash of lightning!

You can give things or other players your money:

 give machine = 10
 You paid 10 Pennies.

If the thing does not require money, or requires less than you give it, you will get the excess back in "change".

Giving things to other players

You can give other players things you are carrying:

 give nick = key ring
 Given.

If you are going to be away from your terminal for a while, but don't want to disconnect, you can set an "idle" message which will be shown to people who try to page you:

 @idle me = Away for a while.

A more complex method is to set up an automatic "idle" message which is automatically sent if you are idle for more than a preset period of time, like this:

 @idle me =[switch(gt(idlesecs(%#),120),1,I'm idle. Use @mail,)]

In this case, the message "I'm idle. Use @mail" is sent if you are idle for more than 120 seconds (two minutes).

You can also set a message to be sent to people if they page you when you are disconnected, like this:

@away me = I'm not connected. I usually connect between 8 pm and 10 pm daily.

You can use this message to tell people when best to catch you.

You can tell people what you are currently doing, like this:

 @doing Exploring the eastern caves

Then, if someone does a WHO, they can see what you are doing:

 WHO
 Player Name  On For   Idle  Doing
 Gandalf      00:17     0s   Exploring the eastern caves
 Strider      00:30     3s   Available to help newbies
 Freddie      02:27     5m   Exploring the larger cave
 There are 3 players connected.

If you are going away for a while, you can set yourself as "on-vacation", like this:

 @set me = on-vacation

This may help prevent you from being purged from the MUSH for inactivity.

Players
Rooms
Exits
Things

Database number (ie. where in the MUSH database it is) - Usually represented as: #nnn
Name - the name of the object (eg. "Merlin", "A table", "The Inn" and so on)
Location - where the object is
Contents list - what it contains (inventory for players, objects in a room)
Owner - who owns this object
Pennies - how much "currency" the object owns (might not be called "pennies" as such)
Zone - which "zone" the object belongs to
Flags - various flags which can be on or off, such as "wizard", "dark" and so on
Locks - these control who can do what to whom.
Attributes list - attributes of the object, such as its description, failure message and so on.
Powers - Special powers the object may use

 examine me
 examine here

 examine here
 The Town Square(#9RnAJ) is owned by Gandalf

Players
Things
Exits

 Room #800 (Cave) contains an exit #802 (West) linked to #801 
 Room #801 (Waterfall) contains an exit #803 (East) linked to #800            

Only certain people can use an exit
You have to be a certain sex to use an exit
You have to be carrying a special object (eg. a key) to use an exit

 You must be carrying the Wand of Gandor to go east!

There are three main commands for building rooms and exits:
@dig - Creates a new room
@open - Creates an exit linking one room to another
@link - Links an existing exit to a room

Syntax:

 @dig Room-name = Exit-to-room , Exit-from-room

or in more detail ...

 @dig[/teleport] <name> [= <name>[;<other name>]*[,<name>[;<other name>]*]]

This creates a new room with the specified name and displays its number. This costs 10 pennies. If the "= <name>" option is used, the exit will be opened and linked for you. The ",<exit>" option will link a reverse exit for you.

If the "teleport" switch is supplied, the digger will be teleported into the new room automatically.

Examples:

The ; symbol means that you may enter the exits by typing 'w', or 'e' also. Only the first Exit name is displayed in the Obvious exits list.

Syntax:

 @open Exit-to-room-name = #Room-number , Exit-from-room

or in more detail ...

 @open <direction>[;<other direction>]* [=<number>][,<dir>[;<other dir]*]

This creates an exit in the specified direction(s). If <number> is specified, it is linked to that room. Otherwise, it is created unlinked. You or anyone else may use the '@link' command to specify where the unlinked exit leads. Opening an exit costs 1 penny. If you specify <number>, linking costs 1 more penny. If you specify a room, you may also specify an exit leading from that room back to the current room. This second back exit costs the same as the forward one.

Use "@open" when you already have a room created, but want to add an exit to go to it (and possibly from as well).

Examples:

Syntax:

 @link object = #Room-number

This sets the destination for an exit to be the nominated room number. For example:

 @link East = #88

You can use the @link command to change the destination of a previously set-up exit.

You can also set up a "variable" exit, if you are a wizard, by using:

 @link object = variable

If you do this, then you must set up a "DESTINATION" attribute on the exit. This attribute is evaluated at runtime to see where to send the player to.

By using @link you change where an exit leads to, however to change where an exit leads from you must teleport that exit to the appropriate room.

For example, if you had an exit numbered #80, which currently leads from room #81, but you want it to lead from room #82 you would:

 @teleport me = #81
 @teleport #80 = #82

Describing your new rooms, and its exits

The rooms you create with the above commands are rather sparse. To make them more interesting you should describe the room, and its exits, by using the @desc command.

For example:

@desc here = You're at a low window overlooking a huge pit, which extends up out of sight.
A floor is indistinctly visible over 50 feet below. Traces of white mist cover the floor
of the pit, becoming thicker to the right. Marks in the dust around the window would seem 
to indicate that someone has been here recently. Directly across the pit from you and 25
feet away there is a similar window looking into a lighted room. A shadowy figure can be
seen there peering back at you.

@desc east = A foreboding passage leads East.

@desc west = A low crawl over crumbling rocks leads West.

By using the @name command you can rename something.

For example:

 @name here = Great Western Chasm

Putting locks on exits

Very frequently you will want to "lock" an exit. This prevents unconditional passage through that exit. As a simple example, say you want to prevent anyone passing through the "east" exit unless they are carrying an object called "key" ...

 @lock east = +key

In addition to locks, you will probably want to put "success" and "failure" messages on your exits.

Locks and messages are described in the following pages.

General

If making a number of rooms, draw a map (on paper) so you don't get confused about where each room and its exit is.

Descriptions, names, locks and messages

Describe each room (use @desc).
Make an appropriate name (use @name to change an object's name)
Make exits to and from each room, as appropriate.
Put locks on exits to enforce appropriate behaviour.
Use lock messages (eg. @succ, @fail, @osucc, and @ofail) on locked exits.

Room flags

Set your room ABODE if you want others to be able to make it their home (ie. so they can use the @home command on it)
Set your room DARK if you don't want people to see any exits, players or things in the room.
In a dark room, set some exits LIGHT if you want them to be visible.
Set your room LINK_OK if you want other players to be able to link exits to it (ie. so they can use the @link command to link to it)
Set your room NO_TEL if you don't want players teleporting out of it.
Set your room TRANSPARENT if you want to show where the exit leads to.

Example of setting flags

To set a room DARK, for example:

 @set here = dark

To set a room not DARK:

 @set here = !dark

Set your exits CLOUDY if you want players to be able to see the contents of the room that the exit leads to through the exit (if someone looks at the exit)
Set your exits DARK if you want to have hidden exits.
Set your exits TRANSPARENT if you want to show where the exit leads to (if someone looks at the exit)

Locks

Introduction
Locks are a very important part of MUSH building - they help give the world its "flavour", by enforcing rules and conditions.

Basically you could define a lock thus:

A locked object cannot be used unless the thing attempting to use it passes the lock
This is a rather broad definition. There are various types of lock (use, mail, enter, teleport) and so on, so the word "use" in the definition above has a fairly general meaning.

Examples of locks

A locked exit prevents players from passing through it. eg.

 @lock east = sex:m*

This only allows "male" character to use the "east" exit.

A locked player or object cannot be taken (picked up). eg,

 @lock mirror = #0

This prevents anyone from taking the mirror. 

A locked room can display a different description than when it is unlocked.

 @lock here = Iswizard/1
 &Iswizard here = [hasflag(%#, WIZARD)]
 @succ here = You notice a secret exit behind the fireplace.

This would show a description about a secret exit to wizards only.

You should generally set a "success" and "failure" message on any object which is locked, so that the player attempting to pass the lock sees an explanatory message. For example:

 @lock east = +key
 @succ east = You unlock the door and go through it.
 @fail east = You must be carrying the key to go through this door.

You should also set "other success" and "other failure" messages on a locked object, so that others in the same room see what is happening to the player.

 @osucc east = unlocks the door and passes through.
 @ofail east = tugs uselessly at the door.

These messages are covered in more detail in a subsequent page.

Click on Lock Messages for more details about messages that are triggered by attempting to use locked objects.

 @lock[/<switch>] <object>=<key> 

Locks <object> to a specific key(s). <object> can be specified as <name> or #<number>, or as 'me' or 'here'. Boolean expressions are allowed, using '&' (and), '|' (or), '!' (not), and parentheses ('(' and ')') for grouping. To lock to a player, prefix their name with '*' (ex. '*Moonchilde').

Example:

 @lock Purse = me|*Darling

will lock object purse so that only you or player Darling can take it.

There are further topics on locks:
Types of locks
Special locks
Lock messages

A @lock without a "switch" is a "basic lock". Other types of locks are described below. For example, to set an "enter lock" you would use:

 @lock/enter foo=bar

@lock/use is equivalent to @ulock, and @lock/enter to @elock.

Special locks

You pass a normal lock if you either:

• Are the key
• Carry the key

       @lock foo = bar         

Special locks behave differently as described below. Each one has a special "symbol" (such as "+" for carry) to distinguish it from a normal lock.

There are six types of special locks:

• Indirect
• Carry
• Is
• Owner
• Attribute
• Evaluation

These are described below...

Locks examples

Below are some examples of using locks, to help you to formulate your own:

Lock something so no-one can take it

 @lock mirror = #0

This just uses the "basic lock" to lock the mirror against database object #0 (the initial room). Since it is very unlikely that the player will be or carry that room, the lock always fails, thus the object cannot be taken.

 @lock north = sex:f*

This checks the attribute "sex" to be anything that starts with "f".

 @lock north = sex:m*|sex:f*

By using the "or" symbol ("|") you can check for one attribute or another.

 @lock out = desc:*

This uses a "wildcard" character ("*") to ensure that the attribute "DESC" is not empty.

 @lock out = desc:*&(sex:m*|sex:f*)

This uses the "and" symbol ("&") in addition to the "or" symbol, as well as parentheses to group the "sex" check.

 @lock purse = me

This is useful for locking your possesions.

@lock south = Iswizard/1
         &Iswizard south = [hasflag(%#, WIZARD)]

This uses an "evaluation lock" to evaluate an attribute "Iswizard". This attribute checks to see if the player attempting to pass the lock ("%#") has the flag "wizard". If so, it returns "1". This is then checked for in the lock.

@lock south = Iswizard/1&sex:m*
         &Iswizard south = [hasflag(%#, WIZARD)]

This uses the "and" operator to combine an evaluation lock with an attribute lock.

@lock me = me

Without this lock, other players can pick you up and take you places.

@lock/page me = !*Bozo

This prevents player Bozo from paging you.

You can lock yourself against all pages by using:

@lock/page me = #0

Another method of avoiding all pages is to set the "haven" flag on yourself, ie.

@set me = haven

 @lock/speech here = !*Bozo

This prevents player Bozo from speaking in this room. Note that this lock does not affect wizards.

Lock an exit so you must be carrying something to pass through it

 @lock west = +key

Players must be carrying "key" to go west.

Lock all exits against the same thing

 @lock north = desc:*&(sex:m*|sex:f*)
 @lock south = @north
 @lock east = @north
 @lock west = @north

By using an "indirect lock" (indicated by the "@" character) you only need to type in a complex lock once, and then lock other things "indirectly" against that lock.

This not only saves you typing the lock over and over again, but makes it easier to change the lock. If you need to change the lock, you only need to change it once.

When using locks it is good practice to put a "success" and "failure" message on the object being locked. This helps tell the player why (or when) s/he succeeded or failed to use the object. For example:

 @lock east = +key
 @succ east = You unlock the door and go through it.
 @fail east = You must be carrying the key to go through this door.
 @osucc east = unlocks the door and passes through.
 @ofail east = tugs uselessly at the door.

There are six different type of message/actions you can put on a basic lock. They are:

1. What you see if you pass the lock
2. What you see if you fail the lock
3. What others see if you pass the lock.
4. What others see if you fail the lock

   These messages are usually preceded by "o" (for "others"), for example "@ofailure".

5. An action that is taken if you pass the lock.
6. An action that is taken if you fail the lock

   These messages are usually preceded by "a" (for "action"), for example "@afailure".

In detail, the commands to set these messages/actions are as follows.

The general syntax is:

<command> <object> [ = <message> ]

or

<command> <object> [ = <actions> ]

<object> can be a thing, player, exit, or room, specified as:

• <name>
• #<dbref>
• 'me'
• 'here'

If you do not specify an action or message then the action or message is cleared. For example:

 @fail east

This would clear the @fail message on the east exit.

Of course, @failure messages (and their variants) are displayed when someone fails to do one of the above.

Some other lock types also trigger messages and actions. These are:

1. Drop - @drop, @odrop, @adrop
2. Enter - @enter, @oenter, @oxenter, @efailure, @ofailure, @aenter, @aefailure
3. Leave - @leave, @oleave, @oxleave, @lfail, @olfail, @aleave, @alfail
4. Page - @haven
5. Teleport - @tport, @otport, @oxtport, @atport
6. Use - @use, @ouse, @ause

You do not necessarily have to set a lock on an object to use some of the above messages. For example, the @use message or @success message can be used for unlocked objects, as an unlocked object always succeeds in the attempted action. For example:

 @create wand
 @use wand = You wave the wand, but nothing happens.
 @ouse wand = waves %p wand, but nothing happens.
 @success wand = You are now carrying the wand.
 @drop wand = You have put the wand down.
 @odrop wand = puts %p wand down.

The above messages will be shown when you use, take and drop the wand respectively.

The %p in the above messages will be replaced by "his/her/its" as applicable. See substitutions for more details.

If you wish to copy or move an attribute you can use @cpattr or @mvattr, as follows:

 @cpattr <obj>/<attr> = <obj1>[/<attr1>] [,<obj2>/<attr2>,<obj3>/<attr3>,...]
 @mvattr <obj>/<attr> = <obj1>[/<attr1>] [,<obj2>/<attr2>,<obj3>/<attr3>,...]

 @cpattr test/va = test/vb, cube/va, tribble/foo

would copy the VA attribute from object "test" to VB on "test", VA on "cube", and FOO on "tribble". <objN> is matched as if you were performing a @set on it.

If you leave out the destination attribute, the attribute is copied to one of the same name on the new object. For example:

@cpattr test/va=cube

@mvattr performs an @cpattr and then removes the original attrib.

Parenting

As an alternative to copying attributes you may find it easier to use @parent, to make an object automatically get its attributes from its parent.

You can see an object's attributes by using "examine", for example:

ex wand

wand(#92n)
Type: Thing Flags: NO_COMMAND
Owner: Nick  Zone: *NOTHING*  Pennies: 1
Parent: *NOTHING*
Powers:
Warnings checked: none
Created: Sun Jul 27 13:12:56 1997
Last Modification: Sun Jul 27 13:15:10 1997
ODROP [#66$]: puts %p wand down.
OUSE [#66$]: waves %p wand, but nothing happens.
DROP [#66$]: You have put the wand down.
SUCCESS [#66$]: You are now carrying the wand.
USE [#66$]: You wave the wand, but nothing happens.
Home: Great Western Chasm(#88Rnt)
Location: Nick(#66PUeA)

You can see the ODROP, OUSE, DROP, SUCCESS and USE attributes in the list above.

To examine an individual attribute, append its name to the "examine" command separated by a slash. For example:

ex wand/succ

SUCCESS [#66$]: You are now carrying the wand.

Reference

Flags

Everything in the universe of a MUSH (Rooms, Exits, Objects, Players, etc...) are represented in the same way at the program level. A room merely has the room flags set and a player has the player flags set. In addition, flags also give objects abilities or qualities. For instance, a wizard has the wizard flag set. That is what lets the program know he may use wizard abilities. An object or room may have the dark flag set. In the case of an object, this makes the object invisible to normal eyesight. In the case of a room, the room becomes too dark to see other objects or players.

Flags list

For more specific information on a particular flag, click on the flag name.

Flags - upper case

Flags - lower case

Some flags may not be enabled on some MUSHes.

Some flags only apply to certain types of objects. Objects can be one of:

Player
Room
Thing
Exit

Flags in the "All" category below can be applied to any object type (for example, any type of object can be DARK). Therefore any object type can use the flags in the "All" category, and in addition use any flag in its own category. For example, a player could be DARK and TERSE.

Examining flags

By examining an object you can see its flags, in both brief and long form. The brief form is just the flag letter (from the table below). The long form is the name of the flag. For example:

 examine me
 Nick(#66PQUeA)
 Type: Player Flags: QUIET UNFINDABLE ENTER_OK ANSI

Notice that the upper and lower-case flags are different. For example, R=Room, but r=Royalty.

In the example above the flags are "PQUeA", namely:

 PLAYER QUIET UNFINDABLE ENTER_OK ANSI

The #66 before the flags is this object's database number.

For objects you own (such as yourself, and objects you created) you are automatically shown their flags, for example:

 look
 Nick's House(#70Rn)
 Obvious exits:
 Town Square

This helps you to see an object's characteristics at a glance. If you find this annoying you can set yourself "myopic" in which case you don't see the database number and flags. In other words:

 @set me = myopic

@set <object> = <Flag>

For example:

 @set me = quiet
 @set here = dark

 @set <object> = !<Flag>

For example:

 @set me = !quiet
 @set here = !dark

ABODE

If a room is set ABODE, any player can set his home there, and can set the homes of objects there. It does not mean that a player can open an exit to that room, only that they can set their home there. This flag should not be set unless you want to make the room a public 'living area'.

When set on a player, this flag bold-hilites the names and owners of attributes when the player "examines" an object. This makes it much easier to pick out where attributes begin and end, when examining complex objects. You must be using a terminal which supports ANSI control codes in order for this to work.

See also the COLOR flag. If COLOR is not set, and ANSI is, you will see vt100 ANSI codes, but not color ANSI codes.

Exits that are AUDIBLE propagate sound to their destinations. In other words, any message - emit, say, or pose - that is heard in the source room of the exit is passed on to the contents of the exit's destination room. The message is prepended with the exit's @prefix attribute; if there is no @prefix, the default is used:

 "From <name of the exit's source room>,"

Messages matching a certain pattern may be filtered out by using @filter on an exit; read 'help @filter' for more.

In order for exits in a room to propagate sound, the room must also be set AUDIBLE. If the room is audible, exits that are audible show up on a @sweep, even if they are set DARK.

This flag is also valid for things. If an object is set AUDIBLE, any messages which originate from its contents will be broadcasted to the outside world. This makes it very simple to program vehicles. Like AUDIBLE on exits, the message is prepended with the thing's @prefix attribute, and messages matching certain patterns may be filtered with @filter. If there is no @prefix, the message will be prepended with "From <name of AUDIBLE object>," The AUDIBLE object does not receive its own propagated messages.

The AUDIBLE flag allows most "emitters" (objects that listen for messages and broadcast them to other rooms) to be eliminated. The message is propagated only to the next room and no farther, so there is no danger of looping.

This flag, when set, allows you to transfer ownership to another player. To set it, you must be carrying the object. You also have to be in the room if you want to set this flag on rooms or exits. After this flag is set, the new player may gain ownership of the object by using the @chown command.

If this flag is set on a (non-TRANSPARENT) exit, when a player looks at the exit they will see the contents of the destination room following the exit's description.

If the flag is set on a TRANSPARENT exit, when a player looks at the exit they will see only the description of the destination room following the exit's description, and will not see contents.

When set on a player, this flag allows the player to see ANSI color. The ANSI flag must also be set.

This flag applies only to players and it shows if the player is connected or not. Thus, each time you are connected to the game, you should see the 'c' flag set, otherwise, you are DEAD! You cannot reset this flag, and it is used internally by the code for things like tabulating players for the WHO list, etc.

If a room is DARK, then no items are shown when a person 'looks' there. If a thing is DARK, then "look" does not list that object in the room's Contents:, and if an exit is DARK, it doesn't show up in the Obvious Exits: list. Puppets and objects that can listen cannot be DARK. Note that players, puppets, and other "hearing" objects still trigger enter/leave messages when in DARK areas. There is a config option for "full invisibility": players and objects that are dark will be slightly disguised in speech and poses. Such actions by these objects will show as being from Someone or Something depending on whether it was an object or wizard player.

Players who can hide from the WHO list should use @hide/on and @hide/off to control this, not the DARK flag. While any player can turn off their DARK flag, only Wizards can set their DARK flag.

Wizards who are DARK "disappear" completely -- they are not on the WHO list, do not announce connects and disconnects, etc.

The DEBUG flag is used for debugging MUSHcode. It is meant to be used in conjunction with the VERBOSE flag. If an object is set DEBUG, all parser evaluation results will be shown to the object's owner, in the format: #<object dbref>! <string to evaluate> => <evaluated string> Note that verbose output is "#obj]" - debug output is "#obj!".

Because the parser does recursive evaluations, you will see successive messages evaluating specific parts of an expression. This enables you to pinpoint exactly which evaluation is going wrong.

Objects run under this flag are computationally expensive. Avoid leaving it set on objects.

During a DEBUG evaluation, the flag is temporarily reset; therefore, a test for HASFLAG(), FLAGS(), etc. in the debug execution will show that the DEBUG flag is not set (although the actual output will be correct.)

 Example - create "test", and set it DEBUG. 
 > @va test=$wc *:"String %0 has [strlen(%0)] letters and [words(%0)] words.
 > wc This is my test string
 #14! String %0 has [strlen(%0)] letters and [words(%0)] words. 
          => String This is my test string has 22 letters and 5 words.
 #14! strlen(%0) => 22
 #14! %0 => This is my test string
 #14! words(%0) => 5
 #14! %0 => This is my test string
Test says, "String This is my test string has 22 letters and 5 words."

The DESTROY_OK flag allows anyone who is holding an object to @destroy it. This is good for "temporary" objects like "Can of Cola". DESTROY_OK takes precedence over SAFE.

If an object or person is ENTER_OK, other players may enter the object or person by using 'enter <object/person>'. Only objects which are ENTER_OK may be entered, regardless of the enter lock. Players must also have the ENTER_OK set if they wish to be able to receive things given to them by other players via the 'give <player> = <object>

An exit links one room to another room. If an exit is set DARK it will not show up in the list of obvious exits in a room.

When this flag is set on a player, it prevents them or any of their objects from using the @tel or home command. The only exception is that a player's objects are permitted to @tel themselves to the player's inventory.

If a room is set floating, you will not be notified every 10 minutes or so that you have a disconnected room.

A disconnected room may mean (depending on how the MUSH is configured) a room that can't be reached from room #0, or a room that can't be reached from room #0 and has no exits.

When set on an ANSI player, this player causes the ansi code to reset the font color to white to be sent after everything the player sees. Necessary for players with broken ansi clients which "bleed".

This flag is aliased to "WEIRDANSI" as well.

When set on a player, it disables him from doing anything except moving and looking. He cannot talk, page, build, pose, get or drop objects. (Yet another consequence of annoying the wizards.) Only wizards can set this flag.

Used internally for the @destroy command, it is set on things that are scheduled to be destroyed. To prevent a GOING object from being destroyed, use the @undestroy (or @unrecycle) command. You can no longer @set the object !GOING.

While this flag is set, the object cannot perform any mush actions, listen, be triggered, evaluate functions or substitutions, etc.

If a room is HAVEN, you cannot kill in that room. If a player is set HAVEN, he cannot be paged.

INHERIT is a security flag used to prevent objects without authorization controlling other objects. There are two classes of objects:

"Inherit" objects include:

1. Objects with the INHERIT flag
2. Objects owned by a player with the INHERIT flag
3. Players
4. Objects with the WIZARD flag

Only "Inherit" objects (with the same owner) can control other "Inherit" objects. An exception is that a non-"Inherit" object may @trigger any Link_Ok object with the same owner.

For zoned objects, the INHERIT flag protects against an object from being controlled by anything not owned by its owner. This prevents someone who controls a zone from doing things like @forcing an INHERIT object to @force its owner.

Note that only Wizard objects can control Wizards, and only Royalty objects can control Royalty, regardless of INHERIT status.

Here are the rules of control (which apply in order):

1. Only God controls God
2. Wizards control everything.
3. You control anything you own
4. Your INHERIT objects control you and anything you own. If you are set INHERIT, all of your objects are effectively INHERIT.
5. Your non-INHERIT objects control your other non-INHERIT objects
6. Only Wizards control wizard objects, and royalty royal objects
7. You control objects (not players) in a zone for which you pass the ZMO's zone lock
8. You control objects (not players) owned by a Zone Master for which you pass the Zone Master's zone lock.
9. Anybody controls an unlinked exit, even if it is locked. (Builders beware!)

These flags may be used by the MUSH to support some form of Judged RP system. Or they may not be compiled in.

When a room is set JUMP_OK, then that room can be teleported into by anyone.

Objects, players, and exits which have the LIGHT flag set on them (and are not also set DARK) appear in the contents of DARK rooms.

If a something is LINK_OK, anyone can link exits to it (but still not from it). Also, LINK_OK overrides the INHERIT protection against @trigger (although not @force or @set).

When set on a player, this flag notifies that player when anyone connects to or disconnects from the MUSH. It is valid only for players, and must be set by a wizard (although royalty may set themselves MONITOR).

When set on a thing or room, this flag activates the ^ listen patterns on the object. Objects which have ^ listen patterns but are not set MONITOR do not check those patterns, although they are flagged on a @sweep as listening.

Myopic is a flag which suppresses the printing of an object's dbref number and abbreviated list of flags when it is looked at. It makes the world appear like you don't control any of it, even if you're a wizard or royalty. It's useful if you don't like to see object numbers. This flag is only valid for players; objects belonging to MYOPIC players are automatically considered to be MYOPIC.

The NO_COMMAND flag disables the checking of $-commands on an object. Most MUSHes will be configured to automatically set this flag on rooms and players. The server runs faster when fewer objects are checked for $-commands; thus, any object which does not have $-commands on it should be set NO_COMMAND.

If an object is set NOSPOOF, @emits, @oemits, @remits and @pemits will be distinctively tagged to help prevent spoofing. This flag is only valid for players; objects belonging to NOSPOOF players are automatically considered NOSPOOF. Beware: the output format of NOSPOOF can mess up @listen and ^ patterns, giving unexpected results.

When this flag is set on an object, players can not "leave" it. Attempts to leave the object will trigger its @LFAIL, @OLFAIL, and @ALFAIL, if set.

The NO_TEL flag prevents objects in a room from being @teleported; mortals in the room cannot use @teleport, nor can other objects @teleport them out. This flag is checked on the "absolute room" of an object; thus, if you are in a container in a room which is NO_TEL, you cannot use @teleport from that container. There is no way to get out of a NO_TEL room except by exiting in some "normal" manner, or by going "home". Puzzle rooms, prisons, and similar locations would probably benefit from this flag.

This flag is enabled with the MUSH building warning system.

When this flag is set on an object, its owner will not receive any building warnings from that object. When it is set on a player, that player will not receive any building warnings at all.

This flag may be used by the MUSH to allow players to indicate when they have left for vacation, to prevent themselves from being purged for inactivity. It is automatically cleared whenever a player logs in, so players should @set it just prior to leaving the net.

When set on yourself, it prevents other players from seeing what you are carrying in your inventory. This applies to everyone and everything, even wizards and royalty, or to stuff that you own.

When set on an exit in a TRANSPARENT room, the exit is displayed as if the room weren't TRANSPARENT.

The PLAYER flag identifies you as a player. This flag cannot be reset by any player, not even a Wizard. It is used mainly by the mush code to identify your commands, check for validity of commands or locks etc. Generally, just pretend it isn't even there.

Once an object is a puppet it will relay all that it sees and hears to its master. All objects created by a puppet are owned by its master. When puppets spend or earn pennies they are also taken from and given to its master. In order to prevent puppets from screwing up puzzles, objects may have the key flag set, which will prevent puppets from picking the object up. A puppet may be commanded by its master by:

 @force [object]=command

or by the shorthand version,

 [name/# of puppet] command

Example:

 @force fred="hi there
 fred "hi there
 #4342 "hi there

This flag when set on yourself prevents you from hearing the 'set' or 'triggered' messages from any objects you own. When set on an object, only that object will not relay its messages.

This flag is automatically set on rooms when you @dig a new room. It cannot be changed.

If this flag is set on any type of object, then that object will be able to @tel and examine as if it was a wizard. Royalty players do not need money, nor are they affected by quotas or restricted building. Royalty is not able to change things like a wizard could. Only wizards may set it on players, although players who are ROYALTY may set their objects ROYALTY.

The SAFE flag protects objects from destruction. If the REALLY_SAFE option was set when the MUSH was compiled, the only way to destroy an object set SAFE is to explicitly reset the SAFE flag and then @dest it. If the REALLY_SAFE option is not set, @destroy/override (or @nuke) will override the SAFE flag and destroy the object.

This flag is automatically set or reset when you set or clear the STARTUP attribute on something. Players may not set this flag. The presence of this flag just shows that an object has a STARTUP attribute on it.

If a thing is STICKY, it goes home when dropped. It also goes home when an object carrying it teleports or goes home. If a room is STICKY, its drop-to is delayed until the last person leaves. This flag is only meaningful for things and rooms.

When an object is set TERSE, it does not see the descriptions or success/failure messages in rooms. This is a useful flag if you're on a slow connection or you're moving through a familiar area and don't want to see tons of text. This flag is only valid for players; objects belonging to TERSE players are automatically considered to be TERSE.

If this flag is set on an exit, when a player looks at the exit they will see the description and contents of the destination room following the exit's description. The exit list and succ/fail messages of the room will NOT be displayed. See also CLOUDY

If this flag is set on a room, it will display exits in "long" format. Instead of putting all the exits on one line under "Obvious exits:" it prints each exit on a line by itself, in the format: <Exit Name> leads to <Exit Destination>.

Thus, you might have:

 Obvious exits:
 South leads to Joe's Room.
 East leads to City Park.

instead of

 Obvious exits:
 South East

Exits set OPAQUE are still shown in the short format, so you can mix the two.

If a player is set UNFINDABLE, he cannot be found by the @whereis command. You also cannot use loc(), locate(), and similar functions to find his location.

If a room is set UNFINDABLE, you cannot locate any of its contents via any means (@whereis, the loc() function, etc.)

If a wizard is set UNFINDABLE, and he is idle past the allowable maximum idle time, he will be set DARK automatically.

This flag may be used by the MUSH to indicate rooms which have not been inspected by the Building Council, Administration, etc.

This flag may be used by the MUSH to support on-line registration. The only restriction on UNREGISTERED players is that they may not be granted @powers.

An object set VERBOSE echoes the commands it executes to its owner before executing them. This differs from the PUPPET flag in that the owner sees the command itself, rather than the output from the command. This flag is extremely useful in debugging, especially if used in conjunction with the PUPPET flag. VERBOSE output follows the format "#<object>]