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, 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.
 Entire forum ➜ MUSHclient ➜ General ➜ Possible Bug with OnPluginTelnetSubnegotiation
Possible Bug with OnPluginTelnetSubnegotiation

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

Posted by Candido   USA  (78 posts)  Bio
Date Sun 12 Sep 2010 09:43 AM (UTC)
Message
This problem will probably be devilishly hard to figure out, so I apologize in advance.

I made a plugin to handle the GMCP subnegotiations IRE is putting out these days, and decided that instead of parsing OnPluginPacketReceived, I'd just simplify things and use the new OnPluginTelnetSubnegotiation. Works great and saved me a lot of trouble, except for one thing.

From what I can see, this is what is going on. Anytime you generate a Note, command echo, or even error message from within OnPluginTelnetSubnegotiation, the very next line output by the MUD, no matter what it is, will fail to match any trigger.

Now at this point it probably looks like I'm completely misinterpreting things. No doubt it's that out of band info behind the plugin call that's somehow messing things up, right? As far as I can see, that's not the case.

Here is the experiment I did. First, I created a simple trigger that just does a Note saying it matched. Now GMCP has a nice, simple thing where you can send it "\255\250\201 Core.Ping \255\240" and it'll send back the same (that's IAC SB GMCP and IAC SE wrapping it; just a standard subnegotiation). The nice thing is, OnPluginTelnetSubnegotiation doesn't activate until I receive an IAC GA, and the pinging alone won't generate that, so I can do things in between for my tests.

In the first case, I just set up OnPluginTelnetSubnegotiation to do a Note, sent the ping subnegotiation, and then generated the text for my simple trigger with the Test Trigger feature. As expected, it failed to match, and the colour from the Note bled onto it (another symptom I forgot to mention earlier). The same happened when replacing the Note with a command, as the command echo has the same effect.

In the second case, I let OnPluginTelnetSubnegotiation be called, but make no visible output to the world. I sent the ping, manually generated the very same Note I had OnPluginTelnetSubnegotiation do last time, and then generated the trigger text with test trigger. The trigger matched. Same result when I manually generate a command echo in between.

In both cases the out of band info was present, but only when the Note is generated by OnPluginTelnetSubnegotiation does the problem occur. This leads me to believe it's OnPluginTelnetSubnegotation itself that's bugged. Especially interesting (and weird) is that the problem Note can be anywhere, so long as it originates with OnPluginTelnetSubnegotiation. For example, I can make OnPluginTelnetSubnegotiation Execute an alias in even my world that then does a Note, or even have that alias call a script function that does a Note, and it'll still happen. But if I use the very same alias to create the same Note in the same place manually, it doesn't happen!

Anyway, thanks for reading all that. I have to say though, I'm surprised nobody's brought this up already as it's a pretty big issue.
Top
Posted by Nick Gammon   Australia  (23,046 posts)  Bio   Forum Administrator
Date Reply #1 on Sun 12 Sep 2010 11:27 AM (UTC)
Message
Candido said:

Anytime you generate a Note, command echo, or even error message from within OnPluginTelnetSubnegotiation, the very next line output by the MUD, no matter what it is, will fail to match any trigger.


My initial reaction to this is, a note in that situation is changing the output buffer, so triggers won't match.

You aren't really supposed to Note from within telnet subnegotiation because it is out-of-band (the same applies to noting when getting MXP sequences).

The trigger matching waits for a newline, then works backwards through the output buffer to assemble the line that it just received (which could be multiple lines because some may not have newlines). However that working backwards stops at a note line (or ColourNote or whatever).

So say you got:


Hello IAC SB 201 blah blah IAC SE world


That works OK because the telnet stuff is stripped out.

But if you change the output by noting then you get something like:


Hello 
<your note here>
 world


Now the trigger won't match "Hello world" because one line has "Hello" on it, and the other has " world" on it.

You are better of putting this stuff to a miniwindow or a notepad window (I assume this is debugging stuff). I did one recently, eg.

http://www.gammon.com.au/forum/bbshowpost.php?id=10515

The idea of stuffing output into the output window when out-of-band data arrives is fundamentally flawed anyway, because by its nature, it might arrive in the middle of a line of text. So even if the trigger fired, you are still splitting up lines from the MUD.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Candido   USA  (78 posts)  Bio
Date Reply #2 on Sun 12 Sep 2010 08:27 PM (UTC)
Message
Alright, I gotcha, though a bit confused since in my test, at least, the situation was more like...

IAC SB 201 bla bla IAC SE Hello world

Unless, the lack of newline between the subnegotiation and output makes Mushclient interpret the Note and output as being on the same line (even though they appear as different lines in output)?

Either way, it's clearly not working for me, so I'll be taking it on faith and doing only processing/calibration stuff in OnPluginTelnetSubnegotiation, setting flags to do whatever outputs I need to do on a subsequent line (I was using it to make room info 'stamps', so the miniwindow won't work for me).
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #3 on Sun 12 Sep 2010 09:10 PM (UTC)
Message
You could try using OnPluginTick to do the Notes, which is called something like 40 times a second(?). Basically, you'd keep a queue of things you want to Note, and add to it in OnPluginTelnetSubnegotiation. Whenever OnPluginTick() is called, it would Note() the contents of that list and clear the list.

[EDIT] By the way, there is a GMCP plugin that already exists, even if it might be a little rough around the edges. http://github.com/druuimai/gmcp.plugin
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Nick Gammon   Australia  (23,046 posts)  Bio   Forum Administrator
Date Reply #4 on Sun 12 Sep 2010 10:31 PM (UTC)
Message
Candido said:

Alright, I gotcha, though a bit confused since in my test, at least, the situation was more like...

IAC SB 201 bla bla IAC SE Hello world

Unless, the lack of newline between the subnegotiation and output makes Mushclient interpret the Note and output as being on the same line (even though they appear as different lines in output)?


Well it shouldn't. But I would like to see a packet debug to clarify if "more like" is "exactly like". Once again though, I think treating telnet stuff as something that can be merged into output from the MUD is asking for trouble. For all you know, later on they may decide to move the telnet stuff into half-way along the line (eg. after the room description but before the exits).

My vision, personally, was that the telnet codes might update a mapper, or refresh a status bar, or be written to a "room description" box. Not simply supplement normal MUD output. Thus the issue of exactly where it appears in the output stream, compared to the normal viewable text, is not relevant.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #5 on Mon 13 Sep 2010 05:42 AM (UTC)
Message
Quote:
My vision, personally, was that the telnet codes might update a mapper, or refresh a status bar, or be written to a "room description" box. Not simply supplement normal MUD output. Thus the issue of exactly where it appears in the output stream, compared to the normal viewable text, is not relevant.

Either that, or the sequences be strictly "atomic" with respect to the rest of what's being sent. That is, if for some reason the MUD is sending structured data for rendering to the main channel, it should be very clearly demarcated from existing lines and not sent in the middle of lines.

I agree with Nick that it's probably a little weird to send something meant for the main channel on something other than the main channel. The only reason I can see for this is if you believe that the client might do some kind of additional processing based on the structured data, and therefore it would not be appropriate to send something pre-rendered.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
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.

21,807 views.

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