Unaltered style run passed through trigger?

Posted by Zimmy on Sun 22 Mar 2020 08:21 PM — 13 posts, 44,795 views.

Zimmy Sun 22 Mar 2020 08:21 PM #0

I would like to be able to get the style-table sent from the mud on a trigger match. The problem is that, the styles-table that is normally passed through a trigger is altered by other triggers and plugins (with color-changing triggers.) I have tried dropping the trigger-priority to zero, but I still only receive the styles after they have been altered client-side, for output.

I thought maybe that the colors sent from the mud we're considered mxp variables? But mxp related callbacks did not reveal any embedded colors.

The only other thing I could think of was using OnPluginPacketReceived to parse the packet directly, instead of using triggers. I would rather not do this if there is another option.

Here is an example of part of a packet:


pkt = [[with almost no wind and medium cloud cover.[4z<BR>[3z[4z<Green>There are three obvious exits: [4z<Exit>west[4z</Exit>, [4z<Exit>northeast[4z</Exit> and [4z<Exit>southeast[4z</Exit>.[3z[4z<BR>A depressed sailor is swaggering around, [4z<C #ff8700>Player 1[3z, [4z<C #ff8700>Player 2[3z, [4z<C #ff00d7>[4z<C #ff8700>Player 3[3z and [4z<C #ff00d7>[4z<C #ff8700>Player 4[3z are standing here and a black cloud is floating in the air here.[3z[4z<BR>]]

Fiendish USA Global Moderator Sun 22 Mar 2020 11:00 PM #1

If you put it into a plugin you can get earlier priority by setting the plugin priority to a negative number (down to -10000). But why do you need to get the original colors if they're being changed?

Zimmy Sun 22 Mar 2020 11:16 PM #2

Fiendish said:

If you put it into a plugin you can get earlier priority by setting the plugin priority to a negative number (down to -10000). But why do you need to get the original colors if they're being changed?

My goal is to be able to pick player names out of a trigger match. The mud only color-codes player names and not npcs/mobs. I wanted to use this fact to determine players. However, there are several plugins/triggers that color npc/mob names. If these color-changes were included in the style-table, then it would ruin the process of elimination.

Nick Gammon Australia Forum Administrator Mon 23 Mar 2020 08:44 AM #3

Trigger style runs are not, in fact, altered by other triggers.

Zimmy Mon 23 Mar 2020 05:32 PM #4

I set the sequence of my plugin lower than the others. But the color-changes from the other plugin still reflect in the style-run. Are you saying this is not expected behavior?

Fiendish USA Global Moderator Mon 23 Mar 2020 08:20 PM #5

Quote:
Trigger style runs are not, in fact, altered by other triggers.

They could be if a preceding trigger omits from output, stops further processing, and then uses Simulate to replace the original.

I do this in the Aardwolf package, because the only two options when replacing output text are either 1) the lay user has to magically know about something that they never see in order to trigger on it, 2) the lay user gets to trigger on what they see even though that's not what the server sent them.

Zimmy Mon 23 Mar 2020 09:44 PM #6

Fiendish said:

They could be if a preceding trigger omits from output, stops further processing, and then uses Simulate to replace the original.

That isn't what's happening here though.

Plugin 1 has a trigger that displays the style run of what it matches. It is set to a lower sequence than plugin 2.

Plugin 2 has triggers that colour certain words, I edited it to also send a print message when it matches (so I can see what order things are happening in.)

What ends up happening is (in this order):

When the trigger in plugin 1 fires, it displays the style-run from the match BUT, it includes the colour-changes from plugin 2.

AFTER that, plugin 2 prints messages on match.

So even though plugin 1 has priority, the colour-changes are still altering the style-run.

Nick Gammon Australia Forum Administrator Tue 24 Mar 2020 05:20 AM #7

See How MUSHclient processes text arriving from the MUD

I had forgotten about the trigger colouring.

You may have a timing issue. It would help to actually show a Minimal, Complete, Reproducible Example.

In other words, make up two plugins that actually demonstrate this (in as minimal way as you can) so we can see exactly what you are doing.

As an example, using script files, rather than “send to script” does things in a different order.

So even though plugin 1 has priority, the colour-changes are still altering the style-run.

Sounds like what I described. Also, the way you are displaying messages might also affect the timing (of when the messages appear).

Zimmy Tue 24 Mar 2020 06:10 AM #8

Nick Gammon said:

See [How MUSHclient processes text arriving from the MUD](http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=6554)

I had forgotten about the trigger colouring.

You may have a timing issue. It would help to actually show a [Minimal, Complete, Reproducible Example](https://stackoverflow.com/help/minimal-reproducible-example).

In other words, make up two plugins that actually demonstrate this (in as minimal way as you can) so we can see exactly what you are doing.

As an example, using script files, rather than "send to script" does things in a different order.

> So even though plugin 1 has priority, the colour-changes are still altering the style-run.

Sounds like what I described. Also, the way you are displaying messages might also affect the timing (of when the messages appear).

Plugin 1:


<muclient>
<plugin
   name="Plugin_1"
   author="Yurt"
   id="b8231bdc89af8f0bb0a62b23"
   language="Lua"
   purpose="testing how priority effect colour runs 1"
   date_written="2020-03-24 01:45:00"
   requires="1.00"
   version="1"
   sequence="-1000">
</plugin>
<script>
<![CDATA[
require "tprint"
function on_trigger_word_line(name, line, wildcards, styles)
    print("plugin 1")
    tprint(styles)
end
]]>
</script>
<triggers>
  <trigger
   enabled="y"
   ignore_case="y"
   keep_evaluating="y"
   match="^.*word.*$"
   regexp="y"
   sequence="100"
   name="word_line"
   script="on_trigger_word_line"
  >
  </trigger>
</triggers>
</muclient>

Plugin 2:


<muclient>
<plugin
   name="Plugin_2"
   author="Yurt"
   id="b8241bdc89bf8f0bb0a62b33"
   language="Lua"
   purpose="testing how priority effect colour runs 2"
   date_written="2020-03-24 01:45:00"
   requires="1.00"
   version="1">
</plugin>
<script>
<![CDATA[
function on_trigger_colour_word(name, line, wildcards, styles)
    print("plugin 2")
end
]]>
</script>
<triggers>
  <trigger
   custom_colour="17"
   enabled="y"
   ignore_case="y"
   keep_evaluating="y"
   match="word"
   regexp="y"
   repeat="y"
   sequence="100"
   other_text_colour="red"
   name="colour_word"
   script="on_trigger_colour_word">
  </trigger>
</triggers>
</muclient>

I used "a word" as a trigger test and got this output:


plugin 1
1:
  "textcolour"=12632256
  "backcolour"=0
  "length"=2
  "style"=0
  "text"="a "
2:
  "textcolour"=255
  "backcolour"=0
  "length"=4
  "style"=0
  "text"="word"
plugin 2

Where I would have expected to get this:


plugin 1
1:
  "textcolour"=12632256
  "backcolour"=0
  "length"=6
  "style"=0
  "text"="a word"
plugin 2

Nick Gammon Australia Forum Administrator Tue 24 Mar 2020 06:52 AM #9

My compliments on doing exactly what I asked, very quickly! These are the questions that are a joy to answer!

:)

Now, by processing in a script file you are processing the line quite late (see point 13 in the link I gave above).

To get the style information when the trigger is actually invoked is a bit trickier. In fact, there is no particularly simple way of doing it. However the trigger below illustrates a way of doing it, which returns the expected results:


<triggers>
  <trigger
   enabled="y"
   ignore_case="y"
   keep_evaluating="y"
   match="^.*word.*$"
   regexp="y"
   sequence="100"
   name="word_line"
   send_to="12"
  >
<send>

t = GetStyleInfo (GetLinesInBufferCount ())     -- get all styles, all types for the last line

print("plugin 1")  -- print this now or IT will be the last line

for k, v in pairs (t) do 
  Note ("style run = ", k)  -- this is one style
  for a, b in pairs (v) do  -- display all info types for style
    Note (" item = ", a, " value = ", b)
  end  
end

</send>
  </trigger>
</triggers>

On your test data:


plugin 1
style run = 1
 item = textcolour value = 12632256
 item = action value = 
 item = backcolour value = 0
 item = starttag value = false
 item = text value = a word
 item = changed value = false
 item = variable value = 
 item = actiontype value = 0
 item = blink value = false
 item = inverse value = false
 item = bold value = false
 item = column value = 1
 item = length value = 6
 item = ul value = false
 item = hint value = 
plugin 2

You can see there is only one style run, and it has the expected colour in it.

So, it was a sequencing issue. Your script ran later than expected, even though your plugin trigger ran at the correct time.

Zimmy Tue 24 Mar 2020 06:21 PM #10

Thank you, I get it now!

By the way, the regex I'm using for triggers is quite complex, so I generate them in the plugin using AddTrigger and SetTriggerOption. In order to add <Send> tags I needed to ExportXML, inject code stored a string and then ImportXML. I don't know if there's a better way to do this but I thought it was super cool.

Nick Gammon Australia Forum Administrator Tue 24 Mar 2020 10:42 PM #11

Just be careful that, for long lines, the lines in the buffer may be more than the lines received. In other words, for lines that exceed what will fit into an output line:


Line A
Line B
Line C
Line D <newline>
Line E
Line F
Line G
Line H <newline>

Now the trigger will fire (if wanted) at lines D and H as they have a newline. However since the lines span multiple lines in the output buffer you really need to count backwards. In other words, loop backwards from the last line until you find a newline (in this case, line D) and then go forward one line. Now that line onwards is the line the trigger would have matched on (lines E to H).

You can see if the line has a newline by using GetLineInfo.

GetLineInfo

The documentation for the GetLineInfo script function is available online. It is also in the MUSHclient help file.

Selector 3 tells you if that line had a newline or not.

Zimmy Wed 25 Mar 2020 06:32 AM #12

Nick Gammon said:

Just be careful that, for long lines, the lines in the buffer may be more than the lines received. In other words, for lines that exceed what will fit into an output line:

Here's what I did:


local n = GetLinesInBufferCount()
local styles = GetStyleInfo (n)
n = n - 1
while not GetLineInfo(n, 3) do	
  local t = GetStyleInfo (n)
  if type(t) == 'table' then
    for i, v in ipairs(t) do
      if i == #t and styles[i].textcolour == v.textcolour then
        styles[i].text = v.text..styles[i].text
        styles[i].length = styles[i].length + v.length
      else
        table.insert(styles, i, v)
      end
    end
  end
  n = n - 1
  if n == -1000 then break end
end