So, back in part 3.3, you may recall a little section shoved in at the end about &-attributes. These are attributes that don't do anything on their own. So if they don't do anything, what do you do with them? This section describes various ways you can make these attributes do things.

Using @trigger
Any attribute can contain a list of commands. The object will run these commands when you @trigger the attribute. You do this by typing: @trigger (object)/(attribute)

Example: @trigger bazooka/fire
This would make the bazooka do all the commands in its &FIRE attribute. The attribute could be something like this: &fire bazooka=@emit/room %n fires %p bazooka! %r*Ka-BLAM!*

That code uses a command that's probably new to you - @emit. This sends a message, kinda like say or pose, except that it has nothing before it. Not even your name. The command also has the switch /room, which makes @emit send the message to the whole room even if it's inside something (for example, being held by a player).

You may have noticed that you use the same kind of command list in @trigger-able attributes and @a-attributes. If you want, you can even trigger an @a-attribute - for example, @trigger bouncy ball/adrop - and it'll run that command list. So in this example, the ball would act as if it had been dropped, and do whatever was in its @adrop.

$-commands
Now, I assume that someone sane wouldn't want to type @trigger bazooka/fire just to shoot their bazooka. And maybe you'd want to give the bazooka to someone else, but don't want to @chown it to them - you can only @trigger objects that you control. So, let me introduce $-commands. Person reading this page, meet $-commands. $-commands, meet person reading this page.

$-commands let you define a command that will make the object run a list of other commands. You set them inside an attribute, and they have this form: $(command):(action-list)

Here, (command) is the command you want to define. You can call it whatever you want. Everything between the $ and the : is considered to be the command. Everything after the : is a command-list just like you'd put in a trigger-able command.

So, a nicer bazooka that used $-commands would be coded like this: &fire bazooka=$fire:@emit/room %n fires %p bazooka!%r*Ka-BLAM!*

So now, when you type 'fire', you'll fire your bazooka. You could give the bazooka to someone else and they could use it just as well.

Keep in mind that the $-command that you type doesn't have to have anything to do with the attribute name. The attribute didn't have to be &FIRE, it could just as well have been &WIBBLE.

Wildcards and stuff
Remember using wildcards (like *) in a @listen? You can use them in $-commands too. So if you wanted the ability to fire AT a specific person, you'd want to change the command to accept more input. So it would start with $fire *:

Of course, you'll need to be able to tell just what matched the wildcard. It turns out that wildcards get turned into the substitutions %0 through %9. You can use these in @listen too - I just didn't bother to talk about them then. So the bazooka code (Why do I keep coming back to the bazooka? Because it's fun to type the word "bazooka".) would be: &fire bazooka=$fire *:@emit/room %n fires %p bazooka at %0!%r*Ka-BLAM!*

For an example of something with more than one wildcard, say you wanted to make the command more flexible so you could type 'fire at (player)' or 'fire toward (player)' or something: &fire bazooka=$fire * *:@emit/room %n fires %p bazooka at %1!%r*Ka-BLAM!*

Note how %0, the first asterisk, is ignored in the command. Though I suppose it'd make sense if you wanted to change 'at' to '%0'. The important part is that, since it's the second asterisk, the player has become %1 in this command.

^-commands
@trigger is to @listen as $ is to ^. You basically use ^ the same way as $, but the difference is that ^ responds to the object hearing something, while $ responds to a player typing something.

For ^-commands to work, you have to @set the object MONITOR first, or else the object won't hear anything.

What's the use of ^-commands when there's @listen? Well, each object has only one @listen, but you can put as many ^-commands on it as you want. That's essentially the only difference.

It really really works just like $-commands. You even use wildcards the same way. So instead of explaining everything again, I'll just give a cheesy example. &hello greeter=^* has arrived.:say Welcome, %0!

The enactor
In many cases it will be useful for a command to do something to the person or object who caused the command to happen. To do this, you use a substitution, like the ones for pronouns that were introduced in 3.3. The substitution %# is replaced by the DB number of whoever caused that command to run - this could be because they ran a $-command, they triggered an @a-attribute, or they did something that was heard by a @listen or a ^-command.

Time to introduce another command: @pemit. This command is a cross between a page and an emit. Hence the name. It sends some text, without anything around it, to one player only. Instead of a name like you'd use in page, though, you typically use a DB number to @pemit, because you can pemit to objects such as puppets, not just players.

So if you type @pemit me=foo, you'll see the word 'foo' on a line by itself, having @pemitted it to yourself. (The 'think' command does the same thing in this case.)

What do these have to do with each other? Well, @pemit and %# are a useful combination. Let's use that "greeter" again for an example. Let's say we want it to welcome people out loud so that everyone can hear, but send another message to the person who's just coming in. Here's how it would be done?

&hello greeter=^* has arrived.:say Welcome, %0!; @pemit %#=If you like this place I've built, send me a @mail.

In this case, the enactor, or %#, is the person who arrived. After saying "Welcome" out loud, the greeter sends a @pemit to %#, so that they see 'If you like this place I've built, send me a @mail.' when they enter the room, and others in the room don't see it.