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

Using more colour on server input / Matching on user output

Posted by KP on Wed 18 Jul 2007 10:43 AM — 17 posts, 81,442 views.

KP #0
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!
Shadowfyr USA #1
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
Nick Gammon Australia Forum Administrator #2
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.
Cage_fire_2000 USA #3
This is almost the exact reason I've often wished for the ability to dynamically turn Pueblo/MXP on/off from inside a script.
Nick Gammon Australia Forum Administrator #4
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.
Onoitsu2 USA #5
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
KP #6
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.
Amended on Thu 19 Jul 2007 06:11 AM by KP
Nick Gammon Australia Forum Administrator #7
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
Shaun Biggs USA #8
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.
KP #9
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.
Amended on Thu 19 Jul 2007 10:27 AM by KP
Onoitsu2 USA #10
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
KP #11
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.
Amended on Thu 19 Jul 2007 12:18 PM by KP
Nick Gammon Australia Forum Administrator #12
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


KP #13
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.
Nick Gammon Australia Forum Administrator #14
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. :)
Shadowfyr USA #15
Yeah. That is an ironic glitch, and useful in this case, even if not intended. Especially since we would have heard screams from someone by now if it effected "all" cases where a plugin sent a simulated packet, to test its own code, and not "just" in those cases where its modifying the packet. Now.. Packets often contain routing info, time stamps, etc., so I didn't even think of it at the time, but adding something to allow you to "look" at that data, or send specific meta data in the packet, could have been another solution. You could then tagged the meta data for the packet with some unique stamp, which the receiver code could then check for the stamp, to see if it should handle it, or it originated it.

Thanks to this odd quirk though, this doesn't appear to be necessary.
KP #16
Quote:

That is an ironic glitch, and useful in this case, even if not intended.

I still wouldn't rely on it though. Even if all my tests confirmed its existence, it still might have something to do with me using perl for scripting (Windows API). So LUA people should try and see if it still 'works' for them.
Nevertheless, it's still one of the nicest bug-o-features(TM) I've ever seen. ;]


Quote:

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

That I definitely am! And let me tell you this, Nick - MC has one of the best designed interfaces (and I'm not talking about GUI here. I'm talking about the events/functions/scripting callbacks etc), one of the most comprehensive and complete help files and.. it's one of the very few pieces of software that stop you from thinking 'can I do this?' and make you wonder 'which way do I want to do this?' instead. So once again, thanks! This all makes me a happy little scripter :]