3.3. Attributes
Get ready. Attributes are the line between building and coding. When you store any kind of data on an object, you're probably doing it with attributes.

Standard attributes
The first kind of attributes are standard attributes. These attributes have a special purpose programmed into the MUX. You set them by typing: @(attribute) (thing)=(text).

Need some examples? You're probably already familiar with the @desc and @sex attributes. The @desc attribute is shown to a person when they look at something, and the @sex attribute is used by +who and various pronouns to tell what sex you are. So, @sex me=None of your business is an example of setting a standard attribute.

You can also abbreviate these attributes, as long as it doesn't conflict with another command. For example, @desc is in fact an abbreviation for @describe, though nobody actually cares.

Verb attributes
The most common kind of standard attribute is the kind that is triggered by simple MUX commands. These commands are generally the type without @'s, at the top of 'help commands'.

Here's a list of these commands and their corresponding attributes.

These attributes are used to set messages and actions when one of these commands is used on an object. They are generically called 'verb attributes'.

Note that the names of these attributes follow a pattern. Consider that there's a verb called 'foo'. The contents of the @foo attribute will be shown to a person who foos the object. The @ofoo attribute will shown to everyone in the room except the person who foos it, with the foo-er's name at the beginning. The @afoo attribute is a command or list of commands that the object does when it gets fooed. If 'foo' were a kind of action so that the object was fooed from somewhere to somewhere else, the @ofoo attribute would be shown to people in the destination room, while the @oxfoo attribute would be shown to people in the room where the object was before it was fooed.

Too abstract? Some examples should help.

@drop bouncy ball=You drop the bouncy ball. It bounces off your foot and hops across the room.
@odrop book=drops the book, which lands on the floor with a THUD.
@enter portal=You enter the swirling portal and travel to someplace mysterious...
@oxenter portal=jumps into the portal, and disappears.
@adesc me="Take a picture! It'll last longer!
@use cookie=You eat the chocolate chip cookie. Mmmm, tasty.
@ause cookie=@set me=destroy_ok;@destroy me
@aconnect me=,pub Gooooooood mooooorning SluggyMUX!

You can see from the @a examples that the commands you use here are the same as the commands you would type yourself. So, the @adesc example would have you say "Take a picture! It'll last longer!" every time someone looks at you, and the @ause example would have the cookie automatically destroy itself when eaten. Observe how you can use ; to separate multiple commands. (If the cookie didn't set itself DESTROY_OK, it would take up to 10 minutes to go away.)

You can find a list of basically all the @-attributes in 'help commands2'. The help file considers these commands, because they are technically commands that you use to SET an attribute. But it makes life so much easier to think of them as attributes themselves.

One more thing: to clear an attributes, just leave out everything starting from the =. For example, @drop book will clear the book's @drop attribute.

Attributes on exits
The preceding attributes mostly applied to objects, rooms, and players, though some of them wouldn't exactly make sense on objects or rooms. But there are only 4 attributes that really make sense on exits: @desc, @succ, @osucc, and @odrop.

@desc does what you think it does - it describes the exit. This is the least important of the four, because nobody ever looks at exits anyway.
@succ is shown to someone when they go through the exit. (The reasoning behind this is that they have 'succ'essfully used the exit.)
@osucc is shown to everyone else when someone leaves the room through an exit.
@odrop is shown to everyone in the destination room when someone comes out of an exit. (The reasoning behind this name is rather strange - in all other cases, @odrop is the opposite of @osucc, so it might as well be here too. If you wish, you can think of the exit picking you up and dropping you on the other side, even though that's wrong.)

Having @osucc and @odrop messages on all the exits makes a place you've built much nicer, because people can see where people are going or coming from, instead of just something like "Squeeky-Bobo has left." or "Squeeky-Bobo has arrived." Once again, for more information, look these commands up in the help files.

Substitutions
In making these messages, you may need to use a pronoun or two. But what pronouns do you use if you don't know what sex the person using the object will be? Obviously, it would sound incredibly stupid to say 'Bob drops the book on his or her foot. He or she yells in pain.' This is why the MUX has substitutions - little things that turn into appropriate pronouns (or special characters, in a few cases) automatically.

Substitutions are generally the character % followed by one letter. The only ones that aren't are those odd 'v' and 'q' ones, which you won't need to use for a while.

Here are some substitutions that it'll be useful to remember:

The capitalized versions of the pronouns - %S, %O, %P, %A, and %N - result in the pronoun being capitalized too. Useful for the beginning of a sentence.

Some examples:

@odrop bouncy ball=throws %p bouncy ball. It immediately bounces straight back and hits %o in the head. %S looks fairly stupid.
@osucc <A>rena=prepares %oself, and enters the Arena.
say Man, I only understand about 50%% of this code.

And now for something completely different...

Introduction to triggers
Triggers are attributes that make an object do something when it hears something else. The simplest form of triggers is the pair of attributes, @listen and @ahear.

@listen doesn't do anything by itself. It should contain a pattern of text to listen for. This text can contain * as a 'wildcard' - * will match any chunk of text, like a player's name, or just arbitrary stuff surrounding a phrase that an object is listening for. In fact, a @listen should usually contain wildcards, or else it won't trigger on anything but one exact line. An example of a @listen with wildcards: @listen greeter=* has arrived.

@listen doesn't do anything without @ahear. An @ahear is a command, or list of commands, just like other @a-attributes, that is triggered when an object hears something matching its @listen.

Example:
@listen ferret=*shiny*
@ahear ferret="OOH! Shiny things? Where?!

Introduction to &-attributes
All this time, and I didn't even get to the other kind of attribute - &-attributes. These attributes can be called (almost) anything you want, and don't do anything on their own. Example:

&foo me=Whee, I'm setting a useless attribute on myself.

To make &-attributes do something, you've got to put code in them, which is a broad enough topic to cover several more sections of this Guide to MUX. In part 4 you'll start to see why you'd want an attribute that doesn't do anything on its own.


[ Previous: More building commands | Contents | Next: The help files ]