Problem with worlds locking up until you send a command

I know, descriptive title. :)

Okay, I'm running WinME, and this is what's happening.

I connect to my few worlds. Things are normal. Then, suddenly, I stop seeing anything from the world until I input a command of my own. It's like it's only letting things through in the part of a second after I hit 'return'.

Rebooting seems to be the only thing that helps, and that's only temporary.

So... help?

On the bottom RH side of the status line, is the word "MORE" there in inverse?

It is possible you have somehow paused output, and then when you type something it unpauses.

Nope. Not paused. This is an actual connection thing. When it happens, it happens on all my worlds at once, generally.

Very strange. Are you using ICS or something like that? Are you using a dial-up modem, cable or something else?

Do you get the same problem if you use another client? eg. use telnet that comes with each copy of Windows.

I don't know what ICS is, we have cable, and no, it didn't happen with anything else, as far as I recall.

Strange, no-one else has reported this "simultaneous stopping" sort of bug.

Are you using scripting? If so, try turning it off.

Are you using any triggers? If so, try disabling them all (there is one checkbox to do this).

Try connecting using telnet, and see if the same problem happens (in which case it is a Windows problem).

eg. start up a "command" window and type in:


telnet mud-address port

eg.

telnet smaug.org 4000



I have actually had this happen too. Until recently I used no scripts, etc. and once in a while the connection would just stop until I sent more commands. This may not be a MUSHClient problem though, since it only started happening to me after Windoze Infernal Exploder crashed. Wish I knew what the source was or how to fix it. It can be a real pain, especially since it does not happen in any consistant way.

Make sure you don't have any triggers along the lines of:



*** You have connected ***


The multiple asterisks can confuse the wildcard parser. If you need to match on multiple asterisks they need to be "escaped".

Nope just checked to make sure. I have quite a few that are:
*our Godshield has faded*
*ou deposited * Gold in the bank.

that sort of thing. For some reason the mud insists on placing a space on input lines, so even replacing the prompt with a newline or adding one to the end gives a line the is like the following:
" Your Godshield has faded."

Kind of a pain. ;)

However, I have none which have multiple * * * in them. It even happens sometimes when moving and there are no possible triggers that could be responsible. It also does not happen all the time. But whether it is some strange sort of lag on the net or a glitch in windows that they haven't yet spotted (since it only happens on some peoples computers)...

I also don't use any other clients, MS Telnet stinks (I never could get it to local echo) and zmud is the only other one around that comes even close to having all the same features as yours, so I haven't tried to see if this is common to all of them for me. It does sound like the same problem that Neva was having. May just be something in common between our systems.

I do believe, folks, that you're probably seeing a problem(?) with MCCP, where the data is "stuck" in the buffer. I've seen this before, though I'm not sure if that's what you're talking about. Can you clarify any, Nick?

Hmm. Actually I haven't seen this problem myself in some time. Why MCCP would have anything to do with it 'when not on' I am unclear with, but you could be right about that being a source. I think it may be tied in some strange fashion to lag though as well, since it seems to happen then more often that other times. It is a very strange thing...

The client works asynchronously, that is, it waits for a "message" to arrive telling it there is new data coming in from the MUD. Under certain circumstances (eg. a bug in the Winsock DLL) that message may not arrive, so the data goes unnoticed.

I can't see how MCCP would affect it.

You could try installing a newer Winsock DLL, if such a possibility is available to you.