why mushclient 4.81 block the output message? lost package??

Posted by Andos on Wed 25 Apr 2012 05:02 AM — 26 posts, 86,444 views.

#0
I'd upgraded the mushclient to 4.81, it works good.
But occasionally, the output window blocked, can't
receive the msg from mud. I'd check that the connection
is active. any input command can't receive echo message
from mud. And it will be good in a few minutes.
1. I haven't check the 'omit from output' option, and
in general, it works well.
2. The network is good, i can't see any message in output window when i send a command such as "hi". but another char in the same room can see the action.

what's wrong?

thank you..

Australia Forum Administrator #1
This sounds vaguely familiar. What operating system are you using?
#2
win 7 enterprise, x64
Australia Forum Administrator #3
Template:summary

Please provide a summary of your world configuration:

  • Either use the scripting Immediate window (Ctrl+I) to execute: Debug ("summary")

    or

  • Install the Summary plugin (see "Summary" feature) and type "summary"

Then copy the resulting information from the output window, and paste into a Forum message.

You need version 4.55 onwards of MUSHclient to do this.

#4
Andos said:

2. The network is good, i can't see any message in output window when i send a command such as "hi". but another char in the same room can see the action.

what's wrong?

thank you..


I have this problem too, but I didn't suspect the client. Do you have to disconnect/reconnect to get it to work again? I have to do this a couple times a night.
#5

-------------- MUSHclient summary --------------

MUSHclient version: 4.81
Compiled: Jan  3 2012.
Time now: 星期四, 四月 26, 2012, 8:13 下午
Client running for:  0d 01h 39m 10s
World opened for:    0d 00h 08m 33s
World connected for: 0d 00h 08m 33s
Operating system: Windows 7
Libraries: Lua 5.1.4, PCRE 8.21, PNG 1.5.7, SQLite3 3.7.9, Zlib 1.2.5
World name: 'killer_cdcd', ID: 7bf6bc1ce230910cf8600694
-- Scripting --
Script language: Lua, enabled: yes
Scripting active: yes
Script file: G:\Program Files (x86)\MUSHclient\worlds\tsrj.lua
Lua sandbox is 127 characters, DLL loading allowed: yes
Scripting prefix: '/'. External editor in use: NO.
Scripting for: 1.672795 seconds.
-- Triggers, aliases, timers, variables --
** Triggers: 32 in world file, triggers enabled: yes. [Triggers]
   25 enabled, 32 regexp, 446330 attempts, 5691 matched, 0.206091 seconds.
** Aliases: 11 in world file, aliases enabled: yes. [Aliases]
   11 enabled, 5 regexp, 15289 attempts, 122 matched, 0.003958 seconds.
** Timers: 2 in world file, timers enabled: yes. [Timers]
   2 enabled, 51 fired.
   Timers checked every 0.1 seconds.
** Variables: 23. [Variables]
-- MCCP --
MCCP not active.
-- Plugins (Processing order) --
** Plugins: 0 loaded, 0 enabled.
-- Comms --
Connect phase: 8 (Open). NAWS wanted: NO
Received: 1169960 bytes (1142 Kb)
Sent: 67612 bytes (66 Kb)
Received 3064 packets, sent 3513 packets.
Total lines received: 21935
This connection: Sent 3499 lines, received 22313 lines.
Telnet (IAC) received: DO: 2, DONT: 0, WILL: 1, WONT: 1, SB: 1 [Telnet]
-- MXP --
MXP active: NO, Pueblo mode: NO, Activated: On command
MXP tags received: 0
MXP entities received: 0
MXP errors: 0
-- Commands --
Commands in command history: 0
Speed walking enabled: NO. Speed walking prefix: #
Command stacking enabled: yes. Command stack character: ';'
Accelerators defined: 0
-- Miniwindows --
** Miniwindows: 0 loaded, 0 shown.
-- Output window --
Output pixels: width 1259, height: 559, font width: 7, font height: 15
               can show 179 characters, wrapping at column 180, height 37 lines.
Output buffer: 4953 of 5000 lines.
-- Miscellaneous --
Logging: NO, tracing: NO
** SQLite3 databases: 0
Sound buffers in use: 0

---------------------- End summary ----------------------
#6
Gesslar said:

Andos said:

2. The network is good, i can't see any message in output window when i send a command such as "hi". but another char in the same room can see the action.

what's wrong?

thank you..


I have this problem too, but I didn't suspect the client. Do you have to disconnect/reconnect to get it to work again? I have to do this a couple times a night.


Yes, disconnect and reconnect will get it to work again. or wait a minute, it will work again too.
#7
Through observation, I found that output window show part of a line when blocking. Usually a few minutes, will continue to show remaining messages. Basically can eliminate network reason for the delay. The commands can send to server during blocking.
#8
Gesslar said:

Andos said:

2. The network is good, i can't see any message in output window when i send a command such as "hi". but another char in the same room can see the action.

what's wrong?

thank you..


I have this problem too, but I didn't suspect the client. Do you have to disconnect/reconnect to get it to work again? I have to do this a couple times a night.


I suspect the client because it's not caused by the lag of server, and the connection is active too.
Just as you said, I have to do this a coule times a night too.
But I haven't meet the same problem when I use other client such as zmud, ytin.
Australia Forum Administrator #9
Are you using UTF-8?

Maybe some bad UTF8 sequences are causing lines not to be shown.
USA Global Moderator #10
Gesslar and Andos, what muds do you connect to where you have this problem? I'd like to try connecting to them.
Amended on Mon 30 Apr 2012 01:06 PM by Fiendish
#11
Nick Gammon said:

Are you using UTF-8?
Maybe some bad UTF8 sequences are causing lines not to be shown.

yes, I'm playing chinese mud which is gb code.
but the left char will display after a few minutes.


Fiendish said:

Gesslar and Andos, what muds do you connect to where you have this problem? I'd like to try connecting to them.

You may try dx.mudol.cn 7777 or 61.164.87.153 7777
:), welcome to tsrj..
USA Global Moderator #12
Andos said:

Nick Gammon said:

Are you using UTF-8?
Maybe some bad UTF8 sequences are causing lines not to be shown.

yes, I'm playing chinese mud which is gb code.
but the left char will display after a few minutes.

My understanding is that GB is not UTF8, so you should not have the UTF8 output box checked. I suspect that this is not your problem, though, as you would see nothing useful with this set incorrectly.

I am trying to connect now. I don't know if I'll be able to see anything but it's worth trying.
Amended on Wed 02 May 2012 04:46 AM by Fiendish
#13
Fiendish said:

My understanding is that GB is not UTF8, so you should not have the UTF8 output box checked. I suspect that this is not your problem, though, as you would see nothing useful with this set incorrectly.

I am trying to connect now. I don't know if I'll be able to see anything but it's worth trying.


I haven't checked the UTF8 output box.
And it seems ok after I use the mcclient.
USA Global Moderator #14
mcclient?
#15
Fiendish said:

mcclient?


You may refer to http://www.sined.co.uk/sined/general/mccp.htm for detail
USA Global Moderator #16
Interesting. Are you saying that the problem happens if using MUSHclient's internal MCCP handling but does not happen if connecting through this other MCCP proxy program?
#17
Fiendish said:

Interesting. Are you saying that the problem happens if using MUSHclient's internal MCCP handling but does not happen if connecting through this other MCCP proxy program?


MUSHClient's internal MCCP is not active because my mud does not support the MCCP.
Mcclient works well even when the MCCP is not supported by the server.
BTW, it hasn't happened since using mcclient.
USA Global Moderator #18
What's the point of using mcclient if there's no mccp?
#19
Fiendish said:

What's the point of using mcclient if there's no mccp?

It just dispatch the message when there's no mccp.
USA Global Moderator #20
Then I don't think I can agree with your statement earlier
Quote:
Basically can eliminate network reason for the delay.

I don't think you can. It seems to me like you're describing a server that has delays sending messages sometimes and that circumstance only makes it look like mcclient works differently.

I guess I would try to use a program like WireShark to verify that the bits coming into mcclient are the same bits coming out of it and into MUSHclient. I see no reason why using it would alter MUSHclient's behavior if it's not doing anything.
#21
Fiendish said:

Then I don't think I can agree with your statement earlier
Quote:
Basically can eliminate network reason for the delay.

I don't think you can. It seems to me like you're describing a server that has delays sending messages sometimes and that circumstance only makes it look like mcclient works differently.

I guess I would try to use a program like WireShark to verify that the bits coming into mcclient are the same bits coming out of it and into MUSHclient. I see no reason why using it would alter MUSHclient's behavior if it's not doing anything.


I don't exactly know whether is server delayed. But I realized the fact is that the other char in the same room could see the response when the blocking char do some action such as say hi.The blocking char can't see response when he send a command such as hi, and in the same time, another char in the same room can see the action.
USA Global Moderator #22
Well...
Any time you send a command there are three data transfers.
1) From you to the server.
2) From the server back to you.
3) From the server to everyone else.

Since (2) and (3) are different activities in the server I don't see why one could not easily work even if the other is broken. Just as easily the situation could be reversed. What would you say if you sent a command and you saw the output immediately but someone else in the room did not see it for 30 seconds? You would say the other person is lagging or something, right? Or it could be a bug in the server or some other problem entirely. That is why I don't think you can automatically say that there is no network or server problem just because someone else saw your commands.

Now you say that mcclient does not do anything, just acts as passthrough, for this data. If it doesn't do anything, how can it make the problem go away?
Amended on Mon 07 May 2012 01:00 AM by Fiendish
#23
Thank you for your reply.


Fiendish said:

What would you say if you sent a command and you saw the output immediately but someone else in the room did not see it for 30 seconds? You would say the other person is lagging or something, right? Or it could be a bug in the server or some other problem entirely. That is why I don't think you can automatically say that there is no network or server problem just because someone else saw your commands.

The two char is in my two world of the same mushclient process. So I guest that it's not caused by the network delay.
What I happened is that one char send command, but can't see the echo. Another char in the same room can see the echo. The two char are in the same muchclient process.

Fiendish said:

Now you say that mcclient does not do anything, just acts as passthrough, for this data. If it doesn't do anything, how can it make the problem go away?

Sorry, I mean that mcclient does not compress or decompress in my case. Mcclient may collect the data from server and send to mushclient line by line. and it means mushclient may has bug when recieve parts of lines, right?
It block the msg for a few munites, which is obviously out of the network delay time.

I hope that mushclient will be better and better. And it's a good chance to catch the bug.
Australia Forum Administrator #24
Can you try turning compression off?
USA Global Moderator #25
Andos said:

The two char is in my two world of the same mushclient process. So I guest that it's not caused by the network delay.
Ah, I see. I didn't realize that detail. I think it could still be a bug with the server sending differently to different players though. I'm not suggesting that this is true, just that still seems possible.

Andos said:

Sorry, I mean that mcclient does not compress or decompress in my case. Mcclient may collect the data from server and send to mushclient line by line. and it means mushclient may has bug when recieve parts of lines, right?

Yes, this is quite possible. I'm not really sure what happens with servers that send parts of lines.

Quote:
I hope that mushclient will be better and better. And it's a good chance to catch the bug.
I agree.