Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in /home/virtualw/public_html/Resources/Hosted/Resource.php on line 9
MUSH Reference
Not a member yet? Register for full benefits!

Username
Password
MUSH Reference

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


Levels of player

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.


Getting started - connecting

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.


Seeing who is already playing

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.

Creating a new character

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.


Connecting to an existing character

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.


Player registration

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.


Quitting the game

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.


Changing your password

To change your password, type:

 @password oldpassword = newpassword

Give yourself a description and gender


Describe yourself

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


Knowing if people look at you

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.


Set your gender
@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.

Lock yourself

It is also sensible here to "lock" yourself:

 @lock me = me

The reasons for this will become apparent later.


Looking around

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.


Looking at people and 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.


Moving

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.


Seeing what you are carrying

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.


Saying

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.


Posing (emoting)

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.


Whispering to another player

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

Paging another player

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

Joining a chat channel

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.

Talking on a chat 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"

Posing on a chat channel

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.


Interacting with things

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

You can try to "take" the object:
 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.

Taking inventory

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

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

Dropping things

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!

Giving things or players money

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.

Being idle

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


Being away

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.


Saying what you are doing

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.

On vacation

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.


Building - an introduction to the database

Before we start talking about building rooms or creating things in the MUSH, it is worthwhile to discuss how the MUSH works internally, at least in broad terms.

Because the game is extensible (ie. you can add new rooms at any time) the program stores a "database" of rooms descriptions, links and so on in memory. The database consists of "objects" which can be one of:

Players
Rooms
Exits
Things

Players are the people who log into the MUSH and play the game. Each player is represented internally by his or her database object (containing the player description, sex and so on).

Rooms are the places where players visit. Players are always in a room of some sort.

Exits are the way that rooms are linked. An exit named "south" for example links a room to the room to the south of it.

Things are things that players can pick up and take around, or look at (eg. keys, wands, chickens, notice boards and so on).

Every object has some fundamental characteristics:

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

Examining an object

You can usually see most of the above characteristics by "examining" an object. For example:

 examine me
 examine here

Unless you are a wizard, you can only examine object you own (unless the object has the "visual" flag set). Objects other people own will only tell you the name of the owner. This is to stop you examining objects and possibly finding out secrets about them (for example, you might examine a room and find its secret exits).

For example:

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

Rooms and exits

To fully understand what is happening when you build, you need to know about rooms and exits.

Rooms

Rooms are where players go and meet. Rooms hold:

Players
Things
Exits

Exits

Exits link rooms to each other. Contrary to what you might think, each exit has its own "database number. The diagram below should make this clearer. If you have two rooms, "Cave" and "Waterfall", and you can go east/west to get between them, then you actually have four database objects, as follows:

The database object numbers (800 to 803) are just examples. In this case:

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

You do not necessarily have to have exits in both directions. A room might have no exits, and thus only be accesible by "teleporting". A room with an exit leading one way but not the other might represent a "one-way" sort of link, such as a drop from a trap-door into a room below.


Locks

Exits can have "locks" put on them. A lock stops unconditional passage from one room to another. For example, you might set a lock so that:

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

Locks are explained in more detail later on. Click on Locks Introduction for more detail about locks.

 


Attributes

Rooms and exits can have attributes put on them. These control messages and actions that are displayed or invoked when someone passes or fails the various locks. These are used to add colour to the game. For example, if someone cannot use the East exit (because they are not carrying an important object) they might see an explanatory message ...

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

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


Building rooms and exits

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


@dig - create 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:

Command Result
@dig Waterfall Will dig a room called "Waterfall".
@dig/teleport Cave Will dig a room called "Cave" and teleport you to it.
@dig Waterfall = West Will dig a room called Waterfall, and open an exit called 'West' in your current room.
@dig Waterfall = West, East Will dig a room called Waterfall, open an exit called 'West' in the current room, AND open an exit 'East' in the room 'Waterfall' leading to the current room.
@dig Waterfall = West;W, East;E Will dig a room called Waterfall, open an exit called 'West' in the current room, AND open an exit 'East' in the room 'Waterfall' leading to the current room. The exit names "E" and "W" can be used in place of "East" and "West".

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.


@open - create an exit

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:

Command Result
@open East Creates an exit (in the current room) called East. It does not lead anywhere.
@open East = #88 Creates an exit (in the current room) called East. It leads to room number #88.
@open East = #88,West Creates an exit (in the current room) called East. It leads to room number #88. Also creates an exit in room #88 called West, leading to the current room.
@open East;E =#88,West;W Creates an exit (in the current room) called East. It leads to room number #88. Also creates an exit in room #88 called West, leading to the current room. You can also use "E" instead of "East" and "W" instead of "West".

@link - change the destination of an exit

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.


Changing where an exit leads from

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.

Changing the name of a room or exit

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.


Building hints

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

Exit flags

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.


Success and failure messages

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


Lock types

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 type Meaning
/enter Who can enter the player/object
Enter-locks an object, restricting who is allowed to enter it. Only objects which are ENTER_OK may be entered, regardless of the key.

The enter lock of a room is its Teleport Lock (see below).

Note that the enter lock of an object or room being used as a Zone Master Object determines control of that zone. Please note that if you're using a room as a ZMO (i.e. as a zone master room), only the controllers of that zone will be able to teleport into that room (which is a good thing for security).

/teleport Who can teleport to the room
Only people who pass the room's teleport lock, are wizards or royalty, or control the room, will be allowed to @teleport into the room. (Note that this is different from NO_TEL, which prevents people from teleporting out of a room). The teleport lock is evaluated even if the room is JUMP_OK - in other words, if you are trying to teleport into a room you don't control, the room must be JUMP_OK, and you must pass the teleport lock.
/use Who can use the object
Sets the use-lock on an object, which restricts who may trigger the "@use" set of registers, and who may use the $commands on the objects. If the person who is trying to use the object or its special commands, cannot pass the lock, he is told, "Permission denied."
/page Who can page the player
/zone Who can control objects on this zone
/parent Who can @parent something to this object/room
/link Who can @link something to this object/room
/mail Who can @mail the player
/user:<name> User-defined. No built-in function of this lock,
/speech Who can speak/pose/emit in this room
/listen Who can trigger my @listen/^-patterns
/leave Who can leave this object
/drop Who can drop this object
/give Who can give this object

@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         
will let you pass either if you carry bar or are 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...

Lock type Symbol Meaning
Indirect locks @ Locks an object to the lock of the specified object. Good if you have many locks with the same key, simply lock all the locks to one object, then lock that object to the common key.

Example:

@lock foo=@bar

locks foo to bar's key.

Carry lock + You can go though only if you carry foo.

Example:

@lock bar = +foo
Is lock = You can only go through if you are foo.

Example:

@lock bar = =foo

The last two are different from @lock foo = bar in that @lock foo=bar will let you pass either if you carry bar or are bar.

Owner lock $ You can only go through if you have the same owner as foo.

Example:

@lock bar = $foo
Attribute lock attr : You can only go through if you have an attribute set on yourself which matches the value of the attribute lock.

The value is a string which may contain wildcards, greater than, and less than.

The locked object must be able to read the attribute from the thing trying to pass the lock; if it cannot do so, the thing cannot pass the lock. (So, mortals can generally only usefully lock to public attributes like 'sex', or to attributes on their own objects).

All attribute locks take the format @lock thing=attribute:value

Example:

@lock thing=sex:m*

will lock thing to anyone whose sex attribute starts with an 'm'.

@lock exit = elephants:<5

will lock the exit to anyone who has 5 or less in the attribute "elephants".

Evaluation locks eval / These locks take the form @lock thing=attribute/value They are thus very similar in form to attribute locks. These locks are checked by evaluating the contents of <attribute> and comparing it to <value>; a lock is passed if these are equal.

<Attribute> may be thought of much like a user-defined function; its contents are evaluated with the equivalent of EVAL(thing, attribute) For the purposes of evaluation, the player trying to pass the lock on thing is the enactor (%N) and the thing is "me" (%!)

Example:

@lock thing = Ispuppet/1
&Ispuppet thing = [hasflag(%#, PUPPET)]

This locks thing to puppets only. If player tries to pass the lock on thing, Ispuppet evaluates to: [hasflag(<player dbref>, PUPPET)] and the function returns 0 or 1 depending on whether or not player is a puppet. The lock is passed if the evaluation equals "1".

Evaluation locks are extremely flexible; you can even use them to imitate other types of locks. For example, instead of @lock object = #5 you can use @lock object = VA/#5 and @va object = %# (This is somewhat foolish, but you can do it if you want to.)

These locks are evaluated with the privileges of the locked object; thus, if you @lock object = VA/5 and @va object = [strlen(get(%#/VZ))] and the object does not have permission to read VZ from the player trying to pass the lock, the player automatically fails to pass the lock.


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 an exit so only female characters can pass
 @lock north = sex:f*

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


Lock an exit so only male or female characters can pass
 @lock north = sex:m*|sex:f*

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


Lock an exit so you must have a description to pass
(useful for initial rooms)
 @lock out = desc:*

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


Lock an exit so you must have a description and gender of M or F to pass
 @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 something so only you can take it
 @lock purse = me

This is useful for locking your possesions.


Lock an exit so you must be a wizard to pass through it
@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 an exit so you must be a male wizard to pass through it
@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 yourself so you cannot be taken
@lock me = me

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


Lock yourself so you cannot be paged by someone
@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 a room so some players cannot speak in it
 @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.


Success and failure messages

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.

Type of success and failure messages

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.


Syntax

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.


Messages/actions for the basic lock
Command Result

@success

Displayed to the player when s/he successfully uses the object. Can be abbreviated to "@succ".

@failure

Displayed to the player when s/he fails to use the object. Can be abbreviated to "@fail".

@osuccess

The @osuccess message, prefixed by the player's name, is shown to others when the player successfully uses the object. Can be abbreviated to "@osucc".

@ofailure

The @ofailure message, prefixed by the player's name, is shown to others when the player fails to use the object. Can be abbreviated to "@ofail".

@asuccess

Sets the actions to be taken on successful usage of <object>. Actions are lists of commands separated by semi-colons and these commands are executed by the object. Things can execute almost any command but rooms and exits are restricted to forcing objects/puppets to do things. Gender substitutions are applied to the commands before they are executed, this allows use of the player's name who caused the action. It can be abbreviated "@asucc".

@afailure

Sets the actions to be taken on failure to use <object>. Actions are lists of commands separated by semi-colons and these commands are executed by the object (see puppet). Things can execute almost any command but rooms and exits are restricted to forcing objects/puppets to do things. Gender substitutions are applied to the commands before they are executed, this allows use of the player's name who caused the action. May be abbreviated "@afail".

When @success messages (and their variants) are displayed

Type of thing When the message is displayed
Exits When someone walks through the exit
Objects When that object is picked up
Players When the player is picked up
Rooms When someone looks at it

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


Other types of messages and actions

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
Lock type Command Result
Drop @drop The message is displayed when a player drops <object>.
@odrop This message is shown to others when the player drops <object>.
@adrop Sets the actions to be taken when <object> is dropped.
Enter @enter The message is displayed to anyone entering the object.
@oenter This displays <name> <message> to everyone inside the object, except for the person who is entering.
@oxenter This replaces the functionality of the old @oenter. This message is shown to everyone in the room that the player leaves whenever he enters an object via the command 'enter <object>'. This will be shown in addition to the leave message of the room, not instead of.
@efailure This is the message shown to the player who fails to enter the object. May be abbreviated @efail.
@ofailure This is shown to others when the player fails to use <object>. May be abbreviated @ofail. (Note: @ofails on locked exits and objects is considered Good Building Practice.)
@aenter Executes <actionlist> whenever someone enters the object. Actions are lists of commands separated by semi-colons and these commands are executed by the object (see puppet). Objects can execute almost any command. Gender substitutions are applied to the commands before they are executed, which allows use of the player's name who caused the action.
@aefail This is the action taken by the object when a player fails to enter it.
Leave @leave The message is displayed to anyone leaving the object.
@lfail This is the message shown to the player who fails to leave the object.
@oleave This displays <name> <message> to others inside the object, except for the person who is leaving.
@olfail This message is shown to others in the room of a player who fails to leave the object.
@oxleave This message is shown to others in the room that a person enters when doing a 'leave' command. This will be shown in addition to the enter messages of the room, not instead of.
@aleave Executes <actionlist> whenever someone leaves the object. Actions are lists of commands separated by semi-colons and these commands are executed by the object. (see puppet). Objects can execute almost any command. Gender substitutions are are applied to the commands before they are executed, which allows use of the player's name who cause the action.
@alfail This is the action taken by the object when a player fails to leave it.
Page @haven This message is sent to a player whose pages you are refusing, either through use of the HAVEN flag or through the use of a page lock, if it evaluates to something non-null.
Teleport @tport The message shown to <object> when <object> is teleported.
@otport Sets the <message>, which will be prefixed by <object>'s name, that will be shown to the others in the room that the <object> is teleported to.
@oxtport Sets the <message>, which will be prefixed by <object>'s name, that will be shown to others in the room that the object has left via @teleport.
@atport Sets the list of actions that <object> will perform when it is teleported. These actions are done after <object> has arrived in its new location.
Use @use The message is displayed when a player successfully does a "use" on the object.
@ouse The @use message, prefixed by the player's name, is shown to others when a player successfully does a "use" on the object.
@ause Sets the actions to be taken when an object is succesfully "used". Actions are lists of commands separated by semi-colons.

Messages displayed even if no lock is present

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.


Moving and copying attributes

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>,...]
This command is used to copy <attr> on <obj> to the object-attribute pairs in a comma-separated list. For example:
 @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
would copy the VA attribute from "test" to VA on "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.


Examining attributes

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.

Examining an individual attribute

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

A - Abode, Ansi C - Chown_Ok, Color D - Dark
E - Exit (type) F - Floating, Fixed G - Going
H - Haven I - Inherit J - Jump_Ok, Judge
L - Link_Ok M - Monitor N - Nospoof, No_Tel, No_Leave
O - Opaque P - Player (type) Q - Quiet
R - Room (type) S - Sticky U - Unfindable
V - Visual W - Wizard X - Safe
Z - Zone, Z_Tel

Flags - lower case

a - Audible b - Debug c - Connected, Cloudy
d - Destroy_Ok e - Enter_Ok f - Force_White
g - Gagged h - Halt j - Jury_Ok
l - Light m - Myopic n - No_Command
o - On-Vacation p - Puppet r - Royalty
s - Suspect t - Transparent u - Uninspected
v - Verbose w - No_Warn x - Terse
z - Startup ? - Unregistered

Some flags may not be enabled on some MUSHes.


Flags grouped by object types

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.

Object type Possible flags
All AUDIBLE, CHOWN_OK, DARK, DEBUG, ENTER_OK, HALT, HAVEN, INHERIT, LIGHT, LINK_OK, NO_COMMAND, NO_WARN, OPAQUE, QUIET, ROYALTY, SAFE, STICKY, TRANSPARENT, UNFINDABLE, VERBOSE, VISUAL, WIZARD
Players ANSI, COLOR, FIXED, FORCE_WHITE, GAGGED, JUDGE, JURY_OK, MONITOR, MYOPIC, NOSPOOF, ON-VACATION, SUSPECT, TERSE, UNREGISTERED, ZONE
Things MONITOR, DESTROY_OK, PUPPET, NO_LEAVE
Rooms ABODE, FLOATING, JUMP_OK, MONITOR, Z_TEL, NO_TEL, UNINSPECTED
Exits CLOUDY

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.


Flags automatically shown for objects you own

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

Setting a flag (turning it on)
@set <object> = <Flag>

For example:

 @set me = quiet
 @set here = dark


Resetting a flag (turning it off)
 @set <object> = !<Flag>

For example:

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

Description of all flags

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


ANSI

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.


AUDIBLE

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.


CHOWN_OK

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.


CLOUDY

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.


COLOR

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


CONNECTED

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.


DARK

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.


DEBUG

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

DESTROY_OK

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.


ENTER_OK

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>


EXIT (type)

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.


FIXED

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.


FLOATING

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.


FORCE_WHITE

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.


GAGGED

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.


GOING

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.


HALT

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


HAVEN

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


INHERIT

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!)

JUDGE and JURY_OK

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


JUMP_OK

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


LIGHT

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.


LINK_OK

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


MONITOR

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

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.


NO_COMMAND

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.


NOSPOOF

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.


NO_LEAVE

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.


NO_TEL

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.


NO_WARN

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.


ON-VACATION

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.


OPAQUE

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.


PLAYER (type)

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.


PUPPET

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


QUIET

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.


ROOM (type)

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


ROYALTY

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.


SAFE

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.


STARTUP

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.


STICKY

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.


SUSPECT
This flag is only settable by wizards. Players with this flag have their connects, disconnects, name changes, and kills reported to all connected wizards.
TERSE

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.


TRANSPARENT

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.


UNFINDABLE

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.


UNINSPECTED

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


UNREGISTERED

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.


VERBOSE

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>] <command>". Something like

 "#1300] @trigger me/va"

is a good example of typical VERBOSE output.


VISUAL

The flag a lot of players have been waiting for. When set on your object, it allows other players to examine it and see all the object's attributes as if they owned the object. They cannot make any changes to the object.


WIZARD

If a person is WIZARD, they are a wizard, unkillable, subject to fewer restrictions, and able to use wizard commands. In general, WIZARDs can do anything using #<number> or *<player>. Only player #1 can set and unset the WIZARD flag of other players. No WIZARD can turn their own WIZARD flag off.


ZONE

The ZONE flag is used to designate a player as a Zone Master. Objects owned by a Zone Master are controlled by anyone who passes the player's enter lock. This allows zoning based on ownership rather than on the zone field, and is more secure, although it does not allow for the "local master room" ability of "standard" zones.


Z_TEL

The Z_TEL flag, when set on a zoned room or on the ZMO (Zone Master Object) of a room, prevents objects in the room from being @teleported out of the zone - that is, objects can only be @teleported to a room which is zoned to the same ZMO. Setting this flag on the ZMO affects all rooms zoned to it. Like no_tel, the "home" command will still work. This flag is intended for use in puzzle rooms and IC areas.

Lock types

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 type Meaning
/enter Who can enter the player/object
Enter-locks an object, restricting who is allowed to enter it. Only objects which are ENTER_OK may be entered, regardless of the key.

The enter lock of a room is its Teleport Lock (see below).

Note that the enter lock of an object or room being used as a Zone Master Object determines control of that zone. Please note that if you're using a room as a ZMO (i.e. as a zone master room), only the controllers of that zone will be able to teleport into that room (which is a good thing for security).

/teleport

Who can teleport to the room

Only people who pass the room's teleport lock, are wizards or royalty, or control the room, will be allowed to @teleport into the room. (Note that this is different from NO_TEL, which prevents people from teleporting out of a room). The teleport lock is evaluated even if the room is JUMP_OK - in other words, if you are trying to teleport into a room you don't control, the room must be JUMP_OK, and you must pass the teleport lock.

/use

Who can use the object

Sets the use-lock on an object, which restricts who may trigger the "@use" set of registers, and who may use the $commands on the objects. If the person who is trying to use the object or its special commands, cannot pass the lock, he is told, "Permission denied."

/page Who can page the player
/zone Who can control objects on this zone
/parent Who can @parent something to this object/room
/link Who can @link something to this object/room
/mail Who can @mail the player
/user:<name> User-defined. No built-in function of this lock,
/speech Who can speak/pose/emit in this room
/listen Who can trigger my @listen/^-patterns
/leave Who can leave this object
/drop Who can drop this object
/give Who can give this object

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

will let you pass either if you carry bar or are 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...

Lock type Symbol Meaning
Indirect locks @ Locks an object to the lock of the specified object. Good if you have many locks with the same key, simply lock all the locks to one object, then lock that object to the common key.

Example:

@lock foo=@bar

locks foo to bar's key.

Carry lock + You can go though only if you carry foo.

Example:

 @lock bar = +foo
Is lock = You can only go through if you are foo.

Example:

 @lock bar = =foo

The last two are different from @lock foo = bar in that @lock foo=bar will let you pass either if you carry bar or are bar.

Owner lock $ You can only go through if you have the same owner as foo.

Example:

 @lock bar = $foo
Attribute lock attr : You can only go through if you have an attribute set on yourself which matches the value of the attribute lock.

The value is a string which may contain wildcards, greater than, and less than.

The locked object must be able to read the attribute from the thing trying to pass the lock; if it cannot do so, the thing cannot pass the lock. (So, mortals can generally only usefully lock to public attributes like 'sex', or to attributes on their own objects).

All attribute locks take the format @lock thing=attribute:value

Example:

 @lock thing=sex:m*

will lock thing to anyone whose sex attribute starts with an 'm'.

 @lock exit = elephants:<5

will lock the exit to anyone who has 5 or less in the attribute "elephants".

Evaluation locks eval / These locks take the form @lock thing=attribute/value They are thus very similar in form to attribute locks. These locks are checked by evaluating the contents of <attribute> and comparing it to <value>; a lock is passed if these are equal.

<Attribute> may be thought of much like a user-defined function; its contents are evaluated with the equivalent of EVAL(thing, attribute) For the purposes of evaluation, the player trying to pass the lock on thing is the enactor (%N) and the thing is "me" (%!)

Example:

 @lock thing = Ispuppet/1
 &Ispuppet thing = [hasflag(%#, PUPPET)]

This locks thing to puppets only. If player tries to pass the lock on thing, Ispuppet evaluates to: [hasflag(<player dbref>, PUPPET)] and the function returns 0 or 1 depending on whether or not player is a puppet. The lock is passed if the evaluation equals "1".

Evaluation locks are extremely flexible; you can even use them to imitate other types of locks. For example, instead of @lock object = #5 you can use @lock object = VA/#5 and @va object = %# (This is somewhat foolish, but you can do it if you want to.)

These locks are evaluated with the privileges of the locked object; thus, if you @lock object = VA/5 and @va object = [strlen(get(%#/VZ))] and the object does not have permission to read VZ from the player trying to pass the lock, the player automatically fails to pass the lock.

Substitutions

All messages may contain %-substitutions. Some common ones return pronouns if the player's gender is set. They are:

%s subjective Name, he, she, it, they.
%o objective Name, him, her, it, them.
%p possessive Name's, his, her, its, their.
%a absolute possessive Name's, his, hers, its, theirs.
%N player's name Name.

Other possible substitutions are:

%# player number #<actor's number>. Equivalent to num(%N)
%@ caller number #<caller's number>. No equivalent. Initially equal to %#, but changes when things like u() are called.
%! object number #<message holder's number>. Equivalent to num(me)
%l location number #<actor's location>. Like loc(%N). This works even if the LOC() function would normally not, since the enactor has "volunteered" his location by triggering another object.
%c last command Text of last command, before evaluation.
%r newline Carriage return and newline in output. Note that this counts as two characters, in functions like strlen(). (puts "rn")
%t tab Tab character in output.
%b blank Space in output.
%qN r(N) The equivalent of r(N), a register set by a setq() function.
%? accounting Current values of function invocation count and recursion depth count.

If you need a '%', use %%. Case matters; for example, "%S" returns "His", "%s" returns "his".

Example:

 @ofail teapot=burns %p hand on the hot teapot.

would, for a male, return "burns his hand on the hot teapot."

HALTed objects do not perform substitutions.

Other substitutions, such as %va-%vz, %wa-%wz, %xa-%xz, and %0-%9 may also be used and are equivalent to v(?) where ? is a-z or 0-9. In these substitutions and pronoun substitutions, if the first letter of the name is capitalized, the first letter of the substitution will also be capitalized.

Staff Comments

 


.
Untitled Document .

Warning: Unknown: write failed: Disk quota exceeded (122) in Unknown on line 0

Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/tmp) in Unknown on line 0