Mudlet & Coffeemud

User avatar
Heiko
Site Admin
Posts: 1548
Joined: Wed Mar 11, 2009 6:26 pm

Re: Mudlet & Coffeemud

Post by Heiko »

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.

khyldes
Posts: 5
Joined: Mon Dec 31, 2012 3:52 pm

Re: Mudlet & Coffeemud

Post by khyldes »

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?

User avatar
Vadi
Posts: 5035
Joined: Sat Mar 14, 2009 3:13 pm

Re: Mudlet & Coffeemud

Post by Vadi »

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.

User avatar
bozimmerman
Posts: 11
Joined: Tue Jul 09, 2013 1:40 am
Location: Round Rock, TX
Contact:

Re: Mudlet & Coffeemud

Post by bozimmerman »

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

User avatar
SlySven
Posts: 1019
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Mudlet & Coffeemud

Post by SlySven »

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...

Post Reply