Mudlet - Forum

The output scrolls up because the server keeps sending ASCII 0 chars. This server also misses prompt configuration to end the prompt properly with a telnet GA event or a newline.

I pasted this conversation into the Coffeemud support forum to see if there's something Zimmerman can do to fix the output scrolling.

Is there any specific reason that this is the only mud client (doesn't happen on putty, tintin++, mushclient, atlantis, mudwalker, telnet, zmud, cmud, every android client, every ios client) that this problem presents itself?

Because Mudlet doesn't ignore the nul characters the server sends and throws them up on screen as-is.

A better question to ask would be why is the MUD spamming you with them, but Heiko said he'll add a workaround to ignore them later on.

Regarding Go-Ahead -- good point. I skipped it because none of the other mud clients, including telnet itself, seemed to care. However, I'm adding Go-Ahead to the end of prompts now.

Regarding MXP -- you don't need to support all the features, but if Mudlet is going to respond to the negotiation at all, it at least needs to support these:
<SUPPORT> and <!ELEMENT>
SUPPORT is needed so the server knows what tags to suppress. <!ELEMENT> is needed so you know what extraneous tags to ignore, if nothing else. In the meantime, since Mudlet doesn't react to <SUPPORT> at all, I'm having the server suppress all MXP, even when negotiation succeeds, if the client does not send a response to a <SUPPORT> request. That should work as a Mudlet-Exception while doubling as a one-off rule.

Regarding the 0 character, RFC 854 defines the 0 as a "No Operation" character, which is different than a "linefeed" character that Mudlet seems to implement. That makes 0 perfect as a ping character, which is what CoffeeMud uses it for. That said, future versions of CM will use IAC NOOP instead... Mudlet does not seem to treat that as a linefeed.

- Bo

Well smearing some ointment on a fly in regard the last point:
RF854 has been updated by RFC5198, which amongst other things includes a comment on the ASCII NULL character (as part of the CR NUL) combination but the comment is equally relevant here for a bare NUL:

In RFC5198 was wrote:... Because NUL (an octet whose value is all zeros, i.e., %x00 in the notation of [RFC5234]) is hostile to programming languages that use that character as a string delimiter, the CR NUL sequence SHOULD be avoided for that reason as well...