[Home] [Downloads] [Search] [Help/forum]


Register forum user name Search FAQ

Gammon Forum

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Lua
. . -> [Subject]  Unaltered style run passed through trigger?

Unaltered style run passed through trigger?

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


Posted by Zimmy   (31 posts)  [Biography] bio
Date Sun 22 Mar 2020 08:21 PM (UTC)

Amended on Sun 22 Mar 2020 08:22 PM (UTC) by Zimmy

Message
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>]]
[Go to top] top

Posted by Fiendish   USA  (2,514 posts)  [Biography] bio   Global Moderator
Date Reply #1 on Sun 22 Mar 2020 11:00 PM (UTC)

Amended on Sun 22 Mar 2020 11:01 PM (UTC) by Fiendish

Message
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?

https://github.com/fiendish/aardwolfclientpackage
[Go to top] top

Posted by Zimmy   (31 posts)  [Biography] bio
Date Reply #2 on Sun 22 Mar 2020 11:16 PM (UTC)
Message
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.
[Go to top] top

Posted by Nick Gammon   Australia  (22,990 posts)  [Biography] bio   Forum Administrator
Date Reply #3 on Mon 23 Mar 2020 08:44 AM (UTC)
Message
Trigger style runs are not, in fact, altered by other triggers.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Zimmy   (31 posts)  [Biography] bio
Date Reply #4 on Mon 23 Mar 2020 05:32 PM (UTC)
Message
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?
[Go to top] top

Posted by Fiendish   USA  (2,514 posts)  [Biography] bio   Global Moderator
Date Reply #5 on Mon 23 Mar 2020 08:20 PM (UTC)

Amended on Mon 23 Mar 2020 08:22 PM (UTC) by Fiendish

Message
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.

https://github.com/fiendish/aardwolfclientpackage
[Go to top] top

Posted by Zimmy   (31 posts)  [Biography] bio
Date Reply #6 on Mon 23 Mar 2020 09:44 PM (UTC)
Message
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.
[Go to top] top

Posted by Nick Gammon   Australia  (22,990 posts)  [Biography] bio   Forum Administrator
Date Reply #7 on Tue 24 Mar 2020 05:20 AM (UTC)

Amended on Tue 24 Mar 2020 05:22 AM (UTC) by Nick Gammon

Message

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).


- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Zimmy   (31 posts)  [Biography] bio
Date Reply #8 on Tue 24 Mar 2020 06:10 AM (UTC)

Amended on Tue 24 Mar 2020 06:17 AM (UTC) by Zimmy

Message
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
[Go to top] top

Posted by Nick Gammon   Australia  (22,990 posts)  [Biography] bio   Forum Administrator
Date Reply #9 on Tue 24 Mar 2020 06:52 AM (UTC)
Message
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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Zimmy   (31 posts)  [Biography] bio
Date Reply #10 on Tue 24 Mar 2020 06:21 PM (UTC)
Message
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.
[Go to top] top

Posted by Nick Gammon   Australia  (22,990 posts)  [Biography] bio   Forum Administrator
Date Reply #11 on Tue 24 Mar 2020 10:42 PM (UTC)
Message
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.

Template:function=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.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Zimmy   (31 posts)  [Biography] bio
Date Reply #12 on Wed 25 Mar 2020 06:32 AM (UTC)

Amended on Wed 25 Mar 2020 07:05 AM (UTC) by Nick Gammon

Message
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
[Go to top] 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.


25,562 views.

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

Go to topic:           Search the forum


[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

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

[Home]


Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at HostDash]