Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

Entire forum
MUSHclient
General
Triggers across lines

Home \| Users \| Search \| FAQ
Username:	Register forum user name
Password:	Forgotten password?

(New message)

Subject:	Triggers across lines
Name:	Your forum user name. Register forum user name
Password:	Your forum password. Forgotten password?
Message:	[quote=Shadowfyr] Ok.. Two things have occured to me that I think are major problems with a look-back method. 1) coloring lines and 2) omitting from output. Both of these are issues because while you use a buffer to do the look-back, the actual lines in the display are not necessarilly going to correspond to where they are in the output. This requires not only keeping track of where those lines are in the output. Ironically, it causes another odd problem. If a user types a command or a script generates a note when these lines are being displayed, then the trigger will correctly match and theoretically could color the right line, but the command, note or tell could cause a break in that line, which means it would see the right line, start to color it, then incorrectly color everything else posted to that line, though it is not actually part of the line that matched. This gets even more confusing if a) your are using the trigger to 'omit from output' or need to correctly retrieve the style information for the lines matched, since there is no practical way to know which line is really the start and if the line gets broken, the styles retrieved won't match, even though the actual contents for the line returned is correct inside the wildcard. Simply disabling these features for such triggers would more or less solve the problem, but begs the question of how useful they really are when you need to both use the data and color the information. In the case of the stat roller, where a clever person might use colourtell, colournote and 'omit from output' to not just have the mud reroll things, but show a colorized version of the results of each roll, to get a sense of the trend the rolls are taking. While this specific instance may not quite be that helpful, since it is automated, a mud which will never give optimal results may require a less automated system, but use the same trigger to provide such a visual comparison. Other similar things could be tracked 'in-game' (say space ports stats or the like in a space trading mud) where, as I mentioned, commands or displayed lines could royally muck up the function of such a trigger. Not that they don't unfortunately tend to sometimes do so on a small scale already, but this requires still another level of complexity to partially fix the problem. A complete fix would require some way to mark lines that get broken internally, so that the commands to return styles or other line info can find the part that got chopped off. Of course since triggers also fail to match lines that get broken that way... Anyway, it is another possible issue to consider. I am almost tempted to try to write a PCRE parser that does properly manage streamed text. The only real hang up is getting it to split on $ or \n, which is easy and deal properly with stuff like (^...$){1,10}. From a practical standpoint it means pre-parsing the regexp to break it into seperate triggers and adding logic so it knows when each one can be expected to find a match. Not exactly an impossibility, but it would admittedly take a bit of work. In the case of something like: ^You see\:$(.\n){1,}^$ it would simply need to create internal logic to do: [code]if Trigger "^You see\:" matched then call sub, etc. loop if match = "$(.\n)" then call sub, etc. until if match = "^$" then call subs, etc.[/code] If you used {1,10} and added ^Exits\: .$, then: [code]if Trigger "^You see\:" matched then call sub, etc. loop if match = "$(.\n)" then call sub, etc. until count = 10 or if match = "^$" then call subs, etc. if match = "^Exits\: .*$" then call sub, etc. reset trigger to first state.[/code] The only real issue is having the pre-parser figure out how the bits get seperated out. Would probably take me forever to get right though. :( I still think it is a better design and uses PCRE syntax correctly, while your design actually ignores the rules to provide a feature that is in theory already in the syntax. I'm not entirely sure all the extra stuff you are doing, like the look-back buffer isn't actually more complicated that a good pre-parser, for generating a set of rules like above, to guide the trigger behaviour. It may be easier to design, but more efficient or less complicated overall? Hard to say. Sometimes 'easy to design' is a synonim for bad idea. I'm just not a good enough programmer to tell the difference most times. I suspect that is true about most of us. On a side note: Interesting quirk with the above idea. If the pre-parser actually built vbscript, or javascript, etc. to handle it and used the scripts regexp parsing to handle the matching it would be even easier, no need to design a messy internal method to do the logic, just one to build the script. But that's not likely that practical and you never know what version of PCRE the available script engines will properly support, if actually any. Still, it is kind of an interesting idea. lol Never know where anything with Mushclient will take you. ;) [/quote] Message to be posted (in English, please).
Forum codes:	Check this if your message uses 'forum codes' or templates (auto-detected for new posts). Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Pages: 1 2 3 4

Posted by Nick Gammon Australia (18,769 posts) bio Forum Administrator

Date

Sat 05 Nov 2005 09:19 PM (UTC) [ quote ]

Amended on Sat 05 Nov 2005 09:21 PM (UTC) by Nick Gammon

Message

After a bit of recent testing I found the suggested trigger further up matches too often.

This seems to work better:


<triggers>
  <trigger
   enabled="y"
   lines_to_match="15"
   match="You are carrying:\n(([ ]{5}.*\n)*)\n(?![ ]{5})\z"
   multi_line="y"
   regexp="y"
   send_to="2"
   sequence="100"
  >
  <send>Found %0</send>
  </trigger>
</triggers>

There is an extra \n before the last bit, which forces it to assert that it gets a newline followed by *not* 5 spaces, to signal the end of the inventory.

Test data:



You are carrying:
     a magic mushroom
     a torch
     a dragonskin
     a bag
     recall scroll

Without the \n it matched on each line of inventory.

- Nick Gammon

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

top

Posted by

Nbe (5 posts)

bio

Date

Tue 06 Jul 2004 07:40 AM (UTC) [ quote ]

Message

thanks a lot

top

Posted by

Nick Gammon Australia (18,769 posts)

bio Forum Administrator

Date

Sat 03 Jul 2004 09:41 PM (UTC) [ quote ]

Message

Quote:

Release notes of 4.48 (which means youll need at least 4.48), ...

That's version 3.48. You'll wait quite a while for 4.48.

- Nick Gammon

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

top

Posted by

Flannel USA (1,230 posts)

bio

Date

Sat 03 Jul 2004 07:49 PM (UTC) [ quote ]

Amended on Sat 03 Jul 2004 10:26 PM (UTC) by Flannel

Message

Release notes of 3.48 (which means youll need at least 3.48), there are three methods, naming your wildcards, simply referencing them (much like the normal numbers) and then finally theres a script function to do it.

14. Added support for named wildcards in triggers or aliases. Inside regular expressions you can specify a named wildcard, like this:

Match: (?P<who>.*) tells you '(?P<what>.*)'

In this case we have 2 wildcards, named "who" and "what".

Then in the "send" box you can access named wildcards like this:

Send: %<who> just told you %<what>

15. Added support for up to 1000 wildcards in triggers and aliases (rather than 10). To access the additional ones you can use named wildcards as described above, the new script routines GetTriggerWildcard and GetAliasWildcard described below, or use this syntax in the "send" box:

Send: %<11> just told you %<12>

This example would return wildcards 11 and 12.

16. Added new script routines GetTriggerWildcard and GetAliasWildcard - these let you get a named or numbered wildcard from a trigger or alias.

eg.

x = GetTriggerWildcard ("mytrigger", "target") ' get named wildcard
x = GetTriggerWildcard ("mytrigger", "22") ' get wildcard 22

edit: changed the version to prevent future confusion, thank you Nick.

~Flannel

Messiah of Rose
Eternity's Trials.

Clones are people two.

top

Posted by

Nbe (5 posts)

bio

Date

Sat 03 Jul 2004 05:44 PM (UTC) [ quote ]

Message

Nick Gammon's way works good,then another problem:how can the script received these data(more than 10) ?

top

Posted by Nick Gammon Australia (18,769 posts) bio Forum Administrator

Date Mon 26 Apr 2004 09:12 PM (UTC) [ quote ]

Message

Yes you can do that. Basically a multi-line trigger is like an ordinary trigger regular expression except that it might have the \n character in it to match line breaks.

Like a normal regexp you can have optional parts, where that optional part might be a whole line.

Here is an example:



Match: ^You see Nick\n(He is carrying (?P<gold>\d+) gold\n)?He is looking sleepy\z

This matches both:


You see Nick
He is looking sleepy


... and ...

You see Nick
He is carrying 13 gold
He is looking sleepy

If it matches the second case (with the gold line) then the named wildcard %<gold> contains the amount of gold he has.

I set the number of lines to 3 to test this. This is a good example of how you cannot predict exactly how many lines to match, so you allow for the maximum number, in this case, 3.

- Nick Gammon

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

top

Posted by

Dubthach (47 posts)

bio

Date

Mon 26 Apr 2004 02:05 PM (UTC) [ quote ]

Message

I for one am excited about this feature. In the past, I never wrote triggers to record things like mob vulns or ID'd items because it is annoying to coordinate the various triggers.

I just hope this system can allow for sometimes having a line and sometimes not. i.e. sometimes a mob has a vulnerability and sometimes they do not.

top

Posted by

Nick Gammon Australia (18,769 posts)

bio Forum Administrator

Date

Mon 26 Apr 2004 02:37 AM (UTC) [ quote ]

Message

You can now play with multi-line triggers in version 3.48, which has just been released.

- Nick Gammon

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

top

Posted by

Nick Gammon Australia (18,769 posts)

bio Forum Administrator

Date

Sun 25 Apr 2004 07:23 AM (UTC) [ quote ]

Message

Quote:

a clever person might use colourtell, colournote and 'omit from output' to not just have the mud reroll things, but show a colorized version of the results of each roll, to get a sense of the trend the rolls are taking

I honestly don't think randomly-rolled stats will "show a trend".

- Nick Gammon

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

top

Posted by

Nick Gammon Australia (18,769 posts)

bio Forum Administrator

Date

Sat 24 Apr 2004 09:29 PM (UTC) [ quote ]

Message

Some parts of this thread are continued at RegExp VM.

- Nick Gammon

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

top

Posted by

Nick Gammon Australia (18,769 posts)

bio Forum Administrator

Date

Sat 24 Apr 2004 09:18 PM (UTC) [ quote ]

Message

Quote:

I am almost tempted to try to write a PCRE parser that does properly manage streamed text.

I'll comment on that in your new thread.

- Nick Gammon

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

top

Posted by

Nick Gammon Australia (18,769 posts)

bio Forum Administrator

Date

Sat 24 Apr 2004 09:18 PM (UTC) [ quote ]

Message

Quote:

Ok.. Two things have occured to me that I think are major problems with a look-back method. 1) coloring lines and 2) omitting from output.

I have now updated the release notes for version 3.48, and you can see from reading those that I have taken those problems into account (before reading what you said).

Clearly a multiple-line trigger cannot do all a single-line trigger can, for instance:

It cannot omit from output, for one thing the line(s) may be already omitted, for another it would be hard to work out which ones they were, for another there may be note or command lines inbetween.
It cannot colour lines, they may have been omitted, already coloured, other lines may intervene, and again it would be hard to say exactly which lines where to be coloured.
It cannot omit from log, the lines may already be logged with other lines after them.
It cannot match on colours or styles, again it would be hard to say exactly where those colours or styles were in the original buffer, and in any case the original lines may be have omitted by the time the trigger matched.

It was really intended to solve those problems where you may want to handle a "batch of lines" (the stat roller is quite a good example) without having to write lots of separate triggers and have "trigger states".

- Nick Gammon

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

top

Posted by Shadowfyr USA (1,774 posts) bio

Date Sat 24 Apr 2004 09:47 AM (UTC) [ quote ]

Message

Ok.. Two things have occured to me that I think are major problems with a look-back method. 1) coloring lines and 2) omitting from output.

Both of these are issues because while you use a buffer to do the look-back, the actual lines in the display are not necessarilly going to correspond to where they are in the output. This requires not only keeping track of where those lines are in the output. Ironically, it causes another odd problem. If a user types a command or a script generates a note when these lines are being displayed, then the trigger will correctly match and theoretically could color the right line, but the command, note or tell could cause a break in that line, which means it would see the right line, start to color it, then incorrectly color everything else posted to that line, though it is not actually part of the line that matched. This gets even more confusing if a) your are using the trigger to 'omit from output' or need to correctly retrieve the style information for the lines matched, since there is no practical way to know which line is really the start and if the line gets broken, the styles retrieved won't match, even though the actual contents for the line returned is correct inside the wildcard. Simply disabling these features for such triggers would more or less solve the problem, but begs the question of how useful they really are when you need to both use the data and color the information.

In the case of the stat roller, where a clever person might use colourtell, colournote and 'omit from output' to not just have the mud reroll things, but show a colorized version of the results of each roll, to get a sense of the trend the rolls are taking. While this specific instance may not quite be that helpful, since it is automated, a mud which will never give optimal results may require a less automated system, but use the same trigger to provide such a visual comparison. Other similar things could be tracked 'in-game' (say space ports stats or the like in a space trading mud) where, as I mentioned, commands or displayed lines could royally muck up the function of such a trigger. Not that they don't unfortunately tend to sometimes do so on a small scale already, but this requires still another level of complexity to partially fix the problem. A complete fix would require some way to mark lines that get broken internally, so that the commands to return styles or other line info can find the part that got chopped off. Of course since triggers also fail to match lines that get broken that way...

Anyway, it is another possible issue to consider.

I am almost tempted to try to write a PCRE parser that does properly manage streamed text. The only real hang up is getting it to split on $ or \n, which is easy and deal properly with stuff like (^...$){1,10}. From a practical standpoint it means pre-parsing the regexp to break it into seperate triggers and adding logic so it knows when each one can be expected to find a match. Not exactly an impossibility, but it would admittedly take a bit of work. In the case of something like:

^You see\:$(.*\n){1,}^$

it would simply need to create internal logic to do:

if Trigger "^You see\:" matched then
  call sub, etc.
  loop
    if match = "$(.*\n)" then
      call sub, etc.
  until if match = "^$" then
    call subs, etc.

If you used {1,10} and added ^Exits\: .*$, then:

if Trigger "^You see\:" matched then
  call sub, etc.
  loop
    if match = "$(.*\n)" then
      call sub, etc.
  until count = 10 or if match = "^$" then
    call subs, etc.
    if match = "^Exits\: .*$" then
      call sub, etc.
      reset trigger to first state.

The only real issue is having the pre-parser figure out how the bits get seperated out. Would probably take me forever to get right though. :( I still think it is a better design and uses PCRE syntax correctly, while your design actually ignores the rules to provide a feature that is in theory already in the syntax. I'm not entirely sure all the extra stuff you are doing, like the look-back buffer isn't actually more complicated that a good pre-parser, for generating a set of rules like above, to guide the trigger behaviour. It may be easier to design, but more efficient or less complicated overall? Hard to say. Sometimes 'easy to design' is a synonim for bad idea. I'm just not a good enough programmer to tell the difference most times. I suspect that is true about most of us.

On a side note: Interesting quirk with the above idea. If the pre-parser actually built vbscript, or javascript, etc. to handle it and used the scripts regexp parsing to handle the matching it would be even easier, no need to design a messy internal method to do the logic, just one to build the script. But that's not likely that practical and you never know what version of PCRE the available script engines will properly support, if actually any. Still, it is kind of an interesting idea. lol Never know where anything with Mushclient will take you. ;)

main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}

top

Posted by Nick Gammon Australia (18,769 posts) bio Forum Administrator

Date

Sat 24 Apr 2004 07:32 AM (UTC) [ quote ]

Amended on Sat 24 Apr 2004 07:35 AM (UTC) by Nick Gammon

Message

Here is another example of a simplified trigger (if you can call it that, *cough* *cough*). At least it uses one trigger to do a stat roller rather than about 8 of them.

This illustrates a few things:

Multi-line trigger
10 wildcards matching (normally MUSHclient matches 9 wildcards plus an extra for "the matching line")
Named wildcards to simplify the end-processing

Expected output:


Rerolling please wait.
-====================== CHARACTER ATTRIBUTES SELECTION ======================-
            Strength (ST): 30( 77)   Constitution   (CO): 33( 53)
            Quickness(QU): 40( 40)   Agility        (AG): 52( 52)
            Presence (PR): 24( 84)   Self-Discipline(SD): 29( 39)
            Empathy  (EM): 20( 68)   Memory         (ME): 40( 40)
            Intuition(IN): 26( 47)   Reasoning      (RE): 29( 39)

Trigger match:



Rerolling please wait\.\n-=* CHARACTER ATTRIBUTES SELECTION =*-\n\s+Strength \(ST\):\s+(?P<st>\d+)\( \d+\)\s+Constitution\s+\(CO\): (?P<co>\d+)\( \d+\)\n\s+Quickness\(QU\): (?P<qu>\d+)\( \d+\)\s+Agility        \(AG\): (?P<ag>\d+)\( \d+\)\n\s+Presence \(PR\): (?P<pr>\d+)\( \d+\)\s+Self-Discipline\(SD\): (?P<sd>\d+)\( \d+\)\n\s+Empathy  \(EM\): (?P<em>\d+)\( \d+\)\s+Memory\s+\(ME\): (?P<me>\d+)\( \d+\)\n\s+Intuition\(IN\): (?P<in>\d+)\( \d+\)\s+Reasoning\s+\(RE\): (?P<re>\d+)\( \d+\)

Example of extracting the data (send box) using named wildcards:



strength = %<st>

quickness = %<qu>

presence = %<pr>

empathy = %<em>

intuition = %<in>

constitution = %<co>

agility = %<ag>

self-discipline = %<sd>

memory = %<me>

reasoning = %<re>

Results:



strength = 30

quickness = 40

presence = 24

empathy = 20

intuition = 26

constitution = 33

agility = 52

self-discipline = 29

memory = 40

reasoning = 29

Time to match: 0.000171 seconds.

- Nick Gammon

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

top

Posted by

Demonsurfer USA (256 posts)

bio

Date

Sat 24 Apr 2004 04:52 AM (UTC) [ quote ]

Message

I've tried tackling multiline triggers myself in the past without much success. The problem I found personally is that different situations have required different solutions, so while one method worked great in one situation, it failed dismally in another. The hardest thing was finding something that covered ANY multiline-type of triggering response, and unfortunately I never found a solution that was 100% fool proof that covered the multitude of differing possible scenarios.

If a trigger could fire using \n somehow.. but no.

I tried using world.getcommandlist on another occasion (for a kind of related situation) that sort of worked, but if I sent any commands in between (whether sent manually or by an unrelated trigger) I ended up doing something entirely undesired. It was amusing for a while anyway.. kinda like playing Russian Roulette ..hehe

Another method I tried that was extremely basic was having a first trigger (firing on the first line) that did 2 things: it enabled a 2nd trigger (that fired on the second line of the multiline trigger required obviously) and also called a script that had a short delay using world.DoAfterSpecial that disabled the 2nd trigger if it had not disabled itself by firing before that time period expired (and this could obviously be a chain of triggers). That actually did work in the right situation, but somehow seemed too easy to be a good solution, and again, this probably would not cover all situations.

My final solution was to just not worry about multiline triggers, and that has worked very well :)

As to the options in this thread so far, I think each has merit but I'm not knowledgable enough to give a definitive and qualified opinion one way or the other. :/

*sits on the fence and raises an eyebrow*

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.

12,712 views.

This is page 1, subject is 4 pages long: 1 2 3 4

Reply to this subject Start a new subject Refresh page

Go to topic: Search the forum

top

Comments to: Gammon Software support
Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )