Interesting. Yes, it seems to show up fine after I disable compression.
EDIT: I had someone else test with compression enabled/disabled on other clients, like zMUD, GMUD, and SimpleMU, and I'm told they all work on all counts. It seems, then, that this MUSHclient bug has something to do with how MCCP is handled at EOF?
Back to this for a bit, this is unsolved AFAIK and it is interesting to read Worstje's commments here:
Referring to the MCCP implementation he says:
Oh, one thing though... Make sure you flush the stream when you know output won't be immediately following anymore, for example after you echo'd a prompt. Otherwise it can be partially stuck in the decompression buffer for a while leading to an odd playing experience where lines sometimes don't show up or take ages to show up. :)
When I first investigated this bug I thought maybe the MCCP buffer was not flushed, particularly as you report that the problem only occurs with MCCP enabled. However on *decompression* I made sure that the Z_SYNC_FLUSH flag was set, which forces as much decompression as possible to occur. Also the zLib library says as follows:
zLib docs said:
In this implementation, inflate() always flushes as much output as possible to the output buffer, and always uses the faster approach on the first call.
So, decompression should be working OK. But what about the server end? Reading Worstje's comment above makes me think that perhaps the fault is at the Achaea end. After all, testing with my local SmaugFuss server does not reproduce the problem, so we have the fact the MUSHclient works OK with Smaug, works OK with compression off, but loses a bit of data with Achaea (data which shows up later).
Now you said you "are told" that zMUD, GMUD, and SimpleMU work with Achaea and MCCP turned on. However for one thing, Wikipedia claims that GMUD does not support MCCP (this might be old), so I wonder quite how accurate these claims are. Do these clients *really* support MCCP, and was it *really* turned on? It may be hard to tell without inspecting the packets in some way.
Also it is possible a single test may not show the problem up. If the server does not set the "flush" parameter when compressing for MCCP, then depending on what is left over in the buffer you may lose a small amount, a large amount, or nothing.