Triggers that may or may not gag.

Posted by Twisol on Thu 06 Aug 2009 05:20 AM — 9 posts, 31,991 views.

USA #0
What would be the best way to handle this scenario? I have a set of triggers that gag and parse a certain stretch of text under certain conditions. Let's say it gags a map as you move. These triggers come in a specific order and have different groups.

Now what happens if you don't want to gag that when the user uses a command to get it? Obviously it needs to be displayed, not gagged, but you still want the parsing to be done.

My solution right now involves taking a table of trigger labels and iterating over them to set/unset the gagging options at need. It seems klutzy to me, and I was wondering if there was a better way.
Australia Forum Administrator #1
I was going to suggest something similar. Say you type "map" and you want to see the map, but usually you gag it (or, inventory, or something).

One approach would be to have a "map" alias that turns off the "omit from output" flag on the appropriate trigger. Then, when the map has fully appeared (ie. the line that normally terminates the map output) it could turn omit from output back on, ready for next time.
USA #2
Yeah, that's exactly what I'm doing, just for multiple triggers (since I have distinct start, middle, and end areas that all need conditional gagging). It just seems like there should be a better way. Thanks anyways!
USA #3
You could use DeleteLines.
USA #4
I did look into that already, but this part of its documentation sort of throws it out the window for me:

`A line is counted as a physical line on the screen, it does not necessarily end in a newline character.`

That means it won't work as expected sometimes, depending on what wrap-width you might have set and what wrap-width the plugin-maker has. That's unacceptable for my purposes. =/
Amended on Sat 08 Aug 2009 10:21 PM by Twisol
Australia Forum Administrator #5
You can do what the client does, and work backwards to find the previous line ending in a "real" line end, and then step forwards one line. This gives you the last "paragraph".
USA #6
Hmm. How expensive is it to do that? Wouldn't that make any line-flicker stand out more?
Australia Forum Administrator #7
At present there is no line flicker if you omit a line that has just arrived, as redrawing the window is deferred to the main event loop as a low priority.

If you waited for a while and then tried to delete a batch of lines, yes there might be a flicker.

What might work for you instead is to do it a different way:

  • Omit your map or whatever it is from output as you go, in the usual way.
  • As each line arrives, in addition to your normal processing add the style runs into a Lua table. That is, on the first line (the start of the map), clear the table out, and then add that first line.
  • For subsequent lines, just do table.insert of the whole style run table.
  • Once the final line has arrived, check some flag you set in the alias to see whether you want to show the map.
  • If wanted, just run through the saved table, displaying each style run with a ColourTell / ColourNote.


That way, the map can be optionally shown, the extra work is minimal, and you don't need to toggle on or off the omit-from-output flags for lots of triggers.
Amended on Mon 10 Aug 2009 11:32 PM by Nick Gammon
USA #8
Hmm, I like that. Thanks!