MUSHclient : General : Using more colour on server input / Matching on user output

Gammon Software Solutions forum

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

Entire forum
MUSHclient
General
Using more colour on server input / Matching on user output

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

Using more colour on server input / Matching on user output

Reply to this subject Start a new subject Refresh page

Pages: 1 2

Posted by

KP (24 posts)

Date

Wed 18 Jul 2007 10:43 AM (UTC) [ quote ]

Message

I have the following problem:

I wish to add more colour to some of the incoming data, while modifying it dynamically too. All incoming packets run through my scripts, before they are returned to MC for displaying. Unfortunately, one packet can contain more that one 'message' that I need to modify. They get split and processed one by one, but.. thats where the problem starts.

I can't insert anything except the standard ANSI colours into the data (and those are unfortunately not enough). I can't return multiple chunks of data one by one from OnPluginPacketRecieved (otherwise I'd run ColourNote after each chunk). One of my approaches was to try to display the chunks with ANSINote, but that ultimately disables trigger matching, because MC doesn't recognize that data as being sent by server anymore (and yes, for a good reason, I know).

Right now, I see no other solution than to create a unique one-shot trigger for each chunk. And that sounds.. cumbersome.

Does anyone have another idea?

Thanks!

Posted by

Shadowfyr USA (1,774 posts)

Date

Reply #1 on Wed 18 Jul 2007 07:56 PM (UTC) [ quote ]

Message

Umm. Well, you could turn on MXP, and assuming you also test for case where it can fail, like, "<<This is my room>>", and such, and do replacement of the "<" with &lt on the raw data, you could then process the line and then send it back through the rest of the triggers using "world.simulate". However, since I think simulate will also cause the line to go through packet interception too, you may need to "tag" it with some sort of nonsense code, like adding esc[99q to the start of each line. The ansi parser should simply throw it out, when it finally does display it, but you can check for the invalid code to determine it this is a packet you have "handled", or one you need to make changes in.

It would have been a damn sight easier if we had simulate from the start and some way to tell the regexp processor in triggers to simply let us also match the ansi code sequences and even MXP tags. Then all it would have taken was a trigger like: "If you don't see <my line tag> and .*", then call the process script.", while everything else would just need to add: "If you *do* see <my line tag> and 'blah...'". Though, that would wreck havoc with plugins, which wouldn't know the difference, so we are probably better off with things as they are, even if it is quite a bit more complicated. lol

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

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

Date Reply #2 on Wed 18 Jul 2007 08:44 PM (UTC) [ quote ]

Message

I wouldn't try to replicate the trigger system at the packet level, it wasn't really designed for that.

Why not just use normal triggers to match the incoming text, and not only change its colours but reformat? This is an example:


<triggers>
  <trigger
   enabled="y"
   match="* enters the room"
   omit_from_output="y"
   send_to="14"
   sequence="100"
  >
  <send>
ColourNote ("orangered", "", "Warning! Room entered by: ",
            "yellowgreen", "", "%1")
</send>
  </trigger>
</triggers>

This examples matches on "* enters the room". It both colours and reformats, by omitting the original line from output and redisplaying it.

- Nick Gammon

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

Posted by

Cage_fire_2000 USA (119 posts)

Date

Reply #3 on Wed 18 Jul 2007 11:37 PM (UTC) [ quote ]

Message

This is almost the exact reason I've often wished for the ability to dynamically turn Pueblo/MXP on/off from inside a script.

Posted by

Nick Gammon Australia (18,770 posts)

bio Forum Administrator

Date

Reply #4 on Thu 19 Jul 2007 12:10 AM (UTC) [ quote ]

Message

Quote:

It would have been a damn sight easier if we had simulate from the start and some way to tell the regexp processor in triggers to simply let us also match the ansi code sequences and even MXP tags.

Simulate was intended to inject debugging. Packet preprocessing was intended for low-level processing.

If you are going to write pattern matching at the packet level you are effectively rewriting what MUSHclient already does for you. For one thing, packets can be partial lines, or contain multiple lines. Packets can contain telnet negotiation. Packets can contain ANSI colour codes, MXP sequences and so on.

MUSHclient already has a "state machine" that deals with all that, handling packets that span lines and so on.

My suggested solution will let you change the text of incoming lines, and change its colouring as well.

- Nick Gammon

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

Posted by

Onoitsu2 USA (246 posts)

Date

Reply #5 on Thu 19 Jul 2007 03:53 AM (UTC) [ quote ]

Message

I used simulate in one of my plugins, the Group Monitor plugin that reformats and colors the line, and omits some non-vital info. It does a simulate in the exact form that it is reformatted in so that you can use triggers to catch certain things that may happen in the reformatted form, I made the simulate use the ANSI color for black lettering, so that if it were not omitted by your trigger it would be just a simple "blank line" and would not interfere with visuals too much.

This might be something that might need to be used once you reformat the output and color it, so that you can use triggers based upon such a reformatted output.

Laterzzz,
Onoitsu2

Posted by KP (24 posts) bio

Date

Reply #6 on Thu 19 Jul 2007 06:10 AM (UTC) [ quote ]

Amended on Thu 19 Jul 2007 06:11 AM (UTC) by KP

Message

Quote:

If you are going to write pattern matching at the packet level you are effectively rewriting what MUSHclient already does for you.
...
My suggested solution will let you change the text of incoming lines, and change its colouring as well.

Unfortunately, your solution works for single line matching. In my case, I can't rely on the data I need to capture to be all on the same line.

Sometimes it is this part and that
part that matters. And sometimes it is this
one and maybe that one.
But they also can be both on the same line.

It's not possible to 'omit from output' when using multiline triggers. And because MC handles the server input line by line, it's hard to get multiline triggers to work in some cases or stop them from firing twice in others. This is why I resorted to working with raw packets.

The Simulate function sounds interesting (I totally missed it, thanks for pointing it out), but I'm not sure if thats a good way to go. I'll try it, but I might have to resort to using the standard ANSI for colouring in the end.

Posted by

Nick Gammon Australia (18,770 posts)

bio Forum Administrator

Date

Reply #7 on Thu 19 Jul 2007 06:50 AM (UTC) [ quote ]

Message

Your example doesn't lend itself to a simple solution, even at the packet level. For example, you can't afford to send the packet on to be processed until you are sure it does *not* match the multi-line sequence that might need changing/colouring. Conceivably you will hold up (and therefore not see) some lines until your packet processor is sure that it can allow them through.

Quote:

It's not possible to 'omit from output' when using multiline triggers.

You can use DeleteLines if you are cautious:

http://www.gammon.com.au/scripts/doc.php?function=DeleteLines

- Nick Gammon

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

Posted by Shaun Biggs USA (644 posts) bio

Date Reply #8 on Thu 19 Jul 2007 10:13 AM (UTC) [ quote ]

Message

For anything weird and complicated like this, I usually just have a few triggers turning each other on and off.and storing data into script variables. I haven't found terribly much use for the multiline triggers because, quite frankly, I just can't get them to work right (through my own fault).

The way your pseudo-example pattern went, I'm thinking it's a lot like how you have to capture stats on items when identifying on Aardwolf. The order is different on each item, and sometimes things show up twice.


+-----------------------------------------------------------------+
| Stat Mods  : Damage roll  : +6       Hp           : +100        |
|              Mana         : +50      Moves        : +200        |
|              Dexterity    : +3       Strength     : +5          |
|              Dexterity    : +5       Intelligence : +5          |
|              Wisdom       : +8       Constitution : +5          |
|              Luck         : +6       Hit roll     : +1          |
| Affect Mods: sanctuary                                          |
+-----------------------------------------------------------------+

As you can see, dex shows up twice, so that has to be taken into account. I just have a trigger match the stat mods and dump them into the appropriate table with item["%1"] = (item["%1"] or 0) + %2 and such. Then another trigger grabbing that bottom line to turn off the stat triggers.

It is much easier to fight for one's ideals than to live up to them.

Posted by KP (24 posts) bio

Date

Reply #9 on Thu 19 Jul 2007 10:15 AM (UTC) [ quote ]

Amended on Thu 19 Jul 2007 10:27 AM (UTC) by KP

Message

Quote:

Your example doesn't lend itself to a simple solution, even at the packet level. For example, you can't afford to send the packet on to be processed until you are sure it does *not* match the multi-line sequence that might need changing/colouring. Conceivably you will hold up (and therefore not see) some lines until your packet processor is sure that it can allow them through.

That was easily solved, because I get telnet indicators when a dataset is complete, so all I need to do is to buffer up until I get one (and this only happens if a dataset gets too big to fit into one packet and gets split into multiple ones).

After messing around with Simulate, I have noticed an interesting feature, that I'd need to get confirmed. If called from OnPluginRecieved, it will not trigger it in the same plugin again. Any truth to that? If that is really correct, then it's all the 'magic' I need.

EDIT:

Quote:

For anything weird and complicated like this, I usually just have a few triggers turning each other on and off.

I've been using a similar approach on captures too, in the past. But it doesn't work if you also need to modify the data, while keeping it 'triggerable'. Like if you'd redraw the table from your example and display the stats already summed up and still have other triggers work on the result.

Posted by

Onoitsu2 USA (246 posts)

Date

Reply #10 on Thu 19 Jul 2007 11:27 AM (UTC) [ quote ]

Message

Quote:
Like if you'd redraw the table from your example and display the stats already summed up and still have other triggers work on the result.

Perhaps you missed my post earlier, I do that task in one of my plugins, I have it actually modify the life/max values into percentages and output it, and use simulate to allow people to create triggers themselves based upon the altered data.

So you COULD just simulate each line of the data, and have a trigger set to omit from output, keep evaluating, and have a low sequence on it, then have a second trigger that does all the work on it. So that you know it is omitted, the simulate that is, and still triggerable, and it "appears" to trigger from the colournote, or note itself.

Hope this might spark a few ideas for your needs,
Onoitsu2

Posted by

KP (24 posts)

Date

Reply #11 on Thu 19 Jul 2007 12:16 PM (UTC) [ quote ]

Amended on Thu 19 Jul 2007 12:18 PM (UTC) by KP

Message

Yes, your post was very helpful, thank you. But as I said..

Quote:

After messing around with Simulate, I have noticed an interesting feature, that I'd need to get confirmed. If called from OnPluginRecieved, it will not trigger OnPluginRecieved in the same plugin again. Any truth to that? If that is really correct, then it's all the 'magic' I need.

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

Date Reply #12 on Thu 19 Jul 2007 09:12 PM (UTC) [ quote ]

Message

Quote:

If called from OnPluginRecieved, it will not trigger it in the same plugin again. Any truth to that? If that is really correct, then it's all the 'magic' I need.

It *will* recall OnPluginPacketReceived (note spelling) however if you are trying to stop an endless loop you could do this:


  EnablePlugin(GetPluginID (), false)
  Simulate ("something")
  EnablePlugin(GetPluginID (), true)

That temporary disabling of itself, which takes place immediately, will stop Simulate from calling OnPluginPacketReceived in the next line. Then, re-enabling it will allow the plugin to continue running properly.

Of course, this will stop all other processing for the plugin as well. This probably won't matter if all this plugin does is manage packets. If it does matter you could use a global flag. eg.


local recursing = false

function OnPluginPacketReceived  (text)
  if recursing then
    return text
  end -- if

  -- do some stuff here

  recursing = true  -- stop endless loop
  Simulate ("something")
  recursing = false

  return whatever
end -- function OnPluginPacketReceived

- Nick Gammon

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

Posted by

KP (24 posts)

Date

Reply #13 on Thu 19 Jul 2007 10:58 PM (UTC) [ quote ]

Message

Quote:

It *will* recall OnPluginPacketReceived (note spelling) ...

From my experience, it does, but NOT for the plugin the Simulate was run from. I ran a few tests with up to three plugins, and everything indicated that if a plugin runs Simulate from OnPluginPacketReceived, it will not see the sent data again (the OnPluginPacketReceived is executed for all other plugins though). My first thought was "Wow! MC must have some sort of tracking to prevent such loops! Either through logic (some sort of flag marking if an event function is already running in a plugin) or though design (an event function can't be started again, if MC is already waiting for it to finish)."

I have a 'safety flag' implemented now anyway (better safe than sorry), so I stopped testing, but I though you should know.

Posted by

Nick Gammon Australia (18,770 posts)

bio Forum Administrator

Date

Reply #14 on Thu 19 Jul 2007 11:40 PM (UTC) [ quote ]

Message

Looking at the source, I can't see how that would happen. Simulate calls the same function that an incoming packet does. Admittedly it is already inside this function for the first packet, but it should retraverse the plugins for the callback.

Oh well, as long as you are happy with the solution. :)

- Nick Gammon

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

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.

5,845 views.

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

Reply to this subject Start a new subject Refresh page

Go to topic: Search the forum

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