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

Gammon Software Solutions forum

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

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  General
. . -> [Subject]  Using more colour on server input / Matching on user output
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?
(New message)
Subject: Using more colour on server input / Matching on user output
Name:
Your forum user name.
Register forum user name
Password:
Your forum password.
Forgotten password?
Message:
Message to be posted (in English, please).
Forum codes:
Check this if your message uses 'forum codes' or templates (auto-detected for new posts).
Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Pages: 1 2  

Posted by KP   (24 posts)  [Biography] bio
Date Fri 20 Jul 2007 02:04 AM (UTC)  [ quote  ]
Message
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 :]
[Go to top] top
Posted by Shadowfyr   USA  (1,774 posts)  [Biography] bio
Date Fri 20 Jul 2007 12:09 AM (UTC)  [ quote  ]
Message
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.
main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date 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
[Go to top] top
Posted by KP   (24 posts)  [Biography] bio
Date 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.
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date 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
[Go to top] top
Posted by KP   (24 posts)  [Biography] bio
Date 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.
[Go to top] top
Posted by Onoitsu2   USA  (246 posts)  [Biography] bio
Date 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
[Go to top] top
Posted by KP   (24 posts)  [Biography] bio
Date 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.
[Go to top] top
Posted by Shaun Biggs   USA  (644 posts)  [Biography] bio
Date 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.
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date 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
[Go to top] top
Posted by KP   (24 posts)  [Biography] bio
Date 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.
[Go to top] top
Posted by Onoitsu2   USA  (246 posts)  [Biography] bio
Date 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
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date 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
[Go to top] top
Posted by Cage_fire_2000   USA  (119 posts)  [Biography] bio
Date 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.
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date 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
[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.

5,858 views.

This is page 1, subject is 2 pages long: 1 2  [Next page]

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

[Home]

Written by Nick Gammon - 5K

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

[Best viewed with any browser - 2K]    [Internet Contents Rating Association (ICRA) - 2K]    [Web site powered by FutureQuest.Net]