Register forum user name Search FAQ

Gammon Forum

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.

Template:saveplugin=Buffer_Lines To save and install the Buffer_Lines plugin do this:
  1. Copy between the lines below (to the Clipboard)
  2. Open a text editor (such as Notepad) and paste the plugin into it
  3. Save to disk on your PC, preferably in your plugins directory, as Buffer_Lines.xml
  4. Go to the MUSHclient File menu -> Plugins
  5. Click "Add"
  6. Choose the file Buffer_Lines.xml (which you just saved in step 3) as a plugin
  7. 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.


Template:saveplugin=Buffer_Lines To save and install the Buffer_Lines plugin do this:
  1. Copy between the lines below (to the Clipboard)
  2. Open a text editor (such as Notepad) and paste the plugin into it
  3. Save to disk on your PC, preferably in your plugins directory, as Buffer_Lines.xml
  4. Go to the MUSHclient File menu -> Plugins
  5. Click "Add"
  6. Choose the file Buffer_Lines.xml (which you just saved in step 3) as a plugin
  7. 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. &lt; ) then it pretends it got "<" in a packet. This is then remembered in the code in the plugin, so that things like &quot; 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:  [Previous page]  1  2 3  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum


[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.