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
| Reply #15 on Thu 10 Oct 2019 09:33 PM (UTC) |
| Message
| Oh, right. The quotes thing. They don't appear on the screen at all despite what shows in the packet debug. Only the normal quotation marks in the appropriate places!
As for the rest, disabling compression alone made no difference and the packets kept getting split up.
Disabling Pueblo as well seemed to make a difference:
Incoming packet: 343 (206 bytes) at Thursday, October 10, 2019, 5:22:43 PM
<.[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
220mB.[38;5;124m 32 32 30 6d 42 1b 5b 33 38 3b 35 3b 31 32 34 6d
urst.[0m .[38;5; 75 72 73 74 1b 5b 30 6d 20 1b 5b 33 38 3b 35 3b
220mA.[38;5;124m 32 32 30 6d 41 1b 5b 33 38 3b 35 3b 31 32 34 6d
ngel.[0m Jo says 6e 67 65 6c 1b 5b 30 6d 20 4a 6f 20 73 61 79 73
, "Meg is n 2c 20 26 71 75 6f 74 3b 4d 65 67 20 69 73 20 6e
ormal human bada 6f 72 6d 61 6c 20 68 75 6d 61 6e 20 62 61 64 61
ss, Jo is 'raise 73 73 2c 20 4a 6f 20 69 73 20 27 72 61 69 73 65
d in a lab to be 64 20 69 6e 20 61 20 6c 61 62 20 74 6f 20 62 65
perfectly engin 20 70 65 72 66 65 63 74 6c 79 20 65 6e 67 69 6e
eered to murder' 65 65 72 65 64 20 74 6f 20 6d 75 72 64 65 72 27
badass." 20 62 61 64 61 73 73 2e 26 71 75 6f 74 3b
Incoming packet: 344 (5 bytes) at Thursday, October 10, 2019, 5:22:44 PM
<BR>. 3c 42 52 3e 0a
Enabling compression again did not change these improved results, but the moment I enabled Pueblo again (and relogged, since it did not kick back in simply by toggling) it was back to the multiple packets and strange unseen quotes. | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #16 on Fri 11 Oct 2019 06:09 AM (UTC) Amended on Fri 11 Oct 2019 06:10 AM (UTC) by Nick Gammon
|
| Message
| What I am seeing above is the first real evidence that the MUD is introducing the delay.
Packet 343 comes in at 5:22:43 PM and packet 344 (which has the newline in it) comes in at 5:22:44 PM.
So there is a second difference. However because of rounding it may be a partial second, but there is a second for you.
What might be needed here is a packet pre-processor that waits until a whole line has arrived and then lets the packet through for evaluation. That would eliminate the difference between the bulk of the text and the newline.
However if such a thing was there all the time, and you log on with prompts, then you won't see the prompt (because they don't have a newline).
Do you log on with prompting? What I mean is:
Enter your name: (name)
Enter your password: (password)
Some MUSHes don't use prompting, you just type an entire line, eg.
connect (name) (password)
If you do use prompting, is there some string that could tell a plugin that you have logged in? eg. "Welcome to XYZ MUD!". This would need to be something that appears after the login sequence. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #17 on Fri 11 Oct 2019 06:41 AM (UTC) Amended on Fri 11 Oct 2019 09:41 PM (UTC) by Nick Gammon
|
| Message
| This plugin should buffer the packets. Then your triggers should work.
 |
To save and install the Buffer_Lines 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 Buffer_Lines.xml
- Go to the MUSHclient File menu -> Plugins
- Click "Add"
- Choose the file Buffer_Lines.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="Buffer_Lines"
author="Nick Gammon"
id="8eb1cd324d58655b0ff057db"
language="Lua"
purpose="Buffer packets so they have a newline in them"
date_written="2019-10-11 17:27:00"
requires="4.80"
version="1.0"
>
</plugin>
<!-- Trigger to show you have connected -->
<triggers>
<trigger
enabled="y"
match="You have connected!"
script="we_connnected"
sequence="100"
>
</trigger>
</triggers>
<!-- Script -->
<script>
<![CDATA[
local previousPacket = { }
local lines = { }
local buffer_packets = false
-- add to lines table
function addToLines (s)
lines [#lines + 1] = s
return "" -- omit from the existing line
end -- end of function addToLines
-- here when we log in
function we_connnected (name, line, wildcards)
buffer_packets = true
end -- we_connnected
function OnPluginPacketReceived (packet)
-- do nothing if we haven't logged in
if not buffer_packets then
return nil
end -- not reached connection message
-- add packet to previous ones
previousPacket [#previousPacket + 1] = packet
-- combine into one long string
local allPackets = table.concat (previousPacket)
lines = { } -- no lines yet
-- break up combined packet into lines with LF in them
local LeftOver = string.gsub (allPackets, "([^\n]*)\n", addToLines)
-- if no linefeed in line return nothing
if #lines == 0 then
return ""
end -- if
-- this last part did not have a LF in it
previousPacket = { LeftOver }
-- return existing lines with the LF added back
return table.concat (lines, "\n") .. "\n"
end -- OnPluginPacketReceived
function OnPluginConnect ()
previousPacket = {}
buffer_packets = false
end -- OnPluginConnect
]]>
</script>
</muclient>
What this is doing is keeping a buffer, and adding new packets to it. When the buffer has newlines in it they are passed on to the client. This guarantees that the packets will end with a newline, and thus be processed quickly. Packets (such as you showed) with no newline are retained until a newline arrives.
To allow for the initial login prompts it waits for a line from the MUD "You have connected!" which you can amend to be something you see after you have logged in. Before that arrives the buffering is disabled, so you can see the name/password prompts. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Fiendish
USA (2,555 posts) Bio
Global Moderator |
| Date
| Reply #18 on Fri 11 Oct 2019 06:10 PM (UTC) Amended on Fri 11 Oct 2019 06:11 PM (UTC) by Fiendish
|
| Message
|
Quote:Incoming packet: 344 (5 bytes) at Thursday, October 10, 2019, 5:22:44 PM
<BR>. 3c 42 52 3e 0a
Oof. Looks like I was right. What a terrible server design. |
https://github.com/fiendish/aardwolfclientpackage | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #19 on Fri 11 Oct 2019 09:13 PM (UTC) Amended on Fri 11 Oct 2019 09:42 PM (UTC) by Nick Gammon
|
| Message
| I've rewritten the plugin to make it less confusing.
 |
To save and install the Buffer_Lines 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 Buffer_Lines.xml
- Go to the MUSHclient File menu -> Plugins
- Click "Add"
- Choose the file Buffer_Lines.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="Buffer_Lines"
author="Nick Gammon"
id="8eb1cd324d58655b0ff057db"
language="Lua"
purpose="Buffer packets so they have a newline in them"
date_written="2019-10-11 17:27:00"
date_modified="2019-10-12 08:06:00"
requires="4.80"
version="1.1"
>
</plugin>
<!-- Trigger to show you have connected -->
<triggers>
<trigger
enabled="y"
match="You have connected!"
script="we_connnected"
sequence="100"
>
</trigger>
</triggers>
<!-- Script -->
<script>
<![CDATA[
local previousPacket = ""
local buffer_packets = false
-- here when we log in
function we_connnected (name, line, wildcards)
if not buffer_packets then
ColourNote ("green", "", "Packet buffering now active")
end -- if
buffer_packets = true
end -- we_connnected
function OnPluginPacketReceived (packet)
-- do nothing if we haven't logged in
if not buffer_packets then
return nil -- this makes the client process the unchanged packet
end -- not reached connection message
-- add packet to previous ones
previousPacket = previousPacket .. packet
-- find last newline (the search for a newline is "greedy")
sendThis, keepThis = string.match (previousPacket, "^(.*\n)([^\n]*)")
-- if no linefeed in line return nothing
if not sendThis then
return ""
end -- if
-- save stuff past the newline for next time
previousPacket = keepThis
-- send up to the last newline
return sendThis
end -- OnPluginPacketReceived
function OnPluginConnect ()
previousPacket = ""
buffer_packets = false
end -- OnPluginConnect
]]>
</script>
</muclient>
Basically it works like this:
- Take an incoming packet and add to the left-over packet from earlier
- Search the combined packet (old ones plus the new one) for the last newline
- If one found, send everything up to that newline to the client for processing
- If none found, send nothing to the client
- In any event, retain the excess bit at the end (which could be nothing if the newline was at the end)
There is still a test for the message "You have connected!" which indicates that you have moved past the login sequence of username/password. Edit that string to be something your MUD sends. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Alisa
(20 posts) Bio
|
| Date
| Reply #20 on Fri 11 Oct 2019 09:28 PM (UTC) |
| Message
| You have nooooo idea how much I can't wait to get back home so that I can test this out. Even if it doesn't solve the problem, you folks have done a tremendous amount of work to help me with this and I super appreciate it!
As for the connect message, it is actually something people say in chat on a fairly regular basis as a bit of a peculiar catchphrase. Will anything bad happen if someone says the line again after the plugin has already initialized for that session?
If so, I could always use the line it spits out stating when and where my last connection was from. I don't belieeeeeeve I've ever heard anyone use "Last connect was from" in normal conversation, although I suppose it could come up at some point if someone gets paranoid and quotes that line in chat when seeking help. | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #21 on Fri 11 Oct 2019 09:39 PM (UTC) Amended on Fri 11 Oct 2019 09:40 PM (UTC) by Nick Gammon
|
| Message
| Nothing bad will happen except you will see that message about "Packet buffering now active" again. You could always remove that, or ignore it.
Or you could change that function to be:
-- here when we log in
function we_connnected (name, line, wildcards)
if not buffer_packets then
ColourNote ("green", "", "Packet buffering now active")
end -- if
buffer_packets = true
end -- we_connnected
That way it only shows the message once per session. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #22 on Fri 11 Oct 2019 09:41 PM (UTC) |
| Message
| | I amended the later version (1.1) to have that test, so you only see that message once. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Alisa
(20 posts) Bio
|
| Date
| Reply #23 on Fri 11 Oct 2019 10:18 PM (UTC) |
| Message
| Using "Last connect was from" did not seem to be starting the plugin for whatever reason. I switched it out for the oft-repeated line I was concerned about and updated the plugin to reflect the change you made, with a green "Packet buffering now active" line greeting me at my next connect.
It actually seems to have somehow caused chaos, probably related to < and > marks in displayed text. Exit names on the game have their shortcuts displayed in those (such as "Out <O>") and of course their usage in the channel names, ie <General>.
If I sit in place and execute the 'look' command a few times in a row, the very first one will display properly but then things go nuts. The <> around the exit shortcut are stripped out, as are those around the channel name, and are inserted in very strange places instead. Quotation marks are randomly appearing prepended to new channel lines as well.
https://puu.sh/ErtKa/6900b39830.png is an example screenshot so that you can see exactly how it looks on my end. As you can see, "Local Exits" has a bunch of >>> jammed into it (probably from the prior 'look' results), the <> are missing from the exit shortcut and channel names, and there are strange double quotes showing up before some of the channel lines but not all.
As for that random > before the first channel line after the look command (where the exit name is displayed), that happens each time I see an exit shortcut. The first line sent after that will have that random > stuck in there but then they stop until I see <> somewhere again. | | Top |
|
| Posted by
| Alisa
(20 posts) Bio
|
| Date
| Reply #24 on Fri 11 Oct 2019 10:32 PM (UTC) |
| Message
| | It seems to also be stripping quotation marks from things! Both channel chatter and local room say. The double quotation marks prepended to lines seem to happen when the previous line had quotation marks stripped out of it, as they do not appear when the previous line was an emote without any quotation marks involved. | | Top |
|
| Posted by
| Alisa
(20 posts) Bio
|
| Date
| Reply #25 on Fri 11 Oct 2019 10:43 PM (UTC) Amended on Fri 11 Oct 2019 10:44 PM (UTC) by Alisa
|
| Message
| And one more tidbit! Apologies for this information trickle, I'm trying to provide anything which seems to be following a pattern.
Anywho, back to the quotation mark thing! It strips them out if they are present in a line, instead prepending the next line with each mark thusly removed. Interestingly, if I do something like @chan/recall that would result in a whole bunch of lines all at once, it will strip the quotation marks from the entire thing and then slap all of the missing ones to the start of the next new packet.
Or at least I think so. I tested it three times, with results that showed 6, 10, and then 8 quotation marks removed from each test, and their following packets each having 6, 10, and then 8 quotation marks prepended to them. Not the world's greatest sample size but it does seem to indicate a pattern to the seeming madness. | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #26 on Sat 12 Oct 2019 05:50 AM (UTC) |
| Message
| Right. What I would like you to do is disable the plugin (there is a button on the plugin list for that) and then capture, say, 20 packets of the sort that are causing trouble. Chat, etc.
Post them here. Using that I can reproduce exactly what you are receiving and debug the problem. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #27 on Sat 12 Oct 2019 05:51 AM (UTC) |
| Message
| | Which version did you use? The first one (1.0) or the second one (1.1). |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #28 on Sat 12 Oct 2019 09:14 AM (UTC) Amended on Sat 12 Oct 2019 09:15 AM (UTC) by Nick Gammon
|
| Message
| After extensive investigation (I could reproduce the problem) I have deduced that the MXP/Pueblo processing is interfering with the packet manipulation.
With the plugin installed (second version, 1.1) and with Pueblo off the artefacts of the weirdness at the start of the line goes away.
To briefly explain, when the MXP/Pueblo processing finds an entity (eg. < ) then it pretends it got "<" in a packet. This is then remembered in the code in the plugin, so that things like " in your packet are added to the "just received" packet stuff, and then appear at the start of the next line.
This looks like a bug in the interaction between the OnPluginPacketReceived and the MXP processing, however it has been around for a long time.
I suggest installing the second plugin, and disabling Pueblo. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #29 on Sat 12 Oct 2019 09:18 AM (UTC) Amended on Sat 12 Oct 2019 09:20 AM (UTC) by Nick Gammon
|
| Message
|
Quote:
... it will strip the quotation marks from the entire thing and then slap all of the missing ones to the start of the next new packet.
Pretty much what I would expect from the code. This is a bit kludgy but you are the first person to discover it (or perhaps, *I* am the first person to discover it, after writing the plugin).
To put that into context, MXP was implemented on 17th June 2001, and this is the first time this issue has arisen. :) |
- 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.
112,714 views.
This is page 2, subject is 3 pages long:
1
2 3
It is now over 60 days since the last post. This thread is closed.
Refresh page
top