Display of text is a bit dodgy

Posted by Larkin on Sat 25 Jun 2005 12:41 AM — 23 posts, 83,079 views.

Larkin Sat 25 Jun 2005 12:41 AM #0

I know that most people probably don't consider this a bug, if they see it happen at all, but to me it's a bit annoying. What happens is when I connect and receive the initial text (a couple system messages and my current room's description), I get no text update until something else happens in the game, whether it be me executing a command, someone talking, or whatever.

The other part of this bug affects both the output window and the log file. When I sign off, I don't get that last bit of text displayed. There should be a few lines of text confirming that I've successfully logged off, but it never shows. The log is missing even more than that (only a line or two), so I'm wondering what happened to the text and if it would be possible to have this changed to display more uniformly.

If it matters, I'm using the smooth scrolling option (but not the very smooth scrolling).

Thanks in advance.

Flannel USA Sat 25 Jun 2005 02:33 AM #1

Are you getting those packets (check in packet debug, next time it happens)?

Do you have any plugins that use OnPluginPacketReceived? or any other callbacks? anything like that?

Larkin Sat 25 Jun 2005 02:41 AM #2

I do have a couple of plugins that use OnPluginPacketReceived to check for prompts without newlines.

The packet debug shows that I receive the lines upon connection, though they are not displayed. It also shows, however, that text is not received when I disconnect. There should be at least a couple more lines before the connection is closed. It's entirely possible that they are products of two separate pieces of code, or that my plugins have done something to get in the way.

If I make a brand new world with no settings at all and login, I see the initial text. When I logoff, I still miss the last few lines.

Hope that helps narrow down the cause of my problems.

David Haley USA Sat 25 Jun 2005 02:47 AM #3

Does this happen with every MUD you connect to? It could be, at least for the final lines, an error server-side.

I'm not sure quite what you mean about not getting text updates after connecting until something happens. Isn't that, well, normal behavior?

Flannel USA Sat 25 Jun 2005 03:00 AM #4

Are the initial lines that you don't get not terminated by newlines? Are they all in the same packet? Whats the situation?

Larkin Sat 25 Jun 2005 11:55 AM #5

It happens with any MUD I connect to, which is only two, and they're both IRE MUDs.

Here is the initial debug packets I see that isn't displayed until I do something or something else happens in the game that causes more text to come through, thereby displaying the buffered text before it, also. (I hope this makes some sense.)

Incoming packet: 3 (538 bytes)

...Password corr   ff fc 01 50 61 73 73 77 6f 72 64 20 63 6f 72 72
ect. Welcome to    65 63 74 2e 20 57 65 6c 63 6f 6d 65 20 74 6f 20
Achaea...Your la   41 63 68 61 65 61 2e 0d 0a 59 6f 75 72 20 6c 61
st login was fro   73 74 20 6c 6f 67 69 6e 20 77 61 73 20 66 72 6f
m domain: 69-162   6d 20 64 6f 6d 61 69 6e 3a 20 36 39 2d 31 36 32
-62-103.stcgpa.a   2d 36 32 2d 31 30 33 2e 73 74 63 67 70 61 2e 61
delphia.net.....   64 65 6c 70 68 69 61 2e 6e 65 74 2e 0d 0a 0d 0a
Your moss tattoo   59 6f 75 72 20 6d 6f 73 73 20 74 61 74 74 6f 6f
 tingles slightl   20 74 69 6e 67 6c 65 73 20 73 6c 69 67 68 74 6c
y...Your boar ta   79 2e 0d 0a 59 6f 75 72 20 62 6f 61 72 20 74 61
ttoo tingles sli   74 74 6f 6f 20 74 69 6e 67 6c 65 73 20 73 6c 69
ghtly....[33mRoa   67 68 74 6c 79 2e 0d 0a 1b 5b 33 33 6d 52 6f 61
d past a Shastaa   64 20 70 61 73 74 20 61 20 53 68 61 73 74 61 61
n guard hut .[37   6e 20 67 75 61 72 64 20 68 75 74 20 1b 5b 33 37
m(road)....[36mA   6d 28 72 6f 61 64 29 2e 0d 0a 1b 5b 33 36 6d 41
n obsidian eye s   6e 20 6f 62 73 69 64 69 61 6e 20 65 79 65 20 73
igil is here..[3   69 67 69 6c 20 69 73 20 68 65 72 65 2e 1b 5b 33
7m.[36m...[37m.[   37 6d 1b 5b 33 36 6d 0d 0a 1b 5b 33 37 6d 1b 5b
1;34mYou see exi   31 3b 33 34 6d 59 6f 75 20 73 65 65 20 65 78 69
ts leading.[0;37   74 73 20 6c 65 61 64 69 6e 67 1b 5b 30 3b 33 37
m.[1;34m north (   6d 1b 5b 31 3b 33 34 6d 20 6e 6f 72 74 68 20 28
open door), east   6f 70 65 6e 20 64 6f 6f 72 29 2c 20 65 61 73 74
, south, and wes   2c 20 73 6f 75 74 68 2c 20 61 6e 64 20 77 65 73
t....[0;37m.[32m   74 2e 0d 0a 1b 5b 30 3b 33 37 6d 1b 5b 33 32 6d
3576h,.[37m.[32m   33 35 37 36 68 2c 1b 5b 33 37 6d 1b 5b 33 32 6d
 2820m,.[37m.[32   20 32 38 32 30 6d 2c 1b 5b 33 37 6d 1b 5b 33 32
m 15835e,.[37m.[   6d 20 31 35 38 33 35 65 2c 1b 5b 33 37 6d 1b 5b
32m 13000w.[37m    33 32 6d 20 31 33 30 30 30 77 1b 5b 33 37 6d 20
ex-...[32m3576h,   65 78 2d ff f9 1b 5b 33 32 6d 33 35 37 36 68 2c
.[37m.[32m 2820m   1b 5b 33 37 6d 1b 5b 33 32 6d 20 32 38 32 30 6d
,.[37m.[32m 1583   2c 1b 5b 33 37 6d 1b 5b 33 32 6d 20 31 35 38 33
5e,.[37m.[32m 13   35 65 2c 1b 5b 33 37 6d 1b 5b 33 32 6d 20 31 33
000w.[37m ex-...   30 30 30 77 1b 5b 33 37 6d 20 65 78 2d ff f9 ff
.......V..         fc 19 ff fc c8 ff fa 56 ff f0

Sent  packet: 7 (3 bytes)

...                ff fe 19

Sent  packet: 8 (3 bytes)

...                ff fe c8

On the left, I can see that the description of the room was sent to me, but it wasn't in the display window yet.

The text that doesn't get sent to me on disconnecting isn't in the display or in the debug packets, and it's not a server-side problem because it works in any other client that I try.

David Haley USA Sat 25 Jun 2005 06:47 PM #6

Seems that the server isn't sending an echo-on request, given that the echo-off is sent right before typing your password.

What bothers me in all of this is that empirical evidence shows that MUSHclient works for a whole lot of people, so something fishy is going on here. Have you tried connecting to another MUD?

Larkin Sat 25 Jun 2005 06:53 PM #7

As I said, I don't play any other MUD and this seems to have something to do with my world settings. I do recall seeing something about ignoring 'echo off' messages and never knew why I'd want that option. I'll see if that helps part of my problem, but the fact still remains that the trailing text on logoff isn't displayed.

Thanks for your help.

Flannel USA Sat 25 Jun 2005 07:09 PM #8

You shouldn't have to ignore echo off messages, the server should send a NOECHO after you send your password (which turns off HIDE YOUR INPUT). So the first bit is a server issue, or at least seems to be.

The last bit, I have a feeling that debug packets only happens after plugins are done dealing with them. Try disabiling your plugins and see if the problem still persists.

Larkin Sat 25 Jun 2005 07:38 PM #9

I removed all plugins, unchecked the Ignore Echo Off option, and when I connected the text was still hidden. Checking the Ignore Echo Off option seemed to take care of the first part of the problem, but I agree with you that I shouldn't have to use the option. I would find it difficult to believe that it could be the server, however, as other clients don't exhibit this same behavior.

Flannel USA Sat 25 Jun 2005 08:34 PM #10

Other clients probably ignore the spec that says that the client won't decide when to turn text back on. That's usually the case in this sort of thing, of course, I could be wrong, only way to know would be to see the whole initial login packets. Would you mind turning off your autologin, logging in by hand (with debug packets), and then going until the text shows, and posting that here? You'll obviously want to change your password to something else during this proccess (so we get the dummy password).

Does the lack of plugins fix the logoff problem?

David Haley USA Sat 25 Jun 2005 11:34 PM #11

I don't think you understand why I'm asking you to connect to another MUD. I hadn't forgotten that you said you didn't play anywhere else. That's not the point. I'm trying to narrow down the problem. As I said, empirical evidence goes to show that it's not a problem with MUSHclient. If you manage to connect to another server and everything works, then we know that something is wrong with the MUD you play on or your settings with it. If the problem occurs with another MUD, then it is likely that you have a bad configuration e.g. with plugins, but we have ruled out the server-side error.

Larkin Sun 26 Jun 2005 12:51 AM #12

I will work on getting a better set of debug packets for you to look at. It's quite possible that the autologin sequence is what causes my problem, too. We'll see if it looks any different at all.

The lack of plugins didn't change the text problem at logoff.

I understand that you want me to connect to another MUD to see differences, but I don't see how that is directly relevant to my particular situation. I'm not blaming MUSHclient for the problem on login, necessarily, but the logoff thing definitely seems to be something particular to this client.

Thanks again for your assistance, and I'll get back to you soon with more information.

David Haley USA Sun 26 Jun 2005 01:40 AM #13

Quote:
but the logoff thing definitely seems to be something particular to this client.

No, it definitely does not seem to be particular to MUSHclient, else other people would be having it. Connecting to other MUDs is relevant to your situation for the reason I explained: it narrows down the problem. If of course you'd rather fix your problem some other way, feel free to do so.

Larkin Sun 26 Jun 2005 02:21 AM #14

The logoff thing cannot be narrowed down, in my opinion. Disconnecting with any number of other clients works as expected and shows all of the text. With MUSHclient, I don't even see the text in debug packets, so obviously something has gone missing. It has nothing to do with my settings. I've asked others who use MUSHclient on these same MUDs and they say they just accepted the behavior and don't know how to fix it. So, not just me here.

Taking out the name and password from the Connecting commands makes the text appear, but entering my name and password by hand isn't as secure as I'd like. I use autologin because I want it to keep my password undisplayed without making a trigger (with my password in it) to omit the password.

Connecting to another MUD requires me to create another character, choose a password, go through the steps to ensure my character is saved long enough for me to make a few attempts at this. I tried Medievia and it not only requires me to get to level two to save my character, it confuses me as to how to even do so. I don't have time to mess with other MUDs, and if that's what it takes to get this problem solved, I'll live with it.

I apologize if I've offended your sensibilities, but I'm simply trying to report a problem and ask for a little help. I'm tired and I'm not going to mess with it any more for now. Thanks anyway.

Flannel USA Sun 26 Jun 2005 04:48 AM #15

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.

David Haley USA Sun 26 Jun 2005 07:12 AM #16

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.

Ked Russia Sun 26 Jun 2005 02:02 PM #17

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.

Ked Russia Sun 26 Jun 2005 02:51 PM #18

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.

Larkin Sun 26 Jun 2005 03:08 PM #19

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.

Flannel USA Sun 26 Jun 2005 05:55 PM #20

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.

Nick Gammon Australia Forum Administrator Mon 27 Jun 2005 07:51 AM #21

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.

Larkin Mon 27 Jun 2005 11:38 AM #22

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.