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 ➜ Display of text is a bit dodgy
Display of text is a bit dodgy

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

Pages: 1  2 

Posted by Flannel   USA  (1,230 posts)  Bio
Date Reply #15 on Sun 26 Jun 2005 04:48 AM (UTC)

Amended on Sun 26 Jun 2005 04:50 AM (UTC) by Flannel

Message
We're simply trying to figure out everything regarding your particular problem, and since we can't sit behind you while it happens, and then try our own things on our own, we require you to supply us with the exact conditions, so we can replicate them on our own clients.

For instance, would it be possible to get the stuff sent at 'logout' (the packets, not just the text). Which I suppose would require another client to send them to you (I have no idea what other clients allow you to look at the packets).

Mushclient SHOULD honor the echo off message (and not display your text when prompted for a password), at least, I believe it does, at the moment I have no way of verifying, but I agree, it is not a valid solution. You could however, write a small plugin to insert the NO ECHO message (which ends the HIDE YOUR INPUT message, of course, the server might be sending another message, only that login packet debug would let us know for sure) into the text before the "Password Correct", which would be where it should be.

And yes, the logout problem may infact be another case of mushclient following the spec, and other clients not, or it may be indeed a bug, only knowing what is actually being sent will allow us to determine that.
~Flannel

Messiah of Rose
Eternity's Trials.

Clones are people two.
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #16 on Sun 26 Jun 2005 07:12 AM (UTC)
Message
My MUD sends echo off and echo on at login and MUSHclient has no problem dealing with that. I suspect that as is often the case, Nick has correctly implemented the standard where others have not and so MUSHclient appears to be 'buggy', when in fact, it is doing exactly what it should be doing.

So I suspect something is up server-side, or client-config side. Of course, without knowing what happens on connection to other MUDs, it's much harder to narrow down the problem. If the echo on/off sequence works on another MUD correctly, then we can be fairly certain that the IRE MUDs are not behaving quite right. I admit that I'd find that surprising given the scope of their operation. But, I know for a fact that MUSHclient works with a correct sequence of echo on/off requests.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Ked   Russia  (524 posts)  Bio
Date Reply #17 on Sun 26 Jun 2005 02:02 PM (UTC)
Message
I can't help with the "no text at logon" problem, but after careful examination have found the source of the second problem - the "no disconnect message" one. It appears that MCCP is responsible for that, and the packets containing the message are either never sent to Mushclient, or Mushclient's MCCP decoder gobbles them up. Seeing as Mushclient is not the only client with this issue (MudMagic at least, and I believe I heard the same complaints from Zmud users), I am inclined to believe that the server simply forgets to send the message when MCCP is active.
Top
Posted by Ked   Russia  (524 posts)  Bio
Date Reply #18 on Sun 26 Jun 2005 02:51 PM (UTC)

Amended on Sun 26 Jun 2005 03:12 PM (UTC) by Ked

Message
Also the first problem... Larkin's output looks pretty much the same as mine, but I've never had this issue before, and wasn't able to reproduce it no matter how hard I tried.

Unless I am missing something however, why would the echo codes cause something like that? The server sends IAC WILL ECHO (FF FB 01) and IAC WON'T ECHO (FF FC 01) at the password prompt. Those codes shouldn't effect whether the client echoes the input locally or not - they control whether the server will echo input back to the client. At least that is my understanding. In any case, having Mushclient's echo option turned on is in no way effected by those codes - the password is still echoed in output. So I presume that you are talking about some other kind of NOECHO, which is actually never sent by the server in this case.

EDIT: Okay, googling for "Telnet NOECHO" gives RFC318 which defines the ECHO (132), NOECHO (131) and Hide Your Input (133) codes. Achaea never sends any of those codes during the login sequence, and even if it did, from their descriptions it looks like HYI with no NOECHO following it should only result in local input echo remaining suppressed after the password is entered, not in MUD output not getting displayed until some more input is received.

EDIT2: I never read carefully enough it seems... From one of Larkin's earlier posts I gather that the problem is definitely with one of the scripts. It's not a client or server problem, since if it was, I'd be getting it also. And the fact that a "clean" world doesn't have this problem leaves no other choice but to presume that the problem is caused by some script. What it is, is hard to say. Seems like about the only sources of trouble could be OnPluginPartialLine or OnPluginPacketReceived. But to figure out what exactly it is, I'd uninstall each and every plugin one by one, reconnecting each time to see whether the problem went away. Once the troublemaker is found, the normal debugging process is in order. I'd love to see what caused this myself. And this is definitely not the "Ignore Echo" option that is solving the problem.
Top
Posted by Larkin   (278 posts)  Bio
Date Reply #19 on Sun 26 Jun 2005 03:08 PM (UTC)
Message
Very good call on the MCCP thing, Ked! I thought I was using MCCP in zMUD, but when I checked, it turns out I was wrong. Enabling it and disconnecting caused the logoff text to be skipped. Now, to figure out of it's IRE or MCCP that's at fault here (though I might lean to the former more than the latter).

If I alter my settings a bit, I'm able to work around the login text problem, so it may just have been that I was doing something I shouldn't have been, though I still am not sure what that is, since it even seems to be somewhat random (meaning that I hadn't changed settings and signed on/off and the text was shown one time and no another).

For now, I'll consider this fixed, but I'm still curious to know exactly what causes the problem in both instances.
Top
Posted by Flannel   USA  (1,230 posts)  Bio
Date Reply #20 on Sun 26 Jun 2005 05:55 PM (UTC)

Amended on Sun 26 Jun 2005 06:07 PM (UTC) by Flannel

Message
Which is why we need a copy of the log. On both ends (login and logout) if possible (although the MCCP thing could prove to be a problem).

What plugins DO you have that deal with packets? PartialLine only CHECKs the line, you can't insert/edit anything, so it has to be packets, or something omitting them entirely (onPluginLineRecieved not returning true), either way, we need details (I feel like a broken record) to track this puppy down. Or we could speculate until we're blue in the face, and still never come up with anything concrete.

And for another RFC about echoing, this could be it (although apparently Ked says nothing is sent, at least, purposefully, but that doesn't mean they can't be tweaked to reflect this):
http://www.faqs.org/rfcs/rfc857.html

All the client needs to receive is a IAC DONT ECHO. But actually it appears that the default for both ends is not to echo.
~Flannel

Messiah of Rose
Eternity's Trials.

Clones are people two.
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #21 on Mon 27 Jun 2005 07:51 AM (UTC)
Message
I am guessing from this that the final messages are being "batched up" in a MCCP packet. Effectively there may not be enough data for the decompressor to process.

I suggest that the server, just before disconnecting, should be sending a "MCCP shutdown" sequence which effectively terminates the MCCP session, and would cause the decompressor to wrap up also. The absence of this, when using MCCP, would probably account for the behaviour you are seeing.

Try turning off the MCCP decompression (in MUSHclient) and see if the problem goes away.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Larkin   (278 posts)  Bio
Date Reply #22 on Mon 27 Jun 2005 11:38 AM (UTC)
Message
Yes, the problem with the logoff text does go away when I disable compression. I thought, for some reason, that the setting would be in the world file as something like 'Enable MCCP' and instead found 'Disable compression.' I hadn't realized it would be on by default and so I wasn't thinking this could have been the cause.
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.

79,042 views.

This is page 2, subject is 2 pages long:  [Previous page]  1  2 

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