Figure 1: zMUD Trigger DialogTriggers and Buttons
What are Triggers?
As introduced in the last chapter, Action Triggers (or just Triggers) allow you to execute commands or send text to the MUD whenever a certain pattern of text is received from the MUD. Triggers are the key to unlocking the tremendous power of a MUD client like zMUD. With Triggers, you can do anything from simple actions, such as automatically eating when your MUD character is hungry, to complex actions such as completely automating your character into a "robot". In this chapter, we will work from simple triggers to complex triggers, building a useful library of functions for players of combat MUDs along the way.
Creating Triggers
There are several ways to create Triggers in zMUD. The easiest way for new users is using the Trigger dialog by selecting Triggers from the View menu, or by clicking on the Triggers button in the button bar. You can also display the Trigger dialog by pressing CTRL-T. In addition to using the Trigger dialog, you can also define Triggers using the zMUD command language. For example, to execute a command when a pattern of text is received from the MUD, you can enter
#TRIGGER {pattern} {command}
into the zMUD command line at the bottom of the screen. Feel free to use either the Trigger dialog or the command language. Both will be used in examples throughout this chapter.
Parts of a Trigger
There are three primary components of a zMUD Trigger: the pattern, the command, and the class. In addition, there are several options for triggers that let you modify their behavior.
The Trigger Pattern is the text received from the MUD that causes the trigger to "fire." Whenever a line of text is received from the MUD, zMUD checks this line against each trigger pattern to determine which triggers to execute. Patterns can range from simple text, to complex expressions, and we’ll explore some of the possibilities in this chapter.
The Trigger Command is the action that you want to take when the pattern is received from the MUD. This action can be a simple string of text to send back to the MUD, or can be a complex series of zMUD commands. A large range of example actions will be demonstrated in this chapter.
The Trigger Class is a name given to a group of related triggers. Triggers within the same Class can be enabled and disabled as a group. Classes also provide you a way to organize your triggers into categories. A trigger is not required to have a class.
The Trigger Dialog
Figure 1 shows the zMUD Trigger dialog. A list of your triggers is shown in the box on the left side of the dialog, while the right side of the dialog displays information about the currently selected trigger. As you select triggers in the box on the left by clicking on them with the mouse, the information on the right will be updated. On the right, you will see the fields for the trigger Class, Pattern, and Command, along with several options.
Figure 1: zMUD Trigger Dialog
To create a new trigger, click the New button in the lower-left corner. Then enter the pattern for the trigger in the Pattern field, and the commands you want to execute into the Command field.
Let’s create a simple trigger that keeps your character from getting thirsty. Click the New button in the Trigger dialog, then type
You are thirsty into the Pattern field, and type drink skin into the Command field. Click the OK button to save your changes and close the dialog.When you create a new trigger, it is enabled by default. You can disable a trigger by clicking the Enable/Disable button located just below the Command field in the dialog, or you can double-click on the trigger in the list box on the left. A green checkmark is displayed to the left of each trigger that is enabled.
To give your trigger a class name, enter a name into the Class field. The drop-down box can be used to select any classes that you have already used. The Enable Class and Disable Class buttons can be used to enable or disable all triggers grouped within the class shown in the Class box.
The options shown just to the right of the Enable/Disable button allow you to change certain properties of the currently selected trigger. Normally, the "state" of a trigger (whether it is enabled or disabled) is stored in your setting file when you save it, and restored when you load this character again later. Many times you want your triggers enabled or disabled when you load them, regardless of how they were last saved. For example, you want a trigger that automatically logs you into the MUD when the
Username pattern is received to be enabled whenever you start. The When loaded option boxes allow you to control whether the trigger is enabled or disabled when you first load them.Normally, the trigger patterns are tested when each new line of text is received from the MUD. Some text, such as your MUD prompt, is sent from the MUD without a new-line after it. For example, when your MUD displays the
Username: prompt, the MUD waits for your answer before moving to the next line on the display. In order to trigger on this type of text, you should select the Trigger on Prompt option. Otherwise you should normally just select Trigger on Newline, which is the default setting.Finally, select the Case Sensitive option if you want zMUD to match the upper and lowercase characters of the pattern exactly as specified. Otherwise, zMUD normally ignore upper and lower case distinctions when matching the patterns.
Testing Triggers
In the lower part of the Trigger dialog is a section allowing you to test your triggers. When you enter text into the Test box and then click the Test button, you will be told whether the text you enter matches the currently selected trigger.
Test your "thirsty" trigger. Make sure it is selected by clicking on it in the list box on the left. Notice that zMUD automatically fills in sample testing text that will match your trigger. If you click the Test button when the text
You are thirsty is in the test box, you will be told that the pattern matches. Type You are hungry into the testing box and click the Test button and you will see that this text does not match the pattern.For simple triggers, the testing function isn’t very useful, but as we show more complicated examples, testing will prove to be very useful in understanding how zMUD triggers work.
Using Wildcards in the pattern
A "Wildcard" is a symbol that represents various characters to be matched in the pattern. For example, the asterisk wildcard (*) matches any number of any characters. The question mark wildcard (?) matches any single character. zMUD has many special wildcard characters as shown in Table 1.
Table 1: Wildcard symbols for trigger patterns
|
Wildcard symbol |
Description |
Sample pattern |
|
* |
Match any number of any character |
Abc 123 |
|
? |
Match any single character |
X |
|
%d |
Match any number of digits |
1234 |
|
%w |
Match a word |
Hello |
|
%s |
Match any number of spaces or tabs |
|
|
%x |
Match any number of alphanumerics |
Test123 |
Keep in mind that zMUD assumes an asterisk * at the beginning and end of your pattern. Thus, if you enter a pattern of
says, it will match He says, She says, Zugg says, or any other line that contains the word says. Using a pattern of *says* will match the same lines, but will be much slower since zMUD must specially handle the * characters.Capturing text from the MUD
The main use for wildcard characters is to help capture certain text received from the MUD. For example, you probably don’t just want to trigger when any line contains the word
say, but you might want to know who said something. The pattern %w says will match a line that contains any word followed by says. In order to capture the text that is received, enclose the part of the pattern you want to capture within parenthesis. For example, (%w) says will capture that word sent by the MUD that matches the %w wildcard. If the line from the MUD contained Zugg says, then the word Zugg will be captured.Where does captured text go? It is stored in "parameters." Parameters are temporary variables that zMUD uses to hold the captured text. These parameters can be used in the trigger command to perform a specific action, but are then discarded. You refer to a parameter using the syntax of
%n where n is the parameter number. For example, %1 represents the first parameter. Up to 99 parameters can be stored by zMUD for each trigger.Let’s create a useful trigger that will be used when we need to take a short break from the MUD. While we are on our break, we want to reply to anyone that tries to tell us something to let them know that we are momentarily away from the keyboard. In MUD jargon, this is know as "afk" (away from keyboard). In the Trigger dialog, click the New button. Type
afk into the class field. For the Pattern, enter (%w) tells you. This will cause the trigger to execute when a line is received from the MUD that contains any word, followed by the phrase tells you. The parenthesis around the %w tells zMUD to capture the word from the MUD and store it into the first parameter, %1. Thus, in the Command field, enter tell %1 I am away from the keyboard. When the trigger executes, the %1 parameter will be replaced with the actual word received from the MUD, which is the name of the person that tried to tell you something.Testing revisited
When using wildcard symbols and capturing text from the MUD, the trigger testing section becomes much more useful. Select the
afk trigger that you created in the previous example, and click the Test button. You’ll notice that the value of the %1 parameter is shown as abc, which is the default sample pattern. In the test field, enter Zugg tells you Hi and click the Test button, and you will see the word Zugg stored as %1. Also, notice that the phrase Zugg tells you is highlighted in the test pattern, indicating the part of the pattern that matches your phrase.Trigger security
Before going wild with triggers, you should keep in mind several important security tips to prevent other players from taking advantage of you. For example, let’s look at a very primitive "robot" trigger:
#TRIGGER {Zugg tells you (*)} {%1}
Remember that * matches any number of characters, and putting it within parenthesis saves the result to the first available parameter. Using the parameter
%1 in the command expands to whatever was matched by the pattern. Thus, if you receive the command Zugg tells you drink skin, the trigger will send drink skin back to the MUD. This is a simple way to automatically control one character using another.Maybe you have already spotted the potential problems with this trigger. What if a troublemaker on the MUD types:
Shout Zugg tells you drop all;quit
This causes the MUD to send
Troublemaker shouts Zugg tells you drop all;quit
to all players on the MUD. Since this line matches the pattern, your character will send
drop all to the MUD, then your character sends the quit command to the MUD! Probably not what you wanted to do. In order to prevent this type of trouble the asterisk character (and other wildcards) will not match the special characters used by the zMUD programming language, such as ; to separate commands. Other special characters that are not matched include @ and %. Because of the ; in the line shown above, your trigger actually will not fire. This is protection for you automatically added by zMUD.However, even though zMUD doesn’t match text containing the ; character, what if the troublemaker just enters:
Shout Zugg tells you drop all
Which causes the MUD to send
Troublemaker shouts Zugg tells you drop all
to all characters. This time your trigger will fire and your character will
drop all that it is holding. The next section addresses the fix for this. For even more information on trigger security, look at the end of this chapter in the Advanced Security section.Beginning and end of line symbols
To force your pattern to match the beginning of a line, start your pattern with a
^ character. To force your trigger to match the end of a line, end your pattern with a $ character. These two characters prevent the automatic * from being added to the beginning or end of a pattern. In the example from the previous section, using a pattern of ^Zugg tells you (*)$ will now prevent troublemakers from causing problems since there is no way for them to send you text like this. The beginning and end of line markers are processed quickly by zMUD, and you should generally use them as much as possible to prevent unwanted or malicious lines from firing your triggers.Making your own wildcards
What if you want to bypass the built-in trigger security and create a trigger that will match the ; character? zMUD allows you to create your own wildcards so that you can match anything you want. To create your own wildcard pattern, you simply enter all of the characters you want to match within square brackets. For example, the pattern
[0123456789] is the same as the built-in %d wildcard for matching any number of digits. You can condense a range of characters using the hyphen. Thus, [0-9] is also the same as the %d wildcard. Instead of the hyphen, you can also indicate a range using two dots together, as in [0..9]. So, to create a pattern that matches any number of alphanumeric characters including the ; character, you would use a pattern like [a-zA-Z0-9 ;]Variables in triggers
Any variable references in the pattern are automatically expanded just before the pattern is tested against the line of output from the MUD. For example, maybe you want only a specific person to control your robot. So, you create a variable called
friend and give it the value of Zugg.#VAR friend Zugg
#TRIGGER {^@friend tells you (*)} {%1}
Now by changing the value of the
@friend variable you can decide what player is allowed to control your robot.Matching more than one string
What if you want your robot controlled by more than one player? For example, you would like both of these lines to fire your trigger:
Zugg tells you drink skin
Aurora tells you drink skin
You could set up two different triggers, but this isn’t very efficient. zMUD provides a pattern that allows you to combine these similar triggers into one called the OR operator. Simply list each phrase that you want to match, separated by the
| character, and enclosed within curly braces. For example, the above lines can be matched with the pattern:{Zugg|Aurora} tells you
Using the variable substitution described in the previous section allows us to create a very powerful trigger:
#TRIGGER {^{@friends} tells you (*)} {%1}
Now, if you assign the value
Zugg|Aurora to the variable friends, anyone listed in this variable can control your robot. Variables that contain strings separated by the bar | character are called string lists in zMUD and there are several built-in functions described in the programming chapter for manipulating them.Enabling and disabling trigger classes
While you can enable and disable classes of triggers using the buttons in the Trigger dialog, you can also use the
#T+ and #T- commands. For example, to enable the afk trigger defined earlier in this chapter, just type #T+ afk into the command line. Controlling trigger classes from the command language is a powerful way to determine exactly which triggers are enabled at any given time.Creating Buttons
Having to type
#T+ afk or #T- afk whenever you want to enable or disable your afk trigger is almost as bad as having to open the Trigger dialog and click the buttons. You could assign these commands to macro keys on the keyboard, but you would need to define two keys: one for the #T+ afk command and one for the #T- afk command. Not only will this use up keys on your keyboard quickly, but you will always have to remember which keys you assigned these commands to, and you will never really know whether your afk trigger is enabled or disabled without looking at the Trigger dialog.Buttons are the solution to this problem, and demonstrate a feature that is unique to graphical MUD clients like zMUD. To create a button, select Make Button from the Action menu to display the Button dialog shown in Figure 2.
Figure 2: Button dialog
Buttons are numbered starting with one and are listed in the list box on the left side of the dialog. On the right side, specific information about the currently selected button is shown. You select a button by clicking on it in the list box on the left. When you use the Make Button command in the Action menu, a new, blank button is automatically added and automatically numbered. Simply enter the caption for this button and then enter the command to be sent when the button is pressed in the On Command field, then click OK to save the button and close the dialog box.
zMUD allows two different types of buttons: push buttons and toggle buttons. A push button is clicked once, executes its On Command and is released. A toggle button switches between two states: on and off. When a toggle button is first clicked, its On Command is executed; then it is shown as pushed and the On Caption is shown in place of the Off Caption. When the toggle button is clicked again, the Off Command is executed and the button is shown as off again, with the Off Caption displayed on the face of the button.
One of the most common uses of toggle buttons is to control triggers using the
#T+ and #T- commands. You enter the #T+ command into the On Command field, the #T- into the Off Command field. Now just by looking at the state of the button you can see if your trigger is off or on, and you can turn your trigger on or off by just clicking on the button.Time to try it. Select Make Button from the Action menu. Click the Toggle option so that a checkmark appears in the box. In the Off Caption, enter
afk. In the On Command, enter #T+ afk, and in the Off Command enter #T- afk. Then click OK. You should see a button bar appear at the top of your MUD window with a single button labeled afk. When you click this button, your afk trigger is enabled. When you click again, your afk trigger is disabled.In addition to clicking on buttons, you can also control buttons using the zMUD command language
#BUTTON command. Just indicate the button number you want to activate. For example:#BUTTON 1
will toggle the
afk button that we just defined. In fact, you can then assign the #BUTTON 1 command to a macro key. Now when you press the macro key on your keyboard, the graphical button on the screen will toggle and your trigger will be enabled or disabled.Putting it all together
Now that we have learned about triggers and buttons, lets develop a useful set that will help in most combat MUDs. By the end of this section, we will have developed triggers and buttons to automatically loot money from corpses, automatically sacrifice corpses, automatically split any money among all members of a group, and a way to automatically join the leader of your group in battle. Some MUDs have these types of features built-in, but many do not. If you play a MUD without these features, these buttons will save you countless keystrokes and make your MUDding experience even more fun. In fact, you’ll wonder how you lived without these features.
Note that the triggers developed in this section are MUD specific. If your MUD outputs information in a different format, you will need to modify these triggers. If you want to load a completed set of these buttons and triggers, load the COMBAT.MUD settings file included on the zMUD CD-ROM in the Samples folder.
Autoloot
At the end of a combat session on a DIKU MUD when you successfully kill the mob, a message like this will appear:
The goblin is DEAD!
You receive 34 experience points.
Usually, the first thing you want to do after killing a creature is loot all of its money and treasure:
get all corpse
So let’s create a trigger for this:
#TRIGGER {^You receive %d experience points.$} {get all corpse} autoloot
The
autoloot at the end of this command defines the class name for this trigger. Next, create a button to toggle this trigger. Use Make Button from the Action menu, and enter autoloot for the Off Caption, #T+ autoloot in the On Command, and #T- autoloot in the Off Command.When creating triggers like this, pick your pattern carefully. In this example, it is important to trigger on the "experience points" line, rather than the "is DEAD" line. Why? If you are wandering around the MUD and come across a battle, another player might kill a mob, generating the "is DEAD" line. However, the "experience points" line will not be generated since you did not kill the mob. If you triggered on the "is DEAD" line, you would end up stealing the money and treasure from the mob that someone else killed. This is generally frowned upon and can get you kicked off of most MUDs. However, for MUDs that allow it, evil players might actually want to implement something like this.
Controlling what your loot
You don’t always want to loot everything in a corpse. When killing mobs that carry cursed equipment, you really only want to loot the coins carried by the mob. So, let’s modify the trigger that we just generated. Go into the Trigger dialog and select the
autoloot trigger. Change the command to:get @lootcmd corpse
Click OK to exit the dialog, and then define the
@lootcmd variable by typing#VAR lootcmd all
in the command line. Now our
autoloot trigger will loot anything we want from the corpse. Let’s create a second button to control this. From the Make Button command, click the Toggle option, enter all for the Off Caption, and all.coins as the On Caption. In the On Command, enter #VAR lootcmd all.coins and in the Off Command, enter #VAR lootcmd all. Click OK to save and exit the button dialog. Now you have a second button that controls the value of the @lootcmd variable used by the autoloot trigger.Sacrificing the corpse
In many MUDs, you get experience points or gold for sacrificing the corpse. This cleans up after your battles and keeps the MUD happy since it doesn’t have to keep track of corpses laying all over the place. Thus, after looting, you want to enter the command
sac corpse
The pattern for this trigger is the same as for the
autoloot trigger, so rather than creating a new trigger, let’s combine these two by modifying the autoloot command again. Go to the Trigger dialog and select the autoloot trigger. Change the command to:get @lootcmd corpse;#IF @autosac {sac corpse}
This command uses a new variable called
@autosac and tests to see if it is true using the #IF command. If the variable is true, then the sac corpse command is sent to the MUD. Let’s create a button to control this new variable. Select Make Button again and click the Toggle option. In the Off Caption, enter AutoSac. Then, in the Variable field, enter @autosac. When you enter the name of a variable in to the Variable field, zMUD automatically stores zero (false) when the button is off, and stores one (true) when the button is on. Click OK to save your button and close the dialog. Now when the AutoSac button is on, the autoloot trigger will sacrifice the corpse just after looting it.Sharing money with your group
Great! Now whenever you get experience for a mob being killed, you automatically grab all the gold and sacrifice the corpse. This will happen automatically using triggers, so you will likely beat anyone else in your group to this (unless they are using zMUD too!). However, when MUDding in a group, keeping all of the gold to yourself is considered very rude. There is usually a command on the MUD to split the gold into equal shares for the other members of the group. In order to split this gold, you need to know how much gold you got from your looting. Usually when you loot a corpse, you will see a message like this:
You get 1000 coins.
Let’s create a trigger that captures this gold and splits it among the group. Enter the following trigger into the command line:
#TRIGGER {^You get (%d) coins.$) {split %1} autosplit
The amount of gold is matched by the
%d wildcard and captured into the %1 parameter. The trigger command uses the value in %1 with the split command on the MUD. A class name of autosplit is given to this trigger.The next step is to control this trigger using another button. From Make Button, select the Toggle option, and enter
AutoSplit into the Off caption. In the On Command, enter #T+ autosplit, and in the Off Command, enter #T- autosplit. Click OK to save your work. Now you have a button that you can use to control whether the gold coins that you loot will be split among your group members.Notifying your group
When you are using functions like automatic looting and sacrificing while in a group, it is helpful to let your group members know about what you are doing. For example, if they know that you are automatically looting just coins and then sacrificing the corpse, they may want you to turn that off if they are about to kill a mob that has a good piece of equipment. Your group members will be very unhappy if you sacrifice a corpse containing a powerful object!
When you are not in a group, you probably don’t want to tell the world what you are doing, but may just want to see a quiet message to yourself. Thus, lets create a command that either sends a message to our group, or just sends a message to ourselves. Let’s call the command:
notify#ALIAS notify {#IF @quiet {#SAY} {gtell}}
This command looks at the value of the
@quiet variable to determine whether to use the built-in command #SAY, which prints a quiet message on your screen, but doesn’t send anything to the MUD, or whether the gtell MUD command is used, which sends a message to all members of your group on the MUD.Create a button to control the
@quiet variable. Select Make Button and click the Toggle option. In the Off Caption, enter Broadcast, and in the On Caption enter Quiet. Enter @quiet into the Variable field and click OK to save your work.The next step is to use the new notify command in all of your other buttons. For example, in your
AutoLoot button On command, change it to#T+ autoloot;notify Autolooting @lootcmd is ON
and in the Off command, change it to:
#T- autoloot;notify Autolooting is OFF
For the
AutoSac button, enter notify Autosacrificing is ON in the On Command, and enter notify Autosacrificing is OFF in the Off Command. Go ahead and add other appropriate notify messages to the On and Off commands of your various buttons.Joining your leader in battle
The final set of triggers are the most complicated and will require the most modification depending upon the messages displayed by your particular MUD. When your group is about to fight a large mob, one person in the group is usually designated at the "tank." This means that they will hit first and receive most of the damage from the mob. Once the tank hits the mob, it is very important for the other fighters in the group to join into the battle as soon as possible. Some MUDs handle this automatically, but on other MUDs you need to use the
join or assist commands along with the name of the tank you are joining in battle.The trick to this trigger is figuring out the pattern needed to trigger it. How do you know that a character has started a battle? In fact, maybe the tank didn’t start the battle at all, but the mob was aggressive and immediately started hitting your group member as soon as you entered the room!
To start, let’s first define a list of people that are in your group. This will be needed since you want to assist anyone in the group that might start fighting. Let’s create a variable called
@group and give it a blank value:#VAR group ""
In fact, we want this variable to be cleared whenever we start the MUD so let’s give it a blank default value also:
#VAR group "" ""
Now, every time we load these settings, the
@group variable will automatically be cleared. Next, we need a button to easily set the members of our group. Use Make Button and in the Off Caption enter Group. In the On Command, enter #prompt group "Enter names of group members separated by |". This command will prompt you to enter the names of people in your group, and to put a bar | character between each name.You can handle group members joining and leaving the group with a couple of simple triggers:
#TRIGGER {^(%w) has joined the group.$} {#VAR group %additem(@group,%1)}
#TRIGGER {^{%w} has left the group.$} {#VAR group %delitem(@group,%1)}
The
%additem and %delitem are built-in zMUD functions that add and remove names from a string list and automatically handle the bar | character.Now that we have a list of people we want to assist in battle, how do we know when they have attacked a mob? Well, the MUD usually displays text like this:
Zugg hits the goblin hard
Zugg massacres the goblin
Zugg misses the goblin
Zugg scratches the goblin
On some MUDs, it might say something like:
Zugg the Veteran hits the goblin
So, one way to handle this is to define a bunch of triggers like:
#TRIGGER {({@group}) *hits} {assist %1} autojoin
The
{@group} expands @group to the names of people we want to assist, and the {a|b|c} pattern syntax allows us to match lines with any group members’ name in it. By putting parenthesis around this pattern, the actual name of the person that has hit the mob is captured into the %1 parameter. Thus, the assist %1 command tells the MUD to assist the character that has hit the mob. However, sometimes the message contains the word "hit", sometimes "misses", sometimes "massacres", etc. In fact, most MUDs have dozens of messages that they use for this. Should you create dozens of triggers? You could, but how about a single massive trigger like:#TRIGGER {({@group}) *{hits|misses|massacres|scratches}} {assist %1} autojoin
This trigger will now fire whenever one of your group members starts fighting a mob.
There is one problem left: this trigger will keep firing on every line in the battle, sending the
assist command to the MUD each time. We need a way to control this so that the trigger is only executed once. The best way to do this is to change the trigger command to:assist %1;#T- autojoin
Now when the trigger fires, the last thing it does is disable itself. We want to re-enable this trigger when the mob is dead, so we create another trigger:
#TRIGGER {is DEAD!} {#T+ autojoin} endjoin
This trigger turns the
autojoin trigger back on when the mob is dead. But how do we turn on this trigger? You guessed it: go back to the autojoin trigger and change the trigger command to:Assist %1;#T+ endjoin;#T- autojoin
And change the trigger command for the
endjoin trigger to#T+ autojoin;#T- endjoin
Now you have a pair of triggers, called
autojoin and endjoin that enable and disable each other properly.The final step is to create a button that turns on and off the
autojoin trigger. This probably seems fairly mundane by now: select Make Button, check Toggle option, enter AutoAssist into Off Caption, enter #T+ autojoin;notify Autoassisting ON into the On Command, enter #T- autojoin;notify Autoassisting OFF into the Off Command and click OK.That’s it! You have now created a powerful set of tools to help you win battles and help your group on a combat MUD. Your group members will appreciate the responsiveness of your character in battle, and you can just sit back and watch the battles fly across your screen. You’ll be amazed how much this helps your MUDding.
Advanced Buttons
In the Button dialog, there is an Advanced tab that displays additional information about each button. In this dialog, you can control the precise location and size of buttons, change their colors, and add graphical icons to the buttons. In fact, if you set your working directory to the Samples folder on the CD-ROM and load the COMPASS.MUD file, shown in Figure 6, you will see how fancy you can get with the button bar.
Figure 3: Advanced buttons from COMPASS.MUD settings
There are also built-in functions %buttoncol to control the color of buttons until program control. For example, the command
#IF (@hp < 100) {%buttoncol(1,red)} {%buttoncol(1,green)}
will set the color of the first button to either red or green, depending upon the value of the
@hp variable. You can also use the %buttonicon function to change the icon on a button under program control. Button icons are Windows BMP graphic files that are easily created in the Paintbrush program supplied with Windows. Icons with 16 colors and 20 bits wide, 20 bits high make good graphics for default buttons. These BMP files must be stored in the same location as the .MUD setting file that uses them.When using the size and location controls in the Advanced tab, the button you are working on is automatically saved, and the actual button located on the button bar of your MUD window will move and change size as your adjust it. At this time, zMUD does not allow drag and drop editing of the button bar. Instead, you must move and resize buttons by specifying numeric positions and sizes in the dialog box. This makes advanced button creation a bit tedious, but it’s something that most people won’t be doing very often.
Finally, in the Location tab in the Button dialog, you can change whether the button bar is displayed at the Top, Bottom, Left, or Right edges of your MUD window. Or, you can select None to turn off the button bar.
Advanced Trigger Security
Since we addressed security earlier in this chapter, here is one more complex scenario to consider. On some MUDs, people can shout long messages that are automatically word-wrapped by the MUD before being received by your character. Since these wrapped lines look like separate lines to zMUD, it is possible to someone to figure out just how many characters are needed to wrap the "Zugg tells you" part of the line onto the next line. For example, something like this:
Shout this is junk to make the line wrap Zugg tells you drop all
Might result in the following two lines being sent by the MUD
Troublemaker shouts this is junk to make the line wrap
Zugg tells you drop all
Now, how to you tell the difference between this case and the case where you really do send a tell to your character? The trick is to examine one of the built-in variables called
%line2 which contains the line just before the line that fires the trigger. Thus, you can use a command such as#IF %pos("shout",%line2) {tell %1 Nice try!} {%1}
Here we check to see if the word "shout" is in the preceeding line. If so, we send the troublemaker a nice try message, otherwise we execute the command for our robot.
Exercises
Here are some exercises to test your knowledge of triggers. Some of these are tricky, and the answers are in the appendix.