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

Match on colour not working

Posted by Itsmarkul on Thu 05 Sep 2024 11:29 AM — 10 posts, 16,436 views.

Itsmarkul #0
Hello, I am setting up a trigger that I only want to match on bold white instead of the standard default "white" (#C0C0C0).

I checked the line text attributes for the line I want to match on:

Text colour: R=255, G=255, B=255
RGB Colour
Text: #FFFFFF


However when I select white from the trigger "Match on" drop down, and select bold, it doesn't match.

I checked the line text attributes for the #C0C0C0 default colour, and that shows up named as white:

Text colour: White
RGB Colour
Text: #C0C0C0


It seems like mushclient isn't recognising #FFFFFF as Bold White. Is there any way I can force this? In ANSI Colours, Bold White is set as #FFFFFF.
Nick Gammon Australia Forum Administrator #1
Please copy and paste your exact trigger:

Template:copying
For advice on how to copy aliases, timers or triggers from within MUSHclient, and paste them into a forum message, please see Copying XML.


Also do a "packet debug" of a line you are trying to match on.

Go to the Edit menu, turn on Debug Packets, get the MUD to display the line in question, turn off Debug Packets or it will slow things down, and then copy/paste the packet into a reply.

Then I can simulate what you are doing and work out an answer for you.
Itsmarkul #2 
<triggers>
  <trigger
   bold="y"
   custom_colour="17"
   enabled="y"
   ignore_case="y"
   keep_evaluating="y"
   match="^(.+) (says|exclaims|asks|screams|shouts)(.+):"
   match_bold="y"
   match_inverse="y"
   match_italic="y"
   match_text_colour="y"
   regexp="y"
   repeat="y"
   sequence="100"
   text_colour="15"
   other_text_colour="cyan"
  >
  </trigger>
</triggers>


.[4z<White>The P   1b 5b 34 7a 3c 57 68 69 74 65 3e 54 68 65 20 50
rofessor of Reco   72 6f 66 65 73 73 6f 72 20 6f 66 20 52 65 63 6f
ndite Architectu   6e 64 69 74 65 20 41 72 63 68 69 74 65 63 74 75
re says in Morpo   72 65 20 73 61 79 73 20 69 6e 20 4d 6f 72 70 6f
rkian: Oh, I do    72 6b 69 61 6e 3a 20 4f 68 2c 20 49 20 64 6f 20
love the summer    6c 6f 76 65 20 74 68 65 20 73 75 6d 6d 65 72 20
weather.  You do   77 65 61 74 68 65 72 2e 20 20 59 6f 75 20 64 6f
n't get weather    6e 27 74 20 67 65 74 20 77 65 61 74 68 65 72 20
like this back i   6c 69 6b 65 20 74 68 69 73 20 62 61 63 6b 20 69
n dear old Bonk.   6e 20 64 65 61 72 20 6f 6c 64 20 42 6f 6e 6b 2e
.[3z.[4z<BR>       1b 5b 33 7a 1b 5b 34 7a 3c 42 52 3e



The match itself works for me if I don't specify a colour but as soon as I switch it to match "bold white" it doesn't.

I tested it with just matching "white" (and changing the output of the MUD to send the line in white vs bold white) and that worked. I believe it's just not recognising bold white as bold white.

I want to match on bold white because room tells are in bold white, but you can also receive private tells that sometimes match the same string and I have those coloured differently.
Amended on Fri 06 Sep 2024 04:46 PM by Itsmarkul
Nick Gammon Australia Forum Administrator #3
There is no ANSI code shown there to set that line to bold white.
Nick Gammon Australia Forum Administrator #4
I see that your MUD seems to be using <White> as an MXP tag to change colours, not ANSI codes.

As far as I can see in the MUSHclient code, <White> should not work. The MXP code for changing colours is "<color fore=cornsilk back=blue>".

http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=238

Since you say the line is actually appearing in bold white I'm curious how this is working. Do you have a plugin that interprets those tags?

Assuming you do, I think the problem here is that the MXP tag is switching the RGB codes to FFFFFF but not setting the bold flag (which would be <B> in MXP).

What you can do as a workaround is detect the colour of the first style run, in the trigger, and then choose whether or not to take action. However re-colouring the line is a little trickier, you basically have to omit it and then redraw with the new colours.

If we can find out how the <White> tag is actually working (it doesn't show as bold white for me when I test) then maybe that can be re-implemented in such a way that it converts <White> into the ANSI codes for bold white, and then your trigger should work.
Nick Gammon Australia Forum Administrator #5
You could try this plugin:

Template:saveplugin=Fixup_White_tag
To save and install the Fixup_White_tag plugin do this:
  1. Copy the code below (in the code box) to the Clipboard
  2. Open a text editor (such as Notepad) and paste the plugin code into it
  3. Save to disk on your PC, preferably in your plugins directory, as Fixup_White_tag.xml
    • The "plugins" directory is usually under the "worlds" directory inside where you installed MUSHclient.
  4. Go to the MUSHclient File menu -> Plugins
  5. Click "Add"
  6. Choose the file Fixup_White_tag.xml (which you just saved in step 3) as a plugin
  7. Click "Close"
  8. Save your world file, so that the plugin loads next time you open it. 



<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE muclient>

<muclient>
<plugin
   name="Fixup_White_tag"
   author="Nick Gammon"
   id="dcf5d6cdace6a70a00f2b162"
   language="Lua"
   purpose="Converts <White> tag to ANSI codes"
   date_written="2024-09-07"
   requires="4.00"
   version="1.0"
   sequence="1"
   >

</plugin>

<!--  Script  -->

<script>

function OnPluginPacketReceived (s)
  return (string.gsub (s, "&lt;White&gt;", "\027[37;1m"))
end -- function OnPluginPacketReceived

</script>

</muclient>


What that does is change the <White> tag to the ANSI codes for bold white, and when I tested it your trigger successfully matched the bold white line.
Itsmarkul #6
I don't have a plugin to interpret those colours, even without any plugins those lines appear as bold white.

I tried your plugin and it works, thank you! I'm still not sure how MUSHclient is interpretting <White> as white if that's not the correct MXP code...
Shadowfyr USA #7
Hmm. Just a thought Nick, but did you use something like an XML/HTML parser to build the MXP implementation? Because its my understanding that these are designed to be semi-sloppy in how they handle errors in code. Basically, the philosophy behind them, even if you don't personally intend this to happen, is, "Display/parse 'something', even if its broken, or wrong, so you at least get something." This is important for html, since it lets you see the content, even if something is broken, instead of just a blank page, and I think the parser for XML was built based on the html parser. So, basically, the parser is seeing "white", and going, "Well... is missing the 'color' keyword, but I know that 'white' is supposed to be a text color, so I should just do that anyway. Even if its wrong, it might also be right, or close enough.", exactly the same way that html would be parsed to do "something", not nothing.
Nick Gammon Australia Forum Administrator #8
Yeah, I understand. However when I tested his supplied test data it didn't appear in bold white, and the MXP error log showed that it didn't recognise that tag.

I admit I was using a slightly older version of MUSHclient but I don't recall making that sort of change recently. Maybe I did. :)
Shadowfyr USA #9
Huh.. Yeah, that is really odd then...