Building 102 -- Creating Things
An Explanation of Basic @Messages and Setup
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
by Wixenstyx@MUCK-U, August, 2002 ARR
Updated 2004 March 31st
Type 'read book2=contents' to see what it's about.
You open the book and turn to the table of contents. It says:
===============================================================
Title Chapter
---------------------------------------------------------------
Introduction: Review of 101.........................A (2 pages)
Creating Objects....................................B (1 pages)
Customizing Objects.................................C (8 pages)
Technical Information...............................D (4 pages)
===============================================================
To read a chapter, type 'Read Book2=A1'
Which will display chapter A, page 1.
Chapter A: Introduction -- Review of 101
Before we launch into the practical exploration of Building, let's review what
we learned in 101. The chart below displays the five types of Database Items
and the properties discussed in 101.
======================================================================
Item Type TypeFlag Can Hold... Can Be Held By...
----------------------------------------------------------------------
Room R All Rooms
Players P Things, Programs Rooms
Things <None> Things, Programs Rooms, Players, Things
Actions/Exits E Nothing Rooms, Players, Things
Programs F Nothing Rooms, Players, Things
=======================================================================
Note that some of the hold/held by capabilities MAY be overridden using
Administrative permissions, MUF or MPI. This chart reflects the standard setup
for mortal builders without MUF or MPI conventions.
We'll now move into a discussion of creation and basic setup for Things.
To read the next page, simply type 'next'.
------ End of Introduction
This is the last page of this chapter.
Chapter B: Creating Things
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
It's time to do some actual building, and we'll start with the most 'typical'
Database Item: the 'Thing'. Please note that many MUCKs use the term 'Object'
to mean 'Thing'. Unfortunately, they also use the term 'Object' for 'Database
Item', resulting in much confusion. MUCK University's courses will use the
terms 'Thing' and 'Database Item' exclusively.
What follows is an overview of the steps involved in creating a complete thing.
Following is a typical building script for a thing. You may wish to refer to
the script as an example as you read through the overviews.
Creating a Thing: @create <name> [=<amt>]
The @create command is used to generate a new thing. You may elect to use the
<amt> argument to alter the value of the thing, but be warned that not all MUCK
formats still respect this format. GLOW, for instance, will take away <amt>
coins, but the value of the thing will remain unchanged.
This is the last page of this chapter.
Chapter C: Customizing Thinngs (@Commands and @Messages)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Okay... This is the good part. On MUCKs, you can customize some aspects of your
Thing using special commands called @Commands (@Link, @Lock, @Name, @Chown,
@Chlock and @Flock). You can also customize the messages shown to Players who
interact with your thing using @Messages (@desc/@idesc, @succ/@osucc,
@fail/@ofail, and @drop/@odrop).
A. @COMMANDS
1. @Name: @name <thing>=<newname>
You'll only need to use this command if you decide to change the name of
your Thing after it's created. It's handy to know, though.
2. @Link: @link <thing>=<something>
This command sets your thing's 'Home'. This is important, because
the thing's home is where it is sent to when the thing is swept or some
other casualty affects it. A Thing may be linked to a Room or a Player.
The MUCK will usually default to set the thing's home to whatever room
you're standing in at the time (if you own the room) or to your home (if
To read the next page, simply type 'next'.
you don't). Things set with the 'sticky' flag will go home when dropped.
3. @Lock: @lock <thing>=<key>
This command determines who may or may not pick up your Thing.
Valid @Lock keys include:
* Players (only named players can pick up the thing)
* Rooms (Thing may only be picked up by players standing in
this Room )
* Other Things ( Only Players carrying a specific Thing
can pick up the Thing.)
* MUF Programs ( More on this later. )
Lock Keys may include boolean 'switch' characters that enable you to
compound to whom or to what the the thing is locked. These switches
include:
! -- AKA "Not",
| -- AKA "Or", and
& -- AKA "And"
Suppose, for example, you have an thing called "Stuffed Dog" that you
wish to @lock so that only you and your friend, Joe, can pick up. You
would set up the lock this way:
To read the next page, simply type 'next'.
@lock Dog=me|Joe
Note that we use 'OR' there, not 'AND'. Using 'AND' requires that the
prospective player fulfill BOTH qualifications, and let's face it..you
can't be yourself and Joe at the same time.
A quick note: If Joe is not in the room with you, using the command
above will return an error of 'I don't see that here.' In this case, use
the "*" symbol in front of Joe's name to instruct the MUCK to search for
him outside of the room.
@lock Dog=me|*Joe (Lock setup when Joe is not with you.)
We'll go into more about Locking when we discuss Exits/Actions.
3. @Chown: @chown <thing>
'Chown' is shorthand for 'Change Owner'. You would
use this command to 'claim' an thing that belongs to another
player. Please note, though, that this command only works if
two conditions are met:
A. The thing has a Chown_OK (C) flag set, and
To read the next page, simply type 'next'.
B. You pass the thing's ChownLock key.
Those are the commands you will most often need to know. The two that follow
are special-case commands that need only be used under very specific
circumstances:
4. @ChownLock: @chlock <thing>=<key>
This command sets the ChownLock key, thereby defining who may
take possession of the thing when its Chown_Ok flag is set.
The 'key' rules here are basically the same as those listed
above for @Lock. @ChownLock is a comparatively new MUCK
convention, and is available only on FuzzBall MUCKs and
FuzzBall derivatives (Glow, NMC, Proto, etc.)
5. @ForceLock: @flock <thing>=<key>
This command, like ChownLock, is a Fuzzball convention. It
determines which players may 'force' an thing to perform
an action of some kind. Since @Force is an Admin-only
command, though, @forcelock only has applications for players
who are using the {Force:} command in MPI. Again, the 'key'
rules are the same as those used in @lock.
To read the next page, simply type 'next'.
@MESSAGES
@Messages fall into two categories (which will make sense as we get further
into the explanation here). There are plain-old @messages, which are shown to
the player who is interacting with the thing, and there are @Omessages, which
are shown to the rest of the players in the room when a player interacts with
the thing. There are several technical considerations to be recognized when
dealing with @messages versus @omessages, however. You should be aware of them,
even though many of them won't really be useful to you until later:
All @Messages (@desc, @idesc, @succ/@osucc, @fail/@ofail, and @drop/@odrop.
* Can be set as MPI commands, and will be parsed.
* Can be set as MUF program calls, which will be executed.
* May respect ANSI tags, depending on the MUCK version and local changes.
@Messages: (@desc, @idesc, @succ, @drop, and @fail)
* Are reported as typed, with nothing added or deleted.
* Do not recognize or make use of %pronoun substitutions.
@OMessages: (@osucc, @odrop, and @ofail)
* Are reported with the name of the interacting player prepended
to the message.
* Recognize and make use of %Pronoun substitutions.
To read the next page, simply type 'next'.
@Messages can sometimes be the determining factor between a well-built Thing
and a shoddily-built one. A good builder will use as many @messages as are
applicable to the Thing.
1. @describe <thing>=<description>
This will set the message show to a player when he or she looks
at the thing (look <thing>). While it's good to be descrip-
tive and detailed, keep in mind that the @desc field is fairly
small. This can be extended using LSEDIT, if you prefer, but
Players generally appreciate shorter descriptions. If they have
to backscroll to read, most won't bother.
2. @idescribe <thing>=<description>
This message is only really necessary if you're planning to turn
your thing (with MUF/MPI assistance) into a vehicle. The Idesc
on an thing shows to players who are sitting inside it. (Think
of how the inside of a car looks compared to the outside.)
3. @success/@osuccess ( @[o]succ <thing>=<message>)
Players will see these messages when the thing is 'successfully'
picked up. The @success is shown to the player who picks up the
To read the next page, simply type 'next'.
Thing (AKA the 'effective player'), and the @osuccess is shown
to everyone else in the room. Remember that the @osuccess will
appear with the name of the effective player stuck onto the
beginning (prepended).
4. @drop/@odrop (@[o]drop <thing>=<message>)
Players will see these messages when the thing is dropped.
The @drop is shown to the player who is dropping the thing,
and the @odrop is shown to everyone else with the effective
player's name prepended.
5. @fail/@ofail (@[o]fail <thing>=<message>)
Fail messages are really only necessary if the thing is @locked
in some way. These messages are shown to players who attempt
to pick up the thing, but do not pass the lock (thus, 'failing'
to pick up the thing'). Format for these is the same as
described above.
And that's it! Once you've created your object, set its value and its home,
@locked it if necessary and set all applicable @messages, your Object is
complete! Congratulations!
To read the next page, simply type 'next'.
Now, if any of the above seemed confusing, check out the sample Object Building
script below. It will probably help make the @messages/@omessage formats
easier to understand. Comments are in parentheses and would not actually be
typed in.
[----------------------------- EXAMPLE -------------------------------]
@create Magic Ring
@describe ring=You see a beautiful gold ring with a red ruby cabochon set into it. It glimmers in the light as you look at it.
@idesc ring=You find yourself inside the ruby cabochon of the Magic Ring! Everything looks so...so RED!
@lock ring=me (Only I can pick up the ring.)
@chlock ring=me (Only I can @chown the ring.)
@flock ring=me (Only I can Force the ring.)
@succ ring=You pick up the ring and put it on.
@osucc ring=picks up the ring and puts it on.
@drop ring=You remove the ring and set it down.
@odrop ring=removes the ring and sets it down.
@fail ring=You reach for the ring, but find you cannot reach it! A kind of bluish force field zaps your hand when you try.
@ofail ring=reaches for the ring, but a kind of bluish force field appears around it, zapping %p hand.*
[------------------------------- END ---------------------------------]
This is the last page of this chapter.
Chapter D: Miscellaneous Concerns
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
A. %Pronoun Substitions
Notice how the @ofail in the example script in section 2 includes a "%p" This
is what is known as a '%pronoun substitution'. In any @Omessage, a MUCK will
replace a '%_' with an word appropriate to that player, usually based on the
player's gender. Other %substitution values may be used, but nearly all MUCKs
recognize the %pronoun substitutions, as detailed below:
===================================================================
%Pronoun Type of Pronoun Male Female Neuter Not Set
-------------------------------------------------------------------
%s Subjective he she it Name
%o Objective him her it Name
%r Reflexive himself herself itself Name
%p Possessive his hers its Name's
===================================================================
If your %pronoun needs to be capitalized (as when it's used at the beginning of
To read the next page, simply type 'next'.
a sentence), just capitalize the letter: %S, %O, %R, %P
....TO READ ON, TYPE Read Book2=3B
B. @Message/@Command Properties
@Messages and @Lock strings are stored in properties on the object. If you're
curious as to where the messages are stored, here's a quick rundown:
=============================================
@MESSAGE ASSOCIATED PROPERTY
---------------------------------------------
@lock _/lok: <message>
@flock @/flk: <message>
@chlock _/chlk: <message>
@desc _/de: <message>
@succ _/sc: <message>
@osucc _/osc: <message>
@drop _/dr: <message>
@odrop _/odr: <message>
@fail _/fl: <message>
@ofail _/ofl: <message>
@idesc _/ide: <message>
To read the next page, simply type 'next'.
=============================================
C. Flags on Things
As previously noted, Flags enable certain permissions to be toggled on and off.
In some cases, they affect how a Thing behaves when a player interacts with
it as well. The trouble with Flags is that they often change from one MUCK
format to the next. Below are some flags typically availabe for use on Things
and the effect they have:
=======================================================================
Flag Flag Name Effect
-----------------------------------------------------------------------
C Chown_Ok Enables another player to take ownership of the
Thing. (See @chown and @chownlock above.)
D Dark* Sets the object so that it does not appear in
the inventory of the room or player that holds
it.
S Sticky When the object is dropped, it returns home.
V Vehicle Permits the Thing to hold Players, enables the
@IDesc.
Z Zombie This makes a Thing into a kind of puppet that
a player can control. Control usually requires
To read the next page, simply type 'next'.
the MPI {Force:} command or a MUF program, but
Players who own Zombie-set objects can see what
the object sees/hears.
=======================================================================
* -- Only a Wizard can set this flag.
The @set command is used to set and unset flags.
To set a flag, type: @set <object>=<flag>
To unset the flag, type: @set <object>=!<flag>
----- End Chapter D.
This is the last page of this chapter.