First, let's examine ways of making standard trigger processing more efficient.
- Do not check "keep evaluating" unless absolutely necessary. With "keep evaluating" unchecked, as soon as a trigger matches, it stops evaluating other triggers, thus if the first trigger out of a thousand matches, it only has to do one regexp compare, not a thousand.
- Order your triggers, by sequence number, from lowest (most likely to match) to highest (least likely to match). Thus if you often get (say) a prompt line, if that has a low sequence number (like 10) then it gets tested first, thus eliminating the need to check all the other triggers. A bit of evaluating using GetTriggerInfo (selector 21) will tell you, after playing for a while, which ones match most often.
- Do not check "expand variables" unless absolutely necessary. When checked, the regular expression has to be "compiled" every time (as it may have changed), thus slowing down the regular expression matching.
- Do not use "send to script" but rather put a script function name into the Script box, and use a script file. Using "send to script" means the script has to be compiled by Lua every time, and then executed. Using a script file, the script only ever gets compiled once.
- Make your regular expressions more specific, where possible, thus allowing the regular expression state engine to match faster. For example, instead of:
use:
^You see [A-Za-z]+ here\.$
- Enable/disable groups of triggers depending on the context. For example, if a whole batch of triggers are only used in combat, put them in a group and use EnableTriggerGroup to enable them when you enter combat, and disable them after combat, thus speeding up matching because triggers that can't match, aren't evaluated.
Quote:
If I put the Notes on a timer (which might be running their own thread?) it works, but this is a sloppy solution so I'm looking for something else.
Not in a separate thread, but timers are evaluated periodically in the main loop.
Quote:
Is OnPluginLineReceived supposed, by design or intent, to work like this? Are there any ways around it?
It was designed to work that way, yes.
Two things you could do ...
- Make a single trigger, matching on "*" and omit from output. Then pass this to your script which runs your Lua pattern matching on it. Use the technique described in http://mushclient.com/faq point 23 to recreate the lines in the output window (before or after substitution) in the original colours, or altered ones.
Effectively this turns the output window into notes, but they could look the same as the original.
- Use OnPluginPacketReceived plugin callback. This actually lets you modify the packets, and thus you can change things as much as you want. The disadvantage here is that packets are supplied prior to processing for colour codes (and telnet codes etc.), and line boundaries and packet boundaries are not necessarily the same.
To make this work you really need to batch up packets until you have a completed line (there are examples on the forum), and then take each complete line and process it further. If you just want to make fairly simple changes, you could do that, then pass the changed packet on, and let MUSHclient keep decoding colours. Or, you could handle everything yourself, and use Note (or ColourNote) to put all the text on the screen.
However in this case I think my first suggestion achieves much the same result with less effort.
|
![[Go to top]](/images/gototop.gif){kind=small}
top