When MushClient 3.15 receives a very long line, it locks up.
This happened on a MOO where I entered a room with a description that was one very long line. The line wrapped 18 times, and then MushClient froze in the middle of the 19th line. MushClient stopped responding to mouse clicks and keyboard input.
So I disconnected and reconnected, getting the same room description, and MushClient locked up again. And again. And again.
To be clearer, instead of "disconnected" I should have written "terminated the process in Task Manager".
I have tried to replicate this - for example with a 55-line long description, but I do not have any problems.
Do you have any triggers active? Try disabling all triggers and seeing if it still happens (there is a single checkbox that will do this).
If so, can you send me the line? I know it might be hard in MUSHclient if it crashes, but use another client, or straight telnet. It might be something strange about the line.
Also, do you have "indent paragraphs" checked? (ie. is each subsequent line of the paragraph indented by one space). Whichever way you have it, try the other way, and let me know if it still happens.
I haven't seen this bug. I did see the bug in versions 3.12 through 3.14 where I was getting Illegal Operation errors and the program was closing, the new version, 3.15, stopped that from happening and also replaced the activity button problems I was having.
I work on a an old style MUSE and also work with huge descriptions, the client is running on windows 98 se and displays a very, and I do mean /very/ long room description, one that I wrote, that was nearly 25 lines, and it displayed it fine.
BTW, I do love this client, it works great for everything I do, from building to playing, keep up the good work.
Disabling word wrap has no effect, but disabling triggers seems to alleviate the problem.
Now that I know it's trigger related, I've noticed that long lines cause MUSHclient to freeze only until a different trigger or a timer goes off, at which point it unlocks. For example, the description of LambdaMOO's The Smoking Room (#51556):
A dark and spacious room which retains a kind of warmth, despite its crepuscular aspect. The ceiling is high, and a brass gasolier lights the room with an orange, flickering light. Heavy paneling, made of burled maple, lines the walls, and a burgundy, Biltmore carpet covers the floor. The room's seating includes a leather sofa, a bergere armchair, and a pearwood chair. An Edwardian-style fireplace is set into the wall. Set into the wall above the fireplace is a pair of hooks with two fencing sabres resting on them. The single window is framed by full-length draperies. Next to the window is a painting. Off to one side is an elm burl humidor. A long velvet cord hangs down from the ceiling. In the far corner is a pipe rack. Standing against one wall is an antique, cherry bookcase filled with classic works of literature. A silken tapestry hangs from the wall, woven into a beautiful rendition of a medieval castle. It shimmers in the light, attached to two recessed wrought iron hooks. A small green bottle lies on its side behind one of the bergere armchair legs. The door to the Drawing Room lies to the west. A set of French doors to the south lead to the dining room.
When triggers are enabled, this description is output up to "wrought iron ho", then MUSHclient locks up until another trigger or a timer goes off.
Sounds like a rogue trigger. Can you make sure scripting is enabled, and then type into the command window:
/world.debug ("triggers")
Then copy the output from the screen (click and drag) and paste the result either here, or into a private email for me.
Thanks.
I figured out which trigger caused the problem. It was a trigger for
*** Redirecting old connection to this port ***
If I rewrite it to the regular expression
^\*\*\* Redirecting old connection to this port \*\*\*$
the problem disappears.
I now realize my error in using "***" in an expression, but MUSHclient should handle such defective expressions more gracefully.
I almost suggested that you might have multiple asterisks in a row as this is a known - shall we say - limitation. It is actually a problem in the way the PCRE library handles multiple consecutive wildcards, especially, I think, with long lines, as it tries for a long time to work out what text to allocate to what wildcard.
I had planned, and will do in the next version, to detect this situation, and at least, warn you.