This forum is a read-only archive of the Gammon Software forum (2000–2026). No new posts can be made. Search the archive.

Triggers on keep evaluating lines using specific match colours do not fire

Posted by Cino on Thu 16 Mar 2006 11:48 PM — 5 posts, 20,638 views.

Cino Australia #0
Am using MUSHclient v3.73.

There are certain lines which I trigger completely, and sometimes colour.

Using subsequent triggers I would like to colour certain phrases, and perform further actions from some of these lines.

I use the match colours to ensure they do not trigger when someone just repeats some output over a chat channel or the particular phrase just happens to turn up elsewhere.

These events are the only times I receive output in this particular colour (bold black). This is set up mud-side.

The problem is, the subsequent triggers do not fire (even with appropriate keep evaluating flags set) unless the match colour and styles are non-specific (i.e. [any]).


Example,
The gullible pickpocket thrusts at you with his dagger but you dodge out of the way.

This line arrives in bold black,
<triggers>
  <trigger
   back_colour="8"
   bold="y"
   custom_colour="5"
   enabled="y"
   keep_evaluating="y"
   match="^The gullible pickpocket thrusts at you with his dagger but you dodge out of the way\.$"
   match_back_colour="y"
   match_bold="y"
   match_inverse="y"
   match_italic="y"
   match_text_colour="y"
   regexp="y"
   sequence="2"
   text_colour="8"
  >
  </trigger>
</triggers>

and this trigger matches perfectly.

Now when using subsequent triggers through the keep evaluating flag, they don't seem to know about the style of the original line.

This triggers and re-colours the match correctly,
<triggers>
  <trigger
   custom_colour="8"
   enabled="y"
   match="but you dodge"
   regexp="y"
   sequence="6"
  >
  </trigger>
</triggers>


But, when the match colours are changed to meet the original output (the same as the previous whole line trigger), it does not fire.
<triggers>
  <trigger
   back_colour="8"
   bold="y"
   custom_colour="8"
   enabled="y"
   match="but you dodge"
   match_back_colour="y"
   match_bold="y"
   match_inverse="y"
   match_italic="y"
   match_text_colour="y"
   regexp="y"
   sequence="6"
   text_colour="8"
  >
  </trigger>
</triggers>



Also, I have noticed that the match_/[bold|inverse|italic/]="y" appears whenever the check box is ticked or unticked, but not when 'grey ticked'.

I thought, when 'grey ticked' it would match either, ticked would be only, and unticked would be never. But on my screen for the two triggers with specific match colours, the bold box is ticked, while the inverse and italic are not. But when looking at the copied trigger code, they appear to be active?


For now, unspecifying the colours and making use of EnableTrigger would work...


And how about taking suggestion #92 http://www.gammon.com.au/scripts/showbug.php?bugid=92&productid=0&searchfor= a step further and allowing to match on any MXP colour? Much like the 'Other...' option under 'Change colour and style'.
Nick Gammon Australia Forum Administrator #1
Quote:

I thought, when 'grey ticked' it would match either, ticked would be only, and unticked would be never. But on my screen for the two triggers with specific match colours, the bold box is ticked, while the inverse and italic are not. But when looking at the copied trigger code, they appear to be active?


Let's look at this first.

The three conditions, with their corresponding entries in the trigger XML code are:

  1. Don't care (grey):


    bold="n"
    match_bold="n"


    Actually they don't appear when you copy the trigger because false booleans are not copied (false is the default).

    However what this means is that bold (and italic and underline as the case may be) are not checked.
  2. Match bold (black tick):


    bold="y"
    match_bold="y"


    This means we are matching on the bold characteristic, and the match must be for bold enabled.
  3. Match not bold (unticked):


    bold="n"
    match_bold="y"


    This means we are matching on the bold characteristic, and the match must be for bold NOT enabled.


This seems to be working as designed.


Nick Gammon Australia Forum Administrator #2
Quote:

Now when using subsequent triggers through the keep evaluating flag, they don't seem to know about the style of the original line.


This is a known issue:

http://www.gammon.com.au/scripts/showbug.php?bugid=494&productid=0

Effectively MUSHclient has changed the colour of the style run on the original match, and thus subsequent matches do not match the modified colour.

There are a couple of workarounds you could use here:

  • If possible, do a non-colouring match first. In your case the phrase "but you dodge" which is inside the other sentence, could be done first, as this will not change the *first* character of the other trigger, which is the one which is tested.
  • If you need to do multiple tests on a certain colour line, first trigger the general line (eg. bold black) and then do further tests using regexps inside a script that the trigger calls, rather than using multiple triggers.


I am a bit reluctant to remember the original colours, this issue hasn't come up much, and to do so effectively adds quite a few bytes to each style run, for every line, for the occasional case where someone may have this problem. This is because you would need to remember the original foreground, background, and style bits for every style run.

There may be other ways of doing it which would not add a huge memory overhead, but perhaps if my suggestions work, that would be acceptable. :)

Nick Gammon Australia Forum Administrator #3
Quote:

Quoting myself :)

In your case the phrase "but you dodge" which is inside the other sentence, could be done first, as this will not change the *first* character of the other trigger, which is the one which is tested.


Your problem here would be that the "but you dodge" colouring would be overwritten by the second trigger. How about working with the system? If the line colour might be changed, match on "but you dodge" in the new colour (the one the other trigger applied)?
Nick Gammon Australia Forum Administrator #4
Quote:

And how about taking suggestion #92 a step further and allowing to match on any MXP colour? Much like the 'Other...' option under 'Change colour and style'.


Yes, I suppose. Alternatively, match on the text part, call a script, and the script can do complex tests on the style runs (available to it in Lua in particular). That way you can match on word A in red followed by word B in blue, and so on.