Tracking Levels and Wish Protections in MUSHClient

In this article, we walk through creating some aliases and triggers that will allow you to track any wish protections (such as from web, marbu, dirt kick, etc.).

Tracking wish protection

If you’d like to see the payoff for your well-spent quest points, you can add the following alias to print your protection stats.

Copy the following XML, and then hit Ctrl-Shift-9 in MUSHClient to open the Aliases page.  Click the Paste button and your new alias will be created:

<aliases>
<alias
match=”protectionstats”
enabled=”y”
send_to=”12″
sequence=”100″
>
<send>Note(GetVariable(‘n_levels’) .. ” levels recorded so far.”)
Note(GetVariable(‘n_dirt’) .. ” dirt attacks prevented.”)
Note(GetVariable(‘n_web’) .. ” web attacks prevented.”)
Note(GetVariable(‘n_marbu’) .. ” marbu attacks prevented.”)
Note(GetVariable(‘n_teleport’) .. ” teleports prevented.”)
Note(GetVariable(‘n_vorpal’) .. ” vorpals prevented.”)</send>
</alias>
</aliases>

Note: if you don’t have any of the above wishes, this would be a good opportunity to track the attacks that DO affect you!  Then just remove the “prevented” word in the above alias, and your report will make sense.

Next, we’ll start filling in those variables.

Creating a level up trigger

Copy the following XML, and then hit Ctrl-Shift-8 in MUSHClient to open the Triggers page.  Click Paste and your new trigger will be created:

<triggers>
<trigger
clipboard_arg=”1″
enabled=”y”
expand_variables=”y”
match=”You raise a level! You are now level *.”
send_to=”12″
sequence=”100″
>
<send>– Search for equipment
SetVariable(‘level’, %1)
SetVariable(‘tierlevel’, GetVariable(‘level’) + 10)
Execute(‘dinv search level ‘ .. GetVariable(‘tierlevel’))
Note(‘New level: ‘ .. GetVariable(‘level’) .. ‘. Searched for gear at level ‘ .. GetVariable(‘tierlevel’))

— Set n_levels
if GetVariable(‘n_levels’) == nil then
SetVariable(‘n_levels’, 0)
end

SetVariable(‘n_levels’, tonumber(GetVariable(‘n_levels’)) + 1)</send>
</trigger>
</triggers>

Now, I threw in a bonus here, which will search for any equipment at your new level, each time you level up.  To ensure it works, create a variable called ‘tierlevel’ with your tier (0, 1, etc.).  If you don’t have dinv installed, or don’t want to use this portion, simply remove the top section of the <send> block, and only keep the part below “Set n_levels”.

This trigger will start tracking the number of levels you have risen from the time you created the trigger.

Creating the protection triggers

Now you can create the following triggers (using the same Paste method above):

Dirt Kick

<triggers>
<trigger
custom_colour=”11″
enabled=”y”
group=”detections”
make_underline=”y”
match=”Unseen * dirt*”
send_to=”12″
sequence=”100″
>
<send>if GetVariable(‘n_dirt’) == nil then
SetVariable(‘n_dirt’, 0)
end

SetVariable(‘n_dirt’, tonumber(GetVariable(‘n_dirt’)) + 1)
Note(GetVariable(‘n_dirt’) .. ” dirt attacks avoided in ” .. GetVariable(‘n_levels’) .. ” levels!”)</send>
</trigger>
</triggers>

I no longer know the text that would appear if you actually got dirt kicked in your eyes, but I’m hoping someone will provide an example in case you don’t have the wish and want to track how many times you’ve had your eyes dirt-kicked.

Vorpal

If you don’t have the novorpal wish, you can track it here:

<triggers>
<trigger
custom_colour=”1″
enabled=”y”
group=”detections”
make_underline=”y”
match=”* DECAPITATES you!*”
regexp=”n”
send_to=”12″
sequence=”100″
>
<send>if GetVariable(‘n_vorpal’) == nil then
SetVariable(‘n_vorpal’, 0)
end

SetVariable(‘n_vorpal’, tonumber(GetVariable(‘n_vorpal’)) + 1)
Note(GetVariable(‘n_vorpal’) .. ” vorpal attacks in ” .. GetVariable(‘n_levels’) .. ” levels!”)</send>
</trigger>
</triggers>

If you do have the novorpal wish, track protections with this:

<triggers>
<trigger
custom_colour=”1″
enabled=”y”
group=”detections”
make_underline=”y”
match=”^Unseen (.*?) (head|decapitat)(.*?)$”
regexp=”y”
send_to=”12″
sequence=”100″
>
<send>if GetVariable(‘n_vorpal’) == nil then
SetVariable(‘n_vorpal’, 0)
end

SetVariable(‘n_vorpal’, tonumber(GetVariable(‘n_vorpal’)) + 1)
Note(GetVariable(‘n_vorpal’) .. ” vorpal attacks avoided in ” .. GetVariable(‘n_levels’) .. ” levels!”)</send>
</trigger>
</triggers>

Web

<triggers>
<trigger
custom_colour=”1″
enabled=”y”
group=”detections”
make_underline=”y”
match=”Unseen * web*”
send_to=”12″
sequence=”100″
>
<send>if GetVariable(‘n_web’) == nil then
SetVariable(‘n_web’, 0)
end

SetVariable(‘n_web’, tonumber(GetVariable(‘n_web’)) + 1)
Note(GetVariable(‘n_web’) .. ” web attacks in ” .. GetVariable(‘n_levels’) .. ” levels!”)</send>
</trigger>
</triggers>

Marbu

If you don’t have the nomarbu wish, you can track it here:

<triggers>
<trigger
custom_colour=”7″
enabled=”y”
group=”detections”
make_underline=”y”
match=”* poison * your eyes stream in agony*”
send_to=”12″
sequence=”100″
>
<send>if GetVariable(‘n_marbu’) == nil then
SetVariable(‘n_marbu’, 0)
end

SetVariable(‘n_marbu’, tonumber(GetVariable(‘n_marbu’)) + 1)
Note(GetVariable(‘n_marbu’) .. ” marbu attacks in ” .. GetVariable(‘n_levels’) .. ” levels!”)</send>
</trigger>
</triggers>

If you do have the nomarbu wish, track it this way:

<triggers>
<trigger
custom_colour=”7″
enabled=”y”
group=”detections”
make_underline=”y”
match=”Unseen* poison *”
send_to=”12″
sequence=”100″
>
<send>if GetVariable(‘n_marbu’) == nil then
SetVariable(‘n_marbu’, 0)
end

SetVariable(‘n_marbu’, tonumber(GetVariable(‘n_marbu’)) + 1)
Note(GetVariable(‘n_marbu’) .. ” marbu attacks in ” .. GetVariable(‘n_levels’) .. ” levels!”)</send>
</trigger>
</triggers>

Teleport

I’ve never encountered this one, but so far this is my guess for preventing a teleport:

<triggers>
<trigger
custom_colour=”1″
enabled=”y”
group=”detections”
make_underline=”y”
match=”Unseen * teleport*”
send_to=”12″
sequence=”100″
>
<send>if GetVariable(‘n_teleport’) == nil then
SetVariable(‘n_teleport’, 0)
end

SetVariable(‘n_teleport’, tonumber(GetVariable(‘n_teleport’)) + 1)
Note(GetVariable(‘n_teleport’) .. ” teleport attacks in ” .. GetVariable(‘n_levels’) .. ” levels!”)</send>
</trigger>
</triggers>

Summing up

Once you’ve created either the positive or negative detection triggers, you can run your “protectionstats” alias to see how many things have been either done to you or stopped from being done to you, compared with the number of levels.  An example of my output is:

154 levels recorded so far.
130 dirt attacks prevented.
78 web attacks prevented.
44 marbu attacks.
0 teleports prevented.
0 vorpals prevented.

Due to this, I suspect my teleport and vorpal prevention triggers may be off, but I’ll correct it as necessary.

Read more
No Comments

More MUSHClient aliases

Just to build on my article, I’ll add some more useful aliases I’ve used:

<aliases>
<alias
match="do * *"
enabled="y"
send_to="12"
keep_evaluating="y"
sequence="100"
>
<send>local num = %1

for i = 1,num,1 do
Execute ("%2")
end</send>
</alias>
</aliases>

This lets you repeat an action.  Let’s say you’re at Pixie, our healer:

do 10 heal heal

This will run the command “heal heal” 10 times

Read more
No Comments

MUSHclient Meta Aliases and useful Triggers

First, I recommend you read the excellent “Mushclient protips” guide by notwalking.
 
After writing some basic aliases, you may have noticed that you do the same thing over and over when defining an alias.  This is the idea behind MUSHclient’s built-in meta alias, “#alias {*} {*}”, which allows you to quickly define an alias from the prompt.
 
We can build on this concept, along with a little scripting, to create some pretty useful meta aliases.
 
First, let’s take a look at the built-in meta alias:
    1. In MUSHclient, hit Ctrl-Shift-9 to bring up the Aliases configuration.
    2. For this article, click the Tree View check box so we can easily group the aliases.
    3. Expand special_convenience_aliases
    4. Double-click on #alias {*} {*} to see what it does.
  1.  
Looks pretty messy, but really this is just building the XML for another alias, and then saving the new alias.  Once you have a sense of how this works, you have quite a bit of power at your fingertips to create clever new meta aliases.
 
Here we’ll walk through two use cases for meta aliases: a cycling attack meta alias, and a portal meta alias.
 

Cycling Attack Meta Alias

One day, this author noticed that he often manually cycled through several attack aliases whenever he wanted to inflict a certain type of damage (say, holy).  “Wouldn’t it be nice if I could just type ‘hol’ and have the client cast a different holy-damage spell each time?” he thought.  This is the purpose of the Cycling Attack meta alias.
 
Our end goal is to be able to do the following in the client:
> t1 kobold
> hol
cast 'holy strike' kobold
> hol
cast repentance kobold
> hol cast 'holy strike' kobold
 
Minor note: in this article, text that follows the “>” is supposed to be what you type at the prompt.  The lines above that don’t start with “>” are supposed to show what the client then sends to the server.
 
First, it’s important to understand the concept of a “target” variable.  This feeds into the attack aliases, so let’s start there.

Creating a Target alias/variable

It’s a common MUD pattern to create an alias like the following, which lets you quickly set a target mob’s name in a client variable (here called “target1”):
<aliases>   <alias    match="t1 *"    enabled="y"    variable="target1"    send_to="9"    sequence="100"   >   <send>%1</send>   </alias> </aliases>
You can add this to your own MUSHclient as follows:
    1. Hit Ctrl-Shift-9.
    2. Copy the above XML.
    3. Click the Paste button in the Aliases configuration screen.
  1.  
Now whenever you type something like “t1 kobold”, you’ll set a MUSHclient variable named “target1” to the value of “kobold”.  Then you can simplify all of your attack-related commands by referencing the @target1 variable like so:
 
<aliases>
  <alias
   match="unmagic"
   enabled="y"
   expand_variables="y"
   group="attack_aliases"
   send_to="10"
   sequence="100"
  >
  <send>cast 'dampening field' @target1</send>
  </alias>
</aliases>
 
Notice that using this alias, you only have to type “unmagic” and you’ll cast dampening field on your current target, instead of having to type the target’s name every time.
 
With this in mind, let’s return to the cycling attack alias idea.  We’ll start by creating a scripted Lua function that we can use later in our meta alias.

Creating a script that cycles through attacks

First, create a new file called cycle_commands.lua with this as its contents:
 
function cycle_attack (cmdvar, idxvar)
    if not GetVariable(idxvar) then
        SetVariable(idxvar, 0)
    end -- if
 
    idx = tonumber(GetVariable(idxvar))
 
    cmds = utils.split(GetVariable(cmdvar), ",")
    nextcmd = cmds[idx + 1]
    Send (nextcmd .. " " .. GetVariable ("target1") )
 
    SetVariable(idxvar, bit.mod(idx + 1, #cmds))
end -- function
 
Okay, what are we doing here?  The function makes use of two arguments:
  • A command variable (cmdvar).  This must contain a list of comma-separated commands that can be run by the client.  For example, it might contain “cast ‘holy strike’,cast repentance”.  Here, the idea would be to somehow cycle through those two attack commands.
  • An index variable (idxvar).  This is where an array index pointer is kept.  The functions start it off at 0 if it hasn’t been defined yet.
The cycle_commands function first gets the index variable and use it to get the appropriate value in the command variable list, and sends the command to the server, along with the @target1 variable.  It then increments the index (rolling back to zero if it’s reached the end of the list) and sets the index variable again.
 
To enable this script:
    1. Place this script file under your MUSHclient home folder, under the scripts directory.
    2. In MUSHclient, hit Ctrl-Shift-6 to bring up the Scripts configuration.
    3. In the External Script File section, select Browse, and select the cycle_commands.lua script.  Ensure “Enable scripting” is checked.
Now we can use the cycle_attacks function in our aliases.
 

Creating the meta attack alias

Next, let’s create the actual meta alias, which will let us quickly create attack aliases later.  Paste this in your Aliases configuration view:
 
<aliases>
  <alias
   match="#attackalias {*} {*}"
   enabled="y"
   group="special_convenience_aliases"
   send_to="12"
   ignore_case="y"
   sequence="100"
  >
  <send>require "addxml"  -- addxml extension
 
-- add the alias
 
addxml.alias {
  name = "command_line_alias_" .. string.gsub(Base64Encode("%1"), "=", ""),
  match = "%1",
  send = "cycle_attack ('%1cmds', '%1idx')",
  sequence = 100,
  enabled = true,
  send_to = 12,
  group = "attack_aliases"
             }
 
ColourNote ("white", "green", "Added alias to match on '%1' with '%2' attacks")
 
SetVariable ("%1cmds", "%2")
  </send>
  </alias>
</aliases>
 
Whew, what have we done here?  It’s probably easiest to just try it out in your prompt:
> #attackalias {hol} {cast 'holy strike',cast repentance}
 
This will do the following:
    1. Set a new variable called ‘holcmds’ to the value: cast ‘holy strike’,cast repentance
    2. Set a new variable called ‘holidx’ to the value: 0
    3. Define a new alias in the attack_aliases group called ‘hol’ that sends the following to a Script:
cycle_attack ("holcmds", "holidx")
 
Now in your client, once you’ve set your target (remember, t1 kobold), you can simply type this:
> hol
cast 'holy strike' kobold
> hol
cast repentance kobold
 

Portal Meta Alias

Now we turn to portals.  You may already have a “portal” alias defined that gets a portal from your bag, holds it, and enters, but let’s first create one here just as a sample:
 
<aliases>
  <alias
   match="portal *"
   enabled="y"
   group="portal_aliases"
   send_to="10"
   sequence="100"
  >
  <send>get %1 backpack
hold %1
enter
rem %1
put %1 backpack
dual @dual
remove invis
wear invis lfinger</send>
  </alias>
</aliases>
 
Say you type ‘portal mirror’.  This alias will do the following (feel free to edit as suits your gear):
    1. Gets the portal from the portal bag (a backpack, in my case)
    2. Holds the portal, enters it, removes it, puts it back in the bag.
    3. Dual wields a weapon whose name I’ve put in my @dual variable (a good practice, as well).
    4. Re-applies the ring of invisibility.
Obviously, much of this is optional, like the dual wield and invisibility ring, and you’ll want to use your actual portal bag name.
 
But, let’s go back to the meta concept: how can we easily create portal aliases, since we do it so often?  Paste the following meta alias in your client:
 
<aliases>
  <alias
   match="#portalalias {*} {*}"
   enabled="y"
   group="special_convenience_aliases"
   send_to="12"
   ignore_case="y"
   sequence="100"
  >
  <send>require "addxml"  -- addxml extension
 
-- add the alias
 
addxml.alias {
  name = "command_line_alias_" .. string.gsub(Base64Encode("%1"), "=", ""),
  match = "%1",
  send = "portal %2",
  sequence = 100,
  enabled = true,
  send_to = 10,
  group = "portal_aliases"
             }
 
ColourNote ("white", "green", "Added alias to match on '%1' with 'portal %2'")
  </send>
  </alias>
</aliases>
 
This makes use of our “portal *” alias.  Now you can do the following:
> #portalalias {preme} {mirror}
 
Which will create an alias called ‘reme’ that sends to the server: portal mirror
 
Once you’ve used your portal, you can additionally add it to the mapper:
> mapper portal preme
 

Disarming Triggers

Finally, let’s define some useful triggers related to getting disarmed.  These triggers use a @weap variable that lets you quickly rewield your primary weapon when disarmed.
 
First, let’s set up the alias that sets this variable:
 
<aliases>
  <alias
   match="setweap *"
   enabled="y"
   variable="weap"
   send_to="9"
   sequence="100"
  >
  <send>%1</send>
  </alias>
</aliases>
 
You can use this as follows:
> setweap sword
 
(You can do the same with the @dual variable from above, by the way.)
 
The folowing trigger, then, will detect when you’re disarmed but keep the weapon in your inventory:
 
<triggers>
  <trigger
   enabled="y"
   expand_variables="y"
   match="*DISARMS you and you struggle not to drop your weapon*"
   send_to="12"
   sequence="100"
  >
  <send>Note ("++++++++++++++++++++++++++++++++++++ You have been DISARMED! +++++++++++++++++++++++++++++++++++")
Send("wield @weap")</send>
  </trigger>
</triggers>
 
And this one triggers when your weapon goes flying:
<triggers>
  <trigger
   enabled="y"
   expand_variables="y"
   match="^.*DISARMS you and sends(.*?)$"
   regexp="y"
   send_to="12"
   sequence="100"
  >
  <send>Note ("++++++++++++++++++++++++++++++++++++ You have been DISARMED! ++++++++++++++++++++++++++++++++++++")
Send ("get @weap")
Send("wield @weap")</send>
  </trigger>
</triggers>

Now you shouldn’t worry, as long as you keep your @weap variable up to date.

Read more
No Comments