Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUSHclient ➜ General ➜ Referencing a variable Via a trigger

Referencing a variable Via a trigger

It is now over 60 days since the last post. This thread is closed.     Refresh page


Posted by C   (10 posts)  Bio
Date Sun 28 Apr 2002 11:32 AM (UTC)

Amended on Sun 28 Apr 2002 05:07 PM (UTC) by C

Message
Hey all,

I was trying to reference an existing variable via a trigger but I can't seem to get it working. Basically what I want to do is set something like:

Variable target = Jim leaves west.
Trigger = $target leaves west.

I'm just not sure of the syntax of this. (ie how to get Mushclient to recognise the variable in the Trigger )

Anyone out there that can help me? :)

[Edit]

I also want to reference a variable in some of my Trigger actions, like:

Jim leaves west
Trigger: Jim leaves west
Action: west, kill $target

Help would be much appreciated :P

[/Edit]

C
Top

Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #1 on Sun 28 Apr 2002 08:01 PM (UTC)
Message
Nick,

Is it possible to use "send to: Variable" [Label: Target] in a trigger, and in the SAME trigger, use something like: "kill %Target"?

...Or would you need a second trigger, ranked to trip after the former (with keep evaluating on the former), that would do the task?

I just realized, this is a bit of a stupid question, as you could just send "kill %1" (or whatever wildcard)... but i think I'll ask it anyway...

Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #2 on Sun 28 Apr 2002 10:20 PM (UTC)

Amended on Sun 28 Apr 2002 10:27 PM (UTC) by Nick Gammon

Message
Quote:

Variable target = Jim leaves west.
Trigger = $target leaves west.


You can use "@" in front of the name, see the help file. You need to check "expand variables".

In this case the variable "target" would need to contain "Jim", which you could do, either through the configuration screens, or if scripting is enabled, by typing:


/world.setvariable "target", "Jim"


Then the trigger should read:


west; kill @target


However if you were asking about how to set "target" in a trigger, then you could do this:


Trigger: * leaves west
Send: %1
Send to: Variable (label is name)
Label: target


This would detect anyone leaving west and set the trigger "target" to their name.

You can be a bit more ambitious and handle the other directions too, with a regular expression, like this:


Trigger: ^(.*?) leaves (north|south|east|west|up|down)$
Send: %1
Send to: Variable (label is name)
Regular expression: checked
Label: target





The problem with the above is that you can only set one variable in a trigger without scripting. Thus you wouldn't be able to remember the direction. However a small script would ...

Trigger


Trigger: ^(.*?) leaves (north|south|east|west|up|down)$
Regular expression: checked
Label: OnLeaving
Script: OnLeaving



Script


sub OnLeaving (sName, sLine, Wildcards)
'
' first remember wildcards 1 and 2 in variables
'
  world.setvariable "target", Wildcards (1)
  world.setvariable "direction", Wildcards (2)
'
' we may as well follow them and kill them right now
'
  world.send Wildcards (2)  ' follow them (eg. east)
  world.send "kill " & Wildcards (1)  ' kill them
end sub





An alternative is to do two triggers, like this:

Trigger 1


Trigger: ^(.*?) leaves (north|south|east|west|up|down)$
Send: %1
Send to: Variable (label is name)
Regular expression: checked
Keep evaluating: checked
Label: target


Trigger 2


Trigger: ^.*? leaves (north|south|east|west|up|down)$
Send: %1
Send to: Variable (label is name)
Regular expression: checked
Keep evaluating: checked
Label: direction


The second trigger now has wildcard 1 as the direction (by removing the brackets around the name part. By checking "keep evaluating" both triggers are matched.




However you can also achieve the same effect anyway without variables at all, like this:


Trigger: ^(.*?) leaves (north|south|east|west|up|down)$
Send: %2; kill %1
Regular expression: checked

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #3 on Sun 28 Apr 2002 10:22 PM (UTC)
Message
Quote:

Is it possible to use "send to: Variable" [Label: Target] in a trigger, and in the SAME trigger, use something like: "kill %Target"?


No, to do that you would need a script, although your second idea would work, of course.

I am planning to remove the restriction on multiple triggers matching the same thing, so in version 3.18 onwards you could make two triggers that would achieve the same effect, as you describe.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #4 on Mon 29 Apr 2002 06:47 AM (UTC)
Message
Quote:

I am planning to remove the restriction on multiple triggers matching the same thing, so in version 3.18 onwards you could make two triggers that would achieve the same effect, as you describe.

If I understand what you are proposing, I think it may be a poor decision:

Currently, a line is received from the mud, then is processed to look for matching triggers. I would image, the more triggers there are, the more processing must be done.

Currently, when a trigger is matched, related script/etc is executed, then the flag to "keep evaluating" triggers is check, and if enabled, the trigger matching process continues. If not, 'attention' is turned to the next received line.

Now personally, among my 171 triggers, I have maybe just one or two that have "keep evaluating" checked. I don't want the entire trigger list processed every time a line from the mud comes in. I have to expect that would only slow down my client!

Indeed, if anything, I would hope that triggers are auto-sorted on occasion by their number of 'hits' (after their forced "sequence"), and that the ones with the most hits are checked first, thus making trigger processing as efficient as possible. Among my 171 triggers, all have the same sequence...

Hmm, If you aren't doing this, maybe I should write a script to get all triggers, sort them by number of hits, then re-save them with appropriate 'sequence' numbers. :)

If you disabled the "keep evaluating" flag, I could see it actually reducing efficiency enough that it may keep people with slow computers from upgrading. (And muds are the perfect game for people with slow computers). A bit drastic, yes... but you should get my point. :)

Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
Top

Posted by C   (10 posts)  Bio
Date Reply #5 on Mon 29 Apr 2002 01:19 PM (UTC)
Message
Thanks for the quick response. That's pretty close to what I want to do. I altered the script slightly, but I can't seem to get it to trigger.

The variable target already exists, so I want the trigger to be:

^@target leaves (north|south|east|west|up|down)\.$

Regular expression and Expand Variables are checked. The script looks like:

sub OnLeaving (sName, sLine, Wildcards)

world.setvariable "direction", Wildcards (1)

TargetName = world.GetVariable ("target")

world.send Wildcards (1)
world.send "kill " + TargetName

end sub

The line I'm trying to match (assuming the variable target is set to Luke) looks like:

Luke leaves north.

Or whatever direction. I've tried fiddling around with the trigger a bit but I can't seem to get it to work :( I'm pretty new to the scripting thing so it's probably something really simple that I missed :P

Thanks.
Top

Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #6 on Mon 29 Apr 2002 04:41 PM (UTC)

Amended on Mon 29 Apr 2002 04:42 PM (UTC) by Shadowfyr

Message
>^@target leaves (north|south|east|west|up|down)\.$

Hmm. Someone else that thinks this is a good idea. lol At the moment setting the variable 'within' the trigger match is not supported. Though I have tried to fight hard for it. ;)

>I am planning to remove the restriction on multiple triggers
>matching the same thing, so in version 3.18 onwards you
>could make two triggers that would achieve the same effect,
>as you describe.

I absolutely agree with magnum on this. But not just for this reason. As it is I can do the following:

Trigger: Magnum tells you: *
Sequence: 50
Custom Color: 2
Script: DoSomething

Trigger: * tells you: *
Sequence: 100
Custom Color: 1

and expect it to 'only' match the first one instead of doing both. If I want it to do both I can simply use 'Keep Evaluating' and have it work the way you propose. Being someone with an insane number of color triggers I am reasonably sure I have at least 1-2 that would work in an entirely inappropriate fashion if multi-match became the standard behaviour. Why you would need this when there is already an option to allow it I am uncertain of. And unlike Magnum I am far more concerned with messing up existing behaviour than possibly slowing things down.

In fact I have the following triggers (as a joke, though some people borrowed it for a while to create real shopping lists):

Trigger: *[BS] * tells you: list
Send: bs 'oy, that don work. Try 'tell' yah blighter.

Trigger: *[GOSSIP] * tells you: list
Send: gossip 'oy, that don work. Try 'tell' yah blighter.

Trigger: ([^ ]*) tells you: list$
Send: to tell %1
Moshimoshi, here you are then:

id|                     name               |  cost
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 1|                           A floppy hat |      10
 2|  A Spotter's Guide to Invisible Things |     300
 3|                            Charm stone |     500
 4|                           Cricket cage |     100
 5|                   Assassin in a Bottle |  500000
 6|        (Discontinued) Bard in a Bottle |       0
 7|                    Blaster in a Bottle |  500000
 8|                     Cleric in a Bottle |  500000
 9|                     Healer in a Bottle |  500000
10|                       Tank in a Bottle |  500000
11|                      Thief in a Bottle |  500000
12|                            Pocket lint | 5000000
.

Obviously I don't want to have one of the first two tell them one thing, then have the third send garbage to the mud, because it kept matching more triggers. I may have others, but at least this time it isn't 'hypothetical'. ;) lol
Top

Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #7 on Mon 29 Apr 2002 06:15 PM (UTC)
Message
Ya... I was thinking about it some more this morning as my computer was booting up... and I realized there are far, far more lines that pass by without setting off a trigger then lines that do... So optomizing trigger processing in the manner I suggested is probably not worth the trouble.

(All those lines that don't set off a trigger had to run through the entire trigger list looking for matches before they were sent to the output screen).

You make a good point, Shadowfyr. :) ...P.S., sorry for my comments in the other thread. Sometimes it seems to me that you are going on a far off tangent, but I -do- see value in that. :)

Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
Top

Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #8 on Mon 29 Apr 2002 06:33 PM (UTC)
Message
C,

You can't use a variable as part of a trigger line.

Here's what you want:

Trigger: ^(.*?) leaves (north|south|east|west|up|down)$
Regular expression: checked
Label: OnLeaving
Script: OnLeaving

Sub OnLeaving (sName, sLine, Wildcards)
  If Wildcards(1) = World.GetVariable("Target") Then
    World.Send Wildcards(2)
    World.Send "kill " & World.GetVariable("Target")
  End If
End Sub

Now, the trigger above will match on anyone leaving in one of the directions... then it calls the script.

The script checks to see if the character who moved (stored in wildcards(1)) is the one you are looking for (stored in the MushClient variable "Target"). If they match up, then the script moves you (by sending Wildcard(2) - the direction), then sends "kill " and the target name. If they don't match, nothing happens.

This trigger and script doesn't SET the value for "Target". You would do that seperately... perhaps with an alias:

alias: target *
enabled: Checked
label: Set_Target
Script: Set_Target

Sub Set_Target (sName, sLine, Wildcards)
  World.SetVariable "Target", Wildcards(1)
End Sub

Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #9 on Mon 29 Apr 2002 10:23 PM (UTC)
Message
Quote:

Currently, when a trigger is matched, related script/etc is executed, then the flag to "keep evaluating" triggers is check, and if enabled, the trigger matching process continues. If not, 'attention' is turned to the next received line.

Now personally, among my 171 triggers, I have maybe just one or two that have "keep evaluating" checked. I don't want the entire trigger list processed every time a line from the mud comes in. I have to expect that would only slow down my client!


I never said I was changing the behaviour of "keep evaluating" - I think you both read something into that, that isn't there. :)

With the change, now in 3.18, your existing triggers will work exactly the same. In the same time. :)

What it *will* do is allow, if you choose to do it, something like this to set two variables:



Trigger 1

Trigger: * leaves *
Send: %1
Send to: Variable (label is name)
Keep evaluating: checked
Label: target

Trigger 2

Trigger: * leaves *
Send: %2
Send to: Variable (label is name)
Keep evaluating: checked
Label: destination



Currently MUSHclient will object you are adding two identical triggers. The above technique lets you set multiple variables without scripting. You might have a third trigger that follows the person going east/west, or whatever.

You can presently do the same thing with scripts, but some players are averse to using them, so I wanted to have a simple alternative.

Quote:

Now personally, among my 171 triggers, I have maybe just one or two that have "keep evaluating" checked. I don't want the entire trigger list processed every time a line from the mud comes in. I have to expect that would only slow down my client!


It won't unless you choose to check "keep evaluating" for your existing triggers.

As for timing issues, I am very aware of the need for things to run quickly, and - as you know - I advertise MUSHclient as the fastest client available (for Windows). I recently rebenchmarked against a couple of other well-known clients and it still comes out ahead, on various tests, including scripting and trigger matching.

Looking at my newer benchmarks page, you can see that on the test file of 5,378 lines, attempting to match 10 triggers per line (which don't match) it is evaluating 53,780 triggers in 0.6 seconds, which is roughly 89,633 triggers per second. Therefore your 171 triggers will be evaluated (if they all were tested) in 1/524 of a second, which isn't too bad. As it is, since on average it might test half of them, trigger evaluation would be taking about a thousandth of a second, per line.

You can confirm these figures by opening the Info window (Shift+Ctrl+I) and looking at total trigger evaluation time.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #10 on Mon 29 Apr 2002 10:27 PM (UTC)
Message
Quote:

^@target leaves (north|south|east|west|up|down)\.$


As Magnum quite correctly pointed out, variable expansion happens in the reply, not the trigger test. I was (and am) reluctant to support that, as the regular expressions (in fact, all triggers) are "precompiled" when they are changed, for speed. Then the compiled trigger is applied to the incoming line (for speed reasons).

To allow variable substitution in the matching expression would require a recompile, either every line, or when the change is made, which would slow things down one way or another.

Another possible solution to the one Magnum proposed, would be that, when the target is changed, the script adds a new trigger itself (using addtrigger) that has the target name in it.

eg.

deletetrigger <-- delete old trigger
addtrigger <-- add new trigger with new target

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #11 on Tue 30 Apr 2002 02:18 AM (UTC)
Message
Ah... I see now. Your previous statement was a little vague which is why it set off alarms for us. ;)

An idea.. It may be slower to make triggers support inline variables, but it is clearer. One option would be like with EvaluateSpeedwalk. Let the user build a trigger using inlined variables, but automatically split it into multiple triggers when they hit OK. Then you can quickly build something that you know will work, but have the client generate the needed triggers to simulate what you intended. (Or even do that internally and invisible to the user.) It wouldn't be perfect, but it would make things slightly less confusing for people used to clients that do allow it.

To Magnum -> Not a problem. :) I try to be as clear as I can, but sometimes I am prone to wander a bit when trying to get a point across. Most of the time it is a simple case of I should have started a new thread or I am not entirely certain how to best describe the percieved problem. ;)

Also, when you get two or more smart people talking about something, sometimes they may as well be speaking entirely different languages. lol You sometimes have to regroup and hit things from another direction in those cases. ;)
Top

Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #12 on Wed 01 May 2002 06:20 AM (UTC)
Message
Quote:

It may be slower to make triggers support inline variables, but it is clearer.


I decided to support that. If it is slightly slower then that is your problem, and for a small number of triggers it probably would not be measurable.

Version 3.18 will now support variables in the trigger match text, eg.


Match on: @target leaves @direction

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

Posted by Magnum   Canada  (580 posts)  Bio
Date Reply #13 on Thu 02 May 2002 08:18 PM (UTC)
Message
Should be handy. Cool!

Get my plugins here: http://www.magnumsworld.com/muds/

Constantly proving I don't know what I am doing...
Magnum.
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.


27,713 views.

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum


[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.