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 ➜ Bug reports ➜ Full lines received within a packet, Note(), and triggers
Full lines received within a packet, Note(), and triggers

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

Pages: 1  2  3  4 5  

Posted by Fiendish   USA  (2,535 posts)  Bio   Global Moderator
Date Reply #45 on Sun 15 May 2016 07:45 PM (UTC)
Message
Re-opening thread. (I don't like this automatic thread closing business)
https://github.com/fiendish/aardwolfclientpackage
Top
Posted by VBMeireles   Brazil  (47 posts)  Bio
Date Reply #46 on Sun 15 May 2016 07:56 PM (UTC)
Message
I'm currently using a Note() in my GMCP handler's OnPluginTelnetSubnegotiation() for developing purposes however some GMCP messages seem to be "waiting (?)" for something before they finally get Note()'d.

I've been pointed to this thread and from what I've read it seems DoAfterSpecial() is the proposed solution.

Does that mean there is currently no way at all to immediately echo all GMCP?
Vinícius
Top
Posted by Nick Gammon   Australia  (23,140 posts)  Bio   Forum Administrator
Date Reply #47 on Sun 15 May 2016 08:25 PM (UTC)
Message
They are waiting for the current line to be completed. The reason for deferring notes was that they could interfere with MUD output, or even convert an output line to a note line. For example, a GMCP note in the middle of an output line caused a note to be inserted, and thus the trigger match on the whole line would fail.

One technique would be to use a Notepad window if you are just trying to debug your GMCP. That won't have the limitations of deferred noting.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by VBMeireles   Brazil  (47 posts)  Bio
Date Reply #48 on Sun 15 May 2016 10:22 PM (UTC)

Amended on Mon 16 May 2016 12:23 AM (UTC) by VBMeireles

Message
1. Why is it that it only happens with some GMCP messages?

It doesn't seem to affect the room.info GMCPs that I receive when I enter a room. The Note()s from those get sent immediately.

However the Note()s for the room.info GMCPs that I receive when I fail to go in a direction do not show immediately.

Regardless of the answer to the question above, 2. is it only Note()s that get deferred or any functions after (or before) it?

3. Does it also mean that if I am to trigger the receiving of such GMCP (whose Note()s are getting delayed), the firing will also be delayed?
Vinícius
Top
Posted by Nick Gammon   Australia  (23,140 posts)  Bio   Forum Administrator
Date Reply #49 on Mon 16 May 2016 04:27 AM (UTC)
Message
Quote:

1. Why is it that it only happens with some GMCP messages?


Possibly they are immediately followed by a newline, see description below.

Quote:

2. is it only Note()s that get deferred or any functions after (or before) it?


During a plugin callback (eg. when processing a GMCP message) all Notes (and similar, like ColourNote, Tell, print) are put into a queue.

Other functions (which do not output to the output window) are not affected.

When a newline is received from the MUD (which activates trigger processing, etc.) then outstanding lines (queued lines) are output.


Quote:

3. Does it also mean that if I am to trigger the receiving of such GMCP (whose Note()s are getting delayed), the firing will also be delayed?


I'm not sure what you mean by "trigger the receiving of such ...". The messages arrive from the MUD, how would you trigger them?
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Fiendish   USA  (2,535 posts)  Bio   Global Moderator
Date Reply #50 on Mon 16 May 2016 09:10 AM (UTC)

Amended on Mon 16 May 2016 09:50 AM (UTC) by Fiendish

Message
Nick Gammon said:

For example, a GMCP note in the middle of an output line caused a note to be inserted, and thus the trigger match on the whole line would fail.

Handling this alleged case (that probably never actually happens in the first place) by always buffering Notes during packet handling has created all kinds of display problems for me recently, and the current workaround using DoAfterSpecial instead of Note is very problematic at best because it completely breaks output predictability. You no longer have any good way of controlling where and when output actually shows up.

The original problem is very simple that the line handler assumes that GMCP in the middle of an output line is good and proper, and now a new problem is that it's seen as ok to arbitrarily and indefinitely block output until some unrelated packet arrives.

The right fix would be either:
1) to say "actually, no it isn't ok to wedge GMCP in the middle of an output line, and in fact this probably never actually happens because it would be a rather silly thing to do" and thus also terminate display lines at the start of any GMCP.
or
2) If and only if GMCP is received in the middle of an output line, then defer handling of the GMCP data until after the full line is completed. Do NOT arbitrarily defer handling of any and all Notes that may occur during packet handling until receipt of some subsequent and 99.999% of the time completely unrelated display line because:
a) Notes are in fact not the only valid way to generate output and this again leads to ordering problems.
b) Most GMCP packets are NOT received in the middle of output lines(!!!) and can in fact be received with no display lines forthcoming from the server at all.

Further, I imagine that if the first function were to use Simulate instead of Note then the problem would also never occur.
I don't really get why this is assumed to be fine:
Quote:
What your Note in the GMCP callback has done is...switched [a completely unrelated line] to a Note line.


[EDIT]slightly edited
https://github.com/fiendish/aardwolfclientpackage
Top
Posted by VBMeireles   Brazil  (47 posts)  Bio
Date Reply #51 on Mon 16 May 2016 09:40 AM (UTC)

Amended on Mon 16 May 2016 09:44 AM (UTC) by VBMeireles

Message
Fiendish said:

You no longer have any good way of controlling where and when output actually shows up.


That's the whole problem if I want "on-the-fly GMCP visualization" triggers (in the output screen). Sometimes the very thing I want is to precise when (or where) the GMCP is in relation to the rest of the MUD output. In my case, for example, I'd like the receiving of specific GMCP to turn on triggers that will process following output. Precision concerning the order and exact moment of stuff received is very valuable in this case.

Fiendish said:

[...] the line handler assumes that GMCP in the middle of an output line is ok [...] no it isn\'t [...]


I lack deep understanding of Telnet protocols or GMCP, but I must say this seems/sounds right to me.
Vinícius
Top
Posted by VBMeireles   Brazil  (47 posts)  Bio
Date Reply #52 on Mon 16 May 2016 09:43 AM (UTC)
Message
Fiendish said:

(..) end lines at GMCP as well as newline symbols.


Is that something I could "fix" on my end in case it's not a change Nick would like to make to the client?

If yes, how?
Vinícius
Top
Posted by Fiendish   USA  (2,535 posts)  Bio   Global Moderator
Date Reply #53 on Mon 16 May 2016 09:47 AM (UTC)

Amended on Mon 16 May 2016 11:45 AM (UTC) by Fiendish

Message
VBMeireles said:

Fiendish said:

(..) end lines at GMCP as well as newline symbols.


Is that something I could \"fix\" on my end in case it\'s not a change Nick would like to make to the client?

If yes, how?

That's an interesting question. I don't know.

I suppose we could try something like

Simulate("\r\n")

following handling of the GMCP combined with activation of a temporary trigger which removes any immediately subsequent blank line and then disables itself?

[EDIT]edited and then unedited and redited
https://github.com/fiendish/aardwolfclientpackage
Top
Posted by Fiendish   USA  (2,535 posts)  Bio   Global Moderator
Date Reply #54 on Mon 16 May 2016 12:26 PM (UTC)

Amended on Mon 16 May 2016 12:44 PM (UTC) by Fiendish

Message
Quote:
I suppose we could try something like...

Note: This will completely eliminate the acceptability of actually receiving GMCP in the middle of an output line, which Nick seems over the years hell-bent on preserving above all else, and will split that line in half.

Aardwolf sanely never splits output lines like that, so _we_ should be fine with this. Of course always introducing a blank line that we then always have to remove is a bit...unfortunate.

For the proper general solution, Manacle's proposed GMCP plugin change in http://mushclient.com/forum/?id=12915&reply=28#reply28 seems like it would have approximately implemented my 2nd suggestion (by combining gmcp message deferral buffering with both timed and forced consumption of that buffer, you mimic only deferring when reasonable), which I think would have been a far preferable solution because it would then also mostly accomodate this insane line-splitting (except possibly at packet boundaries with very high network delays, which is part of why line-splitting is just insane). Though it of course no longer works past MUSHclient 4.98 because it doesn't stack on top of the "always defer notes forever until a new line arrives" change. :\
https://github.com/fiendish/aardwolfclientpackage
Top
Posted by Nick Gammon   Australia  (23,140 posts)  Bio   Forum Administrator
Date Reply #55 on Tue 17 May 2016 04:48 AM (UTC)
Message
The only reason I did this in the first place was that there was indeed a problem to solve. I didn't add all this extra work for my amusement.

We were having a problem with plugins being called during the receipt of an output line, which caused triggers to not fire.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Fiendish   USA  (2,535 posts)  Bio   Global Moderator
Date Reply #56 on Wed 18 May 2016 08:32 AM (UTC)

Amended on Wed 18 May 2016 08:35 AM (UTC) by Fiendish

Message
Nick Gammon said:

The only reason I did this in the first place was that there was indeed a problem to solve. I didn\'t add all this extra work for my amusement.

We were having a problem with plugins being called during the receipt of an output line, which caused triggers to not fire.

No doubt. And I want to take this moment to say two things to you.

1) Your continued effort and attention to this project is both inspiring and pleasant. I'm very glad that you continue to work on it, and I wish that building in Windows were simpler for me to do so that I could send more code to you.
2) The prior resolution of this thread unfortunately broke a lot of my existing plugin code. I'm definitely a lot less bothered by this now that Aardwolf will have a seemingly reliable workaround* ** (thanks for jogging my brain VBMeireles!)
3) I'm still worried that a solution found in a discussion buried in a forum thread leaves breakage for anyone who doesn't find the thread.

Well obviously I can't count.

* - 

+<triggers>
+<trigger
+   enabled="n"
+   name="strip_blank"
+   match="^$"
+   regexp="y"
+   omit_from_output="y"
+   send_to="12"
+   sequence="100"
+><send>
+EnableTrigger("strip_blank", false)
+</send>
+</trigger>
+</triggers>

...

       BroadcastPlugin(1,message)
+      EnableTrigger("strip_blank", true)
+      Simulate("\r\n")


** - that will unfortunately break on any server insane enough to wedge GMCP into the middle of output lines
https://github.com/fiendish/aardwolfclientpackage
Top
Posted by Nick Gammon   Australia  (23,140 posts)  Bio   Forum Administrator
Date Reply #57 on Fri 20 May 2016 06:02 AM (UTC)
Message
This might help:

https://github.com/nickgammon/mushclient/commit/200c691

That turns off the deferred outputting of lines, when doing a plugin callback, if the current line length is zero. That is, we can assume that an existing line won't be corrupted.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,140 posts)  Bio   Forum Administrator
Date Reply #58 on Fri 20 May 2016 06:04 AM (UTC)
Message
Fiendish said:

** - that will unfortunately break on any server insane enough to wedge GMCP into the middle of output lines


Out-of-band messages should be able to be sent at any time, that's the whole point of them. Well, maybe not the whole point, but they should be considered separately from in-band messages.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,140 posts)  Bio   Forum Administrator
Date Reply #59 on Fri 20 May 2016 06:05 AM (UTC)
Message
Fiendish said:

1) Your continued effort and attention to this project is both inspiring and pleasant. I\'m very glad that you continue to work on it, and I wish that building in Windows were simpler for me to do so that I could send more code to you.


Thanks! What was the problem with building in Windows? I thought the latest Visual Studio supported MFC? But there was another issue, wasn't there?
- 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.

152,973 views.

This is page 4, subject is 5 pages long:  [Previous page]  1  2  3  4 5  [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.

Home