Building 104 -- Exits/Actions
An Explanation of Basic @Messages and Setup
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
by Wixenstyx@MUCK-U, June 2003 ARR
Type 'read book4=contents' to see what it's about.
You open the book and turn to the table of contents. It says:
This book dedicated to Perelaai. Happy Birthday, handsome!
July 7, 2003
Wix
===============================================================
Title Chapter
---------------------------------------------------------------
Introduction: Review of 103.........................A (1 pages)
Exit or Action?.....................................B (1 pages)
Anatomy of an Action................................C (3 pages)
Setting up Actions..................................D (4 pages)
Putting it into Practice I -- Commands..............E (3 pages)
Putting it into Practice II -- Exits................F (4 pages)
Other Considerations................................G (3 pages)
===============================================================
To read a section, type 'Read Book4=1A'
Chapter A: Introduction --Review of 103
Before we get into exits, let's review what we've learned about players and
Rooms:
Command Player Room
================================================================================
@pcreate Creates a new player object (wiz) --
@dig -- Creates a new Room (builder)
@Link Sets a Player's 'home' Sets a Room's DropTo
@Lock Determines who may 'rob' player Determines who can see the Succ
@Succ/OSucc Shown when successfully robbed Shown when look is successful
@Fail/OFail Shown when rob attempt is thwarted Shown when look is unsuccessful
@Drop/Odrop Shown when Player is 'killed Shown when DropTo is triggered
@Desc Sets the Player's description Sets the Room's description
@Set Sets/Unsets Flags Sets/Unsets Flags
Now that you've mastered the three major static building objects, it's time to
move into the magical world of 'manipulation', that is, making Things, Players
and Objects move around relative to each other within the game. For this, of
course, you need to learn about Exits.
This is the last page of this chapter.
Chapter B: Exit or Action?
=========================
Before we can get into the mechanics of setting up an Exit, it is important to
clarify exactly what an Exit/Action really is. If you ask most avid MUCK
players to define the term 'exit', they'll probably tell you it's a door that
leads from one room into another. Given that A) they ARE called 'exits' and B)
allowing a player to move from one room to the next is easily the most common
use of these database items, this perception of them is not at all unexpected.
But it is, in the strictest sense, incorrect. In fact, some builders even
object to calling them 'exits' at all, though this is the accepted term for
them. 'Exit' implies a kind of hole that allows Players to move back and forth
from one room to the next. However, as you will see, this isn't at all how
exits work, and this perception sets up new builders for a lot of confusion.
For that reason, try to think of exits as 'actions'. The terms 'Action' and
'Exit' are used more or less interchangeably in building, but 'action' really
is the most accurate description of what they are and how they work. This will
(hopefully) be clearer as we discuss the various ways exits/actions work.
This is the last page of this chapter.
Chapter C: Anatomy of an Action
===============================
Actions serve as connections between two other database items. Without them,
Rooms, Things, Players and Programs would simply exist, with no other way to
interact with each other. For this reason, the properties that apply to other
database items (having a home, being able to 'hold' things, having a monetary
value, etc.) do not apply to Actions.
Actions always interact with two other database items. The first, called the
'Source', is the item where the action is actually located. The second, the
'Destination', is established using the @Link command, and determines what
exactly the Action causes to happen when it is triggered by a player.
The chart below details out exactly what happens when certain database items
are linked to others via an action.
When the Source And the Destin- This will happen when the
Object is: ation Object is: action is triggered by a player:
A Room Another Room Move the player into the next room.
A Room A Player Will move the triggering player to
To read the next page, simply type 'next'.
where the other Player is.
A Room An Object Will bring the object to that room.
A Player A Room Moves the Player to the Room.
A Player Another Player Moves the Player to where the
other Player is.
A Player An Object Brings the object to the Player.
An Object A Room Moves the Player to the Room.
An Object Another Player Moves the Player to where the
other Player is.
An Object Another Object Brings the Dest object to the
triggering player, sends the Source
object to its home.
Anything A Program Runs the MUF program.
Like other Database objects, Actions do use @messages, but the ones displayed
when they are triggered depend on the Source and Destination. The general rules
of thumb, though, are listed below:
@Message When Displayed
@Desc When someone looks at the action itself.
@Success To the effective player, when the action is triggered.
@OSuccess To the rest of the Source Room, or the room where the
To read the next page, simply type 'next'.
source is located, when the action is triggered.
@Drop To the Player, when the destination is reached.
@ODrop To the rest of the Destination room, or the room where
the destination is located, when the action is completed.
@Fail To the effective player, when a locked action is attempted.
@OFail To the rest of the Source Room, or the room where the
source is located, when a locked action is attempted.
This is the last page of this chapter.
Chapter D: Setting up Actions
=============================
Because of the unique nature of Actions, setting them up can be interesting.
Initially, you must make sure the following things are true:
A. That you either own or control (if you're a wizard) your intended Source object.
B. That either you own the Destination database item, or the database item has
an L (Link-Ok) flag set.
Once those requirements are in place, you can proceed. As it happens, there are
two sets of commands you can use to set up an Action.
1. The @Action-@Link Combo
This method was the earliest way to set up an action. It's also the least
convenient, but probably the most easily understood. Format is as follows:
@Action <name of action>=<source database item>
@Link <name of action>=<destination database item>
Viola! A completed action.
2. The @Open Technique
To read the next page, simply type 'next'.
This command was developed later, as 'actions' became more widely known as
'exits'. The nice thing about @Open is that it sets up the source and
destination in one step. The annoying thing about it is that it assumes the
source you want is the room you're standing in, and there's no good way to
convince it otherwise.
@open <name of action>=<destination database item>
Other Action-related commands you should be aware of:
1. @Attach -- used to change an action's source. If you accidentally create an
action on your character that was intended to be on the room,
you can simply:
@attach <name of action>=<new source>
2. @Unlink/@Link -- Used to change an action's destination. If you accidentally
@link an action to the wrong thing, you can simply:
@unlink <name of action>
@link <name of action>=<new destination>
3. @Relink -- NOT supported by all MUCK formats, but this command actually
combines the @unlink and @link commands into one command for
To read the next page, simply type 'next'.
setting a new destination for an action.
@relink <name of action>=<new destination>
Finally.. One last word about Action Names
To trigger an action, you simply type the name of the action and you're off.
But what if you don't WANT to type out 'North [n]' every time you want to head
in a northbound direction? Action naming supports a wonderful feature called
'aliasing', which simply means that you can set up an action so that it can be
triggered using any of several typed commands.
For example:
@action North [N];north;nort;nor;no;n;out;leave;exit=here
@link North=#1234 (destination room)
In this example, players wishing to go through the 'north' exit can type any of
the following to move into the room to the north: 'north [n]' or 'north' or
'nort' or 'nor' or 'no' or 'n' or 'out' or 'leave' or 'exit'.
Note that the MUCK's execution of actions is NOT case-sensitive. Only the
inserver commands 'WHO' and 'QUIT' require case consideration. Also note that
most MUF 'Obvious Exits' programs list the first alias of an exit only, so
To read the next page, simply type 'next'.
you'll want to make that the first alias the 'pretty' name of the exit. The
rest won't show.
This is the last page of this chapter.
Chapter E: Putting It Into Practice I -- Commands
=================================================
'Commands' are basically any action that isn't an 'exit' that links two rooms.
Suppose, for example, that you have set up your home and want to reach it from
anywhere in the Game without using the 'Home' command. Here's the setup you
might use:
Example 1: GoHome Telportation Action
-------------------------------------
@action gohome;gh=me
@link gohome=#<dbref of your 'home' room>
@desc gohome=Type this to go home, silly!
@succ gohome=You snap your fingers and blip out.
@osucc gohome=snaps %p fingers and blips out.
@drop gohome=Lights flash, and you appear back at your home!
@odrop gohome=suddenly appears beside you!
Simple enough, right? Okay...suppose you make friends with someone named
'Bojo' who wants to hang out with you. You can make him a nice present by
creating a 'Thing' and an action that brings him to you from anywhere he
To read the next page, simply type 'next'.
happens to be:
Example 2: Teleportation Object
--------------------------------------
@create Zapper
@desc Zapper=You see a funny square object that looks like a remote-control. There is one large, square red button in the center that says "WIX!" You wonder what would happen if you <press> it.
@succ Zapper=You pick up the Zapper.
@osucc Zapper=picks up the Zapper.
@drop Zapper=You set down the Zapper.
@odrop Zapper=sets down a Zapper.
@action press button;press;gowix=Zapper
@link press button=me
@lock press button=*Bojo
@succ press button=You press the button on the Zapper. There's a flash of light and your surroundings disappear!
@osucc press button=presses a button on the Zapper. There's a flash of light, and %s disappears!
@drop press button=The light fades, and you find yourself standing beside Wix!
@odrop press button=appears in a sudden flash of light!
@fail press button=You press the button on the Zapper, but nothing happens.
@ofail press button=presses the big red button on the Zapper, but nothing happens.
(And no, for the record, I don't actually know anyone named Bojo.)
To read the next page, simply type 'next'.
Keeping handy the chart in Section 2 can be very helpful when playing with
actions that make commands. Read on now to learn about the most common use of
actions -- as exits.
This is the last page of this chapter.
Chapter F: Putting It Into Practice II -- Exits
===============================================
The use of actions to move players from one room to another is by far the most
common, and for that reason it is important to understand why it is that
calling an action an 'exit' is misleading.
Imagine that you're standing in a two room house. There is a room to the east,
and a room to the west, and a single wall dividing them with a door in the
center of it. You are standing in the room at the east end of the house, and
you want to move into the other room. What do you do?
Well, of course, you go through the door.. But to do that you 'go west',
passing through the door on your way. Once you're standing in the western room,
you cannot 'go west' again to get back. You have to do something different...in
this case, 'go east'. So, even though there is only one door, you perform two
separate actions to use it.
Building on MUCKs is very literal in this regard. When you @dig two rooms and
you want to pass from one to the next, you have to create two different actions
to make that possible. You do not actually create an 'exit' in the form of the
two-way portal a doorway represents. Instead, the actual portal is purely
To read the next page, simply type 'next'.
incidental and only part of the description. What you actually make are the
actions that make it LOOK as if you're using a portal.
Take a look at this example:
Example 1: Creating an Exit -- Basic
------------------------------------
@dig ThisHere Room
@tel me=#<dbref of ThisHere Room>
@desc here=You stand in a room. Right here! Isn't it nice? There's a door to
the west leading into ThatThere Room.
@succ here=@$obvexits
@dig ThatThere Room
@open ThatThere Room <W>;west;wes;we;w;there=#<dbref of ThatThere Room>
@desc west=You see a doorway. It appears to lead into ThatThere Room.
@succ west=You head through the west doorway, entering ThatThere Room.
@osucc west=heads west, entering ThatThere Room.
@drop w=<NOT SET>**
@odrop West=enters through the door to the east.
You're only half done here, though.
To read the next page, simply type 'next'.
You type 'west' and see:
You head through the west doorway, entering ThatThere Room.
ThatThere Room(#1234R/M)
You see nothing special.
From here, you must now:
@desc here=You stand in ThatThere room! There is a door in the east wall leading back to ThisHere Room.
@succ here=@$obvexits
@open ThisHere Room <E>;east;eas;ea;e;this;here;=#<dbref of ThisHere Room>
@desc east=You see a doorway. It appears to lead into ThisHere Room.
@succ east=You head through the west doorway, entering ThisHere Room.
@osucc east=heads west, entering ThisHere Room.
@drop east=<NOT SET>**
@odrop east=enters through the door to the west.
NOW you're done. Two actions, each leading in different directions, make one
'exit' as it were.
Now, back to MUF-programmed Shortcuts. One obvious problem with this system is
that inexperienced builders sometimes forget to make that second exit. As a
To read the next page, simply type 'next'.
result, anyone navigating through rooms they've built can end up trapped in a
room with no way to leave it. To address this problem, some MUF programmers
(Raven of FurryMUCK, for one) have programmed ways to make the whole thing
complete (except for @messages) using one command. That command is called
"@XDig" The command format is as follows:
@xdig <roomname>=<exit leading in>=<exit leading back>
Example: (assume you're standing in 'ThisHere Room', and you've not yet used
@dig to create 'ThatThere Room'
@xdig ThatThere Room=ThatThere Room <W>;west;wes;we;w;thatthere=ThisHere Room <E>;east;eas;ea;e;thishere
The command will, then, @dig the room for you and create and link both exits in
one full swoop. Very handy.
** Note that the @drop really isn't necessary on exits, as it appears
immediately after the @success. Often, the @drop is used for exit-triggered
MUF or MPI program calls, so setting an actual @drop message isn't necessary
for the building to look complete.
This is the last page of this chapter.
Chapter G: Other Considerations
===============================
Removing Actions (This is for you, Iris)
@recycle <action name>
@recycle #<dbref of action>
Renaming Actions
@name <old action name>=<new action name>
Actions and Parenthood
One of the nice features of Actions with respect to Parent rooms is that
actions whose sources are Parent rooms are available in all child rooms as
well. This is true regardless of the destination of the action. Examples of
ways in which this can be used include:
A. HoloMUCK's 'center' command, which automatically transports you to
'Tanstaafl Center' from anywhere on Planet Holo. SPR's 'gopark' command works
much the same. NarniaMUCK's 'GoOOC' works this way, too, but with MUF support
that enables you to return to your point of origin when you use 'GoBACK'. (If
you'd like the MUF program for this, just let me know. I'm pretty liberal about
To read the next page, simply type 'next'.
sharing mine.)
B. Any actions that call programs (examples include NarniaMUCK's global combat
commands, special variations on 'WHO', etc.) are all actions located on parent
rooms that are accessible in child rooms.
Action Priority
Occasionally you might run into a problem where two actions that affect a given
room have one or more of the same aliases. For instance, you might have a
global exit on a parent room called 'Center;c' and then an exit on a child room
that is called 'Chandellier Room;c'. When this happens, the default priority is
given to the most local exit.. Thus, if a player typed 'C' while standing in
the child room, the more local exit 'Chandellier Room;c' would be triggered and
the 'Center;c' exit on the parent room ignored.
This CAN be overridden, however. Say you have a global exit that you want to
take precedence no matter what the aliases may be on child rooms in the
environment. You can set priority using M- and W- flags, where each level
represents a higher priority. An action set M1 overrides an action with no M-
flag set. An action set M3 overrides an action set M1, and so on. This control
feature is mainly to allow Wizards greater control over the game, but players
who build for fun may find it useful as well.
To read the next page, simply type 'next'.
Fake Actions
Actions can also be used to create 'fake' actions that APPEAR to do something
when they really do not. Say, for instance, that you have created a stuffed
bear, and you want it to react when someone 'hugs' it. You can set that up this
way:
@action hug bear;hug teddy;hug teddy bear=Teddy Bear
@link hug bear=Teddy Bear
@lock hug bear=me&!me**
@fail hug bear=You hug the Teddy Bear! The Bear squeals with delight!
@ofail hug bear=hugs the Teddy Bear! The Bear squeals with delight!
Note that the source and destination are the same here, and that the action is
locked to 'me&!me'. If you recall back to when we discussed @Lock, the '&'
symbol requires that a player be able to fulfill BOTH qualifications before
they can pass the lock. As no one can be 'me & not me' at the same time,
locking anything to 'me&!me' effectively locks it against everyone, including
you. You then set @fail messages to read as if they are @success messages, and
you're done.
This is the last page of this chapter.