Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ MUSHclient
➜ General
➜ 'omit from output' triggers slightly delayed
|
'omit from output' triggers slightly delayed
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
Pages: 1 2
3
| Posted by
| Alisa
(20 posts) Bio
|
| Date
| Mon 07 Oct 2019 07:14 AM (UTC) |
| Message
| A game I play on recently made the questionable decision to relax their rules regarding spam frequency on public chat channels, so I am trying to set up a simple trigger to automatically omit the worst offenders from output, in effect causing them to cease to exist on my end.
Unfortunately, I seem to be doing something wrong. The trigger does work as intended but there seems to be some kind of slight delay involved with it. Omitted lines are indeed omitted, but only after a brief delay of around 1 or 2 seconds; long enough for me to glimpse the lines before they poof out of existence.
This causes my output screen to kind of erratically 'jerk' up and down when these lines are encountering the trigger, in that they briefly appear, cause the output window to scroll down one line to make room for them, then the line is removed and the output window jerks back upward when the line vanishes.
Being that this is somehow even more annoying than having to see the same obnoxious advertisements in chat every 5 minutes, I'm hoping someone here can take a look at this screencap of an example trigger and suggest what might be causing the delay here. I've seamlessly used this sort of trigger in the past so I'm not sure what I might have borked up to suddenly cause it to stop working as intended.
https://puu.sh/EpJko/48d2d111fd.png
(The <General> bit in the trigger is to include the displayed name of the chat channel so that I can only filter out lines beginning this way, rather than omitting any line even mentioning the offender's name.) | | Top |
|
| Posted by
| Nick Gammon
Australia (23,140 posts) Bio
Forum Administrator |
| Date
| Reply #1 on Mon 07 Oct 2019 09:30 AM (UTC) Amended on Mon 07 Oct 2019 10:14 AM (UTC) by Nick Gammon
|
| Message
| First, we prefer if you copy the trigger as text so it can be pasted into a test without actually retyping:
 |
For advice on how to copy aliases, timers or triggers from within MUSHclient, and paste them into a forum message, please see Copying XML.
|
It seems odd to check "Keep Evaluating" and then go to the trouble of running a script to stop evaluating. Perhaps you are trying to stop evaluation in all plugins? In any event, I would uncheck "Keep Evaluating". Example:
<triggers>
<trigger
enabled="y"
ignore_case="y"
match="^<General> Blah Blah Blah Spam Sure Is Annoying .+$"
omit_from_output="y"
regexp="y"
sequence="1"
>
</trigger>
</triggers>
|
|
For advice on how to copy the above, and paste it into MUSHclient, please see Pasting XML.
|
I can't actually reproduce your problem. Using version 5.06 of the client I don't see the effect you are describing.
To download:
http://www.gammon.com.au/downloads/dlmushclient.htm
|
|
Please help us by advising the version of MUSHclient you are using. Use the Help menu -> About MUSHclient.
|
The general way that the client works is that a line from the MUD is displayed (byte by byte) in the output window, and then when a newline is received, triggers are evaluated. This conceivably might cause text to briefly appear and then disappear. On my PC, which is fairly fast, I don't notice that. The updating of the screen itself should occur periodically, not for every byte received. This might sound contradictory, but there are two things: the screen data as assembled, ready to be displayed, and the moment when it is actually displayed.
If you are using the latest client, and unchecking "Keep Evaluating" doesn't work, then a fall-back position would be to try to get the spam out of the input packet before it is processed at all. This might be fiddly to do if the spam spans multiple network packets, but if it doesn't it should be reliable.
A possible plugin to implement the packet approach would be this.
|
|
To save and install the Omit_Spam plugin do this:
- Copy between the lines below (to the Clipboard)
- Open a text editor (such as Notepad) and paste the plugin into it
- Save to disk on your PC, preferably in your plugins directory, as Omit_Spam.xml
- Go to the MUSHclient File menu -> Plugins
- Click "Add"
- Choose the file Omit_Spam.xml (which you just saved in step 3) as a plugin
- Click "Close"
|
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE muclient>
<muclient>
<plugin
name="Omit_Spam"
author="Nick Gammon"
id="cd039821125303ed7c839fbf"
language="Lua"
purpose="Omits spam from packets"
date_written="2019-10-07 20:17:00"
requires="5.00"
version="1.0"
>
</plugin>
<!-- Script -->
<script>
<![CDATA[
function OnPluginPacketReceived (s)
return (string.gsub (s, "<General> Blah Blah Blah Spam Sure Is Annoying .-\r?\n", ""))
end -- OnPluginPacketReceived
]]>
</script>
</muclient>
Note that this uses Lua regular expressions, not PCRE ones.
The Lua regular expression syntax is documented here:
http://www.gammon.com.au/scripts/doc.php?lua=string.find
In particular, a non-greedy wildcard is ".-" rather than what you had. This particular plugin scans the entire packet for the spam (which might occur multiple times) hence the test for a newline.
This test will fail if the spam spans multiple packets, but if you combine the plugin with the trigger it should be less annoying. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Nick Gammon
Australia (23,140 posts) Bio
Forum Administrator |
| Date
| Reply #2 on Mon 07 Oct 2019 09:43 AM (UTC) Amended on Mon 07 Oct 2019 09:46 AM (UTC) by Nick Gammon
|
| Message
| A more sophisticated approach at the packet level would be to detect the spammer name, like this:
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE muclient>
<muclient>
<plugin
name="Omit_Spam"
author="Nick Gammon"
id="cd039821125303ed7c839fbf"
language="Lua"
purpose="Omits spam from packets"
date_written="2019-10-07 20:17:00"
date_modified="2019-10-07 20:45:00"
requires="5.00"
version="1.1"
>
</plugin>
<!-- Script -->
<script>
<![CDATA[
idiots = {
"Lorem",
"ipsum",
"dolor",
"sit",
"amet",
"consectetur",
"adipiscing",
"elit",
}
-- turn table into keyed by name table
idiots_lookup = {}
for k, v in ipairs (idiots) do
idiots_lookup [v] = true
end -- for
function spammer_test (a)
if idiots_lookup [a] then
return ""
end -- if
-- show original line
return nil
end -- function spammer_test
function OnPluginPacketReceived (s)
return (string.gsub (s, "<General> ([^ ]+) .-\r?\n", spammer_test))
end -- OnPluginPacketReceived
]]>
</script>
</muclient>
Now you make a simple list of the idiots you want to ignore (this is case-sensitive). The function takes any input matching: "<General> somename somespam" and then checks the name against the list. If a spammer shows up the whole line is omitted, otherwise it is allowed through unchanged.
If there is some punctuation (eg. a colon after the name) then add that into the regular expression. This particular regexp assumes that the name is anything other than spaces, but you can tweak that. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Nick Gammon
Australia (23,140 posts) Bio
Forum Administrator |
| Date
| Reply #3 on Mon 07 Oct 2019 10:19 AM (UTC) |
| Message
| My solution above might fail if people put "<General> spammer spam" in a message that is not at the start of the line. I didn't want to test for a newline at the start, as packets probably don't start with a newline.
If this is an issue, we could add an extra newline at the start, check for "\n spam message \n" and then omit that first newline.
However let's not go to that complexity unless it turns out to be a problem. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Fiendish
USA (2,535 posts) Bio
Global Moderator |
| Date
| Reply #4 on Mon 07 Oct 2019 02:48 PM (UTC) Amended on Mon 07 Oct 2019 02:52 PM (UTC) by Fiendish
|
| Message
|
Quote:
Omitted lines are indeed omitted, but only after a brief delay of around 1 or 2 seconds
I wonder if the server is doing something strange, like waiting a second before sending newline in a separate packet, or sending newline at the start of each message rather than at the end. A snippet from the packet debug display might clarify. ( Edit menu -> Debug Packets ) |
https://github.com/fiendish/aardwolfclientpackage | | Top |
|
| Posted by
| Nick Gammon
Australia (23,140 posts) Bio
Forum Administrator |
| Date
| Reply #5 on Wed 09 Oct 2019 09:09 PM (UTC) |
| Message
| | I agree with Fiendish that this is a plausible explanation. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Alisa
(20 posts) Bio
|
| Date
| Reply #6 on Thu 10 Oct 2019 04:37 AM (UTC) |
| Message
| Hello again! Just a quick note that I am not ignoring anyone or taking my help and running! Things have been a bit hectic this week and I haven't been able to MUSH as often as I would like.
I realized later that something which may or may not be useful for the troubleshooting is that the game uses Pueblo and, while I have the resulting clicky links disabled from displaying on my end, I think the game actually still transmits the code around them. Would that maybe have something to do with the weird jerky delay for the omitted lines?
Also! With the plugin helpfully provided, how does that search for the names? Does it search the entire line, or just the beginning? What happens if the user has a channel title showing prior to their name? Like a line might start out as '<General> Titlehere Namehere' before getting on with whatever they said or posed. And what happens if that title has punctuation included?
Sorry for all of the questions. I figured that there has to be something else influencing all of this if your own tests could not reproduce the problem, especially after I gave it a try on 5.05, 5.06, and the 5.07-prerelease with the same results across all three.
As for the packet debug, I ducked into the game for a moment to grab the debug for whatever line first popped up. I have no idea what all of this mess means but maybe it will be useful for your suspicions?
Incoming packet: 87 (2 bytes) at Thursday, October 10, 2019, 12:24:28 AM
ÿñ ff f1
Incoming packet: 88 (160 bytes) at Thursday, October 10, 2019, 12:24:33 AM
<.[35mGeneral 26 6c 74 3b 1b 5b 33 35 6d 47 65 6e 65 72 61 6c
.[0m> .[38;5; 1b 5b 30 6d 26 67 74 3b 20 1b 5b 33 38 3b 35 3b
228mHoney.[0m .[ 32 32 38 6d 48 6f 6e 65 79 1b 5b 30 6d 20 1b 5b
38;5;255mMaid.[0 33 38 3b 35 3b 32 35 35 6d 4d 61 69 64 1b 5b 30
m Ayako Kurota s 6d 20 41 79 61 6b 6f 20 4b 75 72 6f 74 61 20 73
ays, "Don't 61 79 73 2c 20 26 71 75 6f 74 3b 44 6f 6e 27 74
worry, Kamadeva 20 77 6f 72 72 79 2c 20 4b 61 6d 61 64 65 76 61
, White Ren is a 2c 20 57 68 69 74 65 20 52 65 6e 20 69 73 20 61
totally differe 20 74 6f 74 61 6c 6c 79 20 64 69 66 66 65 72 65
nt person." 6e 74 20 70 65 72 73 6f 6e 2e 26 71 75 6f 74 3b
Incoming packet: 88 (1 bytes) at Thursday, October 10, 2019, 12:24:33 AM
< 3c
Incoming packet: 88 (1 bytes) at Thursday, October 10, 2019, 12:24:33 AM
> 3e
Incoming packet: 88 (1 bytes) at Thursday, October 10, 2019, 12:24:33 AM
" 22
Incoming packet: 88 (1 bytes) at Thursday, October 10, 2019, 12:24:33 AM
" 22
Incoming packet: 89 (5 bytes) at Thursday, October 10, 2019, 12:24:33 AM
<BR>. 3c 42 52 3e 0a
| | Top |
|
| Posted by
| Nick Gammon
Australia (23,140 posts) Bio
Forum Administrator |
| Date
| Reply #7 on Thu 10 Oct 2019 06:38 AM (UTC) |
| Message
| Well, the plugin won't work with that because, amongst other things, the newline is in the 6th packet.
Is that what the MUD sends? It looks like rubbish.
For one thing, you have single byte packets which are inefficient. They could conceivably introduce delays.
There are colour codes there which would throw out my regular expression (that isn't their fault).
<General> Honey Maid Ayako Kurota says, "Don't worry, Kamadeva, White Ren is a totally different person."""
Is that what you see on your screen? A chat line ending in three double-quotes? Weird.
Packet 88 and packet 89 are just "<" and ">" which doesn't make any sense when using Pueblo.
Can you respond to this please?
|
|
Please help us by advising the version of MUSHclient you are using. Use the Help menu -> About MUSHclient.
|
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Alisa
(20 posts) Bio
|
| Date
| Reply #8 on Thu 10 Oct 2019 07:31 AM (UTC) Amended on Thu 10 Oct 2019 07:32 AM (UTC) by Alisa
|
| Message
| As noted in my last post, I have been trying to fix this with 5.05, 5.06, and 5.07-pre to no avail. 5.07-pre is the one where that packet debug came from, just because it was the last version in the sequence I tried and thus the one I left installed.
I don't believe there are triple quotes at the end of the lines. I would have to check when I get home to be certain but that seems like an oddity I would have noticed a long time ago.
As for the code... yeah, the coder there is apparently absolutely terrible. I do not know enough about code to criticize but my coder friends and coders from other games pretty much despise this person, who supposedly steals code from other places, tacks on a few clumsy tweaks, then calls it their own product. They even obfuscate all kinds of things so much that players can't even examine themselves to see which attributes are set, rendering @decompile useless. I have no idea why but the coder people say it is to keep people from seeing the underhanded stuff this person does.
MUSH drama hoooooooooo! | | Top |
|
| Posted by
| Nick Gammon
Australia (23,140 posts) Bio
Forum Administrator |
| Date
| Reply #9 on Thu 10 Oct 2019 10:16 AM (UTC) |
| Message
| Actually, the packet numbers in what you posted look suspicious:
Incoming packet: 87 (2 bytes) at Thursday, October 10, 2019, 12:24:28 AM
Incoming packet: 88 (160 bytes) at Thursday, October 10, 2019, 12:24:33 AM
Incoming packet: 88 (1 bytes) at Thursday, October 10, 2019, 12:24:33 AM
Incoming packet: 88 (1 bytes) at Thursday, October 10, 2019, 12:24:33 AM
Incoming packet: 88 (1 bytes) at Thursday, October 10, 2019, 12:24:33 AM
Incoming packet: 88 (1 bytes) at Thursday, October 10, 2019, 12:24:33 AM
Incoming packet: 89 (5 bytes) at Thursday, October 10, 2019, 12:24:33 AM
You have a lot of packet number 88 there. That doesn't look right. Either you edited what was in the packet debug, or the client has a bug with packet numbers. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Alisa
(20 posts) Bio
|
| Date
| Reply #10 on Thu 10 Oct 2019 10:46 AM (UTC) Amended on Thu 10 Oct 2019 10:47 AM (UTC) by Alisa
|
| Message
| Nothing was edited on this end. I wouldn't even know what to edit. I copied it straight from the window to a text file to ensure it copied okay, then from the text file to here.
If it helps, I can grab another packet sample later from 5.06. Maybe the prerelease of 5.07 is having a tantrum. | | Top |
|
| Posted by
| Alisa
(20 posts) Bio
|
| Date
| Reply #11 on Thu 10 Oct 2019 12:12 PM (UTC) |
| Message
| Here are three packet debugs from 5.06. The first two are from someone without a channel title, the third is from someone with a channel title that has color and a punctuation mark in it. I have no idea what could be causing the problem here so I figured giving examples of multiple situations might be helpful.
Incoming packet: 7 (49 bytes) at Thursday, October 10, 2019, 7:51:26 AM
<.[35mGeneral 26 6c 74 3b 1b 5b 33 35 6d 47 65 6e 65 72 61 6c
.[0m> Grugork 1b 5b 30 6d 26 67 74 3b 20 47 72 75 67 6f 72 6b
pets the puppie 20 70 65 74 73 20 74 68 65 20 70 75 70 70 69 65
s 73
Incoming packet: 7 (1 bytes) at Thursday, October 10, 2019, 7:51:26 AM
< 3c
Incoming packet: 7 (1 bytes) at Thursday, October 10, 2019, 7:51:26 AM
> 3e
Incoming packet: 8 (5 bytes) at Thursday, October 10, 2019, 7:51:26 AM
<BR>. 3c 42 52 3e 0a
Incoming packet: 9 (71 bytes) at Thursday, October 10, 2019, 7:51:53 AM
<.[35mGeneral 26 6c 74 3b 1b 5b 33 35 6d 47 65 6e 65 72 61 6c
.[0m> Grugork 1b 5b 30 6d 26 67 74 3b 20 47 72 75 67 6f 72 6b
pulls Belladonn 20 70 75 6c 6c 73 20 42 65 6c 6c 61 64 6f 6e 6e
a down from the 61 20 64 6f 77 6e 20 66 72 6f 6d 20 74 68 65 20
ceiling 63 65 69 6c 69 6e 67
Incoming packet: 9 (1 bytes) at Thursday, October 10, 2019, 7:51:53 AM
< 3c
Incoming packet: 9 (1 bytes) at Thursday, October 10, 2019, 7:51:53 AM
> 3e
Incoming packet: 10 (5 bytes) at Thursday, October 10, 2019, 7:51:53 AM
<BR>. 3c 42 52 3e 0a
Incoming packet: 24 (88 bytes) at Thursday, October 10, 2019, 7:55:32 AM
<.[35mGeneral 26 6c 74 3b 1b 5b 33 35 6d 47 65 6e 65 72 61 6c
.[0m> Go for 1b 5b 30 6d 26 67 74 3b 20 47 6f 20 66 6f 72 20
a .[38;5;80mswim 61 20 1b 5b 33 38 3b 35 3b 38 30 6d 73 77 69 6d
.[0m? Misty lean 1b 5b 30 6d 3f 20 4d 69 73 74 79 20 6c 65 61 6e
s on Nessa. Boop 73 20 6f 6e 20 4e 65 73 73 61 2e 20 42 6f 6f 70
tanuki. 20 74 61 6e 75 6b 69 2e
Incoming packet: 24 (1 bytes) at Thursday, October 10, 2019, 7:55:32 AM
< 3c
Incoming packet: 24 (1 bytes) at Thursday, October 10, 2019, 7:55:32 AM
> 3e
Incoming packet: 25 (5 bytes) at Thursday, October 10, 2019, 7:55:32 AM
<BR>. 3c 42 52 3e 0a
| | Top |
|
| Posted by
| Alisa
(20 posts) Bio
|
| Date
| Reply #12 on Thu 10 Oct 2019 12:13 PM (UTC) |
| Message
| And to be extra thorough, here is another packet debug from someone who should have been omitted and triggered that odd 1-second delay before the line poofed. Maybe there is something in here that isn't in the others?
Incoming packet: 20 (130 bytes) at Thursday, October 10, 2019, 7:54:52 AM
<.[35mGeneral 26 6c 74 3b 1b 5b 33 35 6d 47 65 6e 65 72 61 6c
.[0m> .[38;5; 1b 5b 30 6d 26 67 74 3b 20 1b 5b 33 38 3b 35 3b
57mDo Not Trust. 35 37 6d 44 6f 20 4e 6f 74 20 54 72 75 73 74 1b
[0m Riven nods a 5b 30 6d 20 52 69 76 65 6e 20 6e 6f 64 73 20 61
nd maybe sneaks 6e 64 20 6d 61 79 62 65 20 73 6e 65 61 6b 73 20
a quick feel on 61 20 71 75 69 63 6b 20 66 65 65 6c 20 6f 6e 20
Ruby~ "Good 52 75 62 79 7e 20 26 71 75 6f 74 3b 47 6f 6f 64
to know." 20 74 6f 20 6b 6e 6f 77 2e 26 71 75 6f 74 3b 20
^^ 5e 5e
Incoming packet: 20 (1 bytes) at Thursday, October 10, 2019, 7:54:52 AM
< 3c
Incoming packet: 20 (1 bytes) at Thursday, October 10, 2019, 7:54:52 AM
> 3e
Incoming packet: 20 (1 bytes) at Thursday, October 10, 2019, 7:54:52 AM
" 22
Incoming packet: 20 (1 bytes) at Thursday, October 10, 2019, 7:54:52 AM
" 22
Incoming packet: 21 (5 bytes) at Thursday, October 10, 2019, 7:54:52 AM
<BR>. 3c 42 52 3e 0a
| | Top |
|
| Posted by
| Nick Gammon
Australia (23,140 posts) Bio
Forum Administrator |
| Date
| Reply #13 on Thu 10 Oct 2019 08:39 PM (UTC) Amended on Thu 10 Oct 2019 08:41 PM (UTC) by Nick Gammon
|
| Message
| The multiple packets with the same number seem to be recurring. It looks like this is an artefact of the MCCP compression. For some (odd) reason the message is being compressed multiple times in succession.
Quote:
As for the code... yeah, the coder there is apparently absolutely terrible.
That's certainly a possible reason.
Compressing a single-byte piece of data is likely to increase the amount of data sent, not decrease it.
Try turning off compression, that might cause the packets to not be split up like that.
Configuration -> Appearance -> Output -> Disable compression.
Then collect some more packets for us. Do those multiple quotes appear in the output on your screen or not? It would help to copy/paste (here) what you see in the output window as well as the packet debug (for the same chat messages).
Try also disabling Pueblo.
Configuration -> Appearance -> MXP / Pueblo -> Use MXP/Pueblo: No - Never. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Nick Gammon
Australia (23,140 posts) Bio
Forum Administrator |
| Date
| Reply #14 on Thu 10 Oct 2019 08:43 PM (UTC) |
| Message
|
Alisa said:
Also! With the plugin helpfully provided, how does that search for the names? Does it search the entire line, or just the beginning? What happens if the user has a channel title showing prior to their name? Like a line might start out as '<General> Titlehere Namehere' before getting on with whatever they said or posed. And what happens if that title has punctuation included?
It just looked for the first word (something delimited by spaces) after the channel name. With all those colour codes you had it wouldn't have matched anything, and it looks like the names have spaces in them, so work would be needed to make that work properly. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | 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.
82,912 views.
This is page 1, subject is 3 pages long: 1 2
3
![[Next page]](/images/thin_next.gif)
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top