Not that I'm aware of, although looking at the MXP Specification it doesn't actually say it can't. However MUSHclient's implementation of MXP only seems to support 24-bit colour codes.

It wouldn't surprise me if some client did support 12-bit colour, it's just that I don't know of any that do.


TTYPE may not guarantee the name, but most mud clients seem to use it for that. Of the 372 active characters on my mud, 50 (13.4%) failed to identify their client, 27 (7.3%) gave a generic terminal type (DUMB or ANSI), and 295 (79.3%) provided a meaningful client name.

MUSHclient, CMUD and zMUD identify their version numbers through the MXP <VERSION> tag, while Mudlet includes its version number in its TTYPE (MUDLET-1.0, MUDLET-1.1, etc).

Handling CLIENT_VERSION through a script would work I guess, but IMO it's the sort of thing that really should be built in to the client itself. It doesn't matter too much whether you do this through MSDP (CLIENT_VERSION variable), MSSP (client-side variant), MXP (VERSION tag), ZMP (zmp.ident command), TTYPE, or whatever else, but if it's something you consider worth adding then I think it really should be a documented feature of the client.


Yeah I saw that, I did actually take a look at your colour snippet to see how you'd done it, as I couldn't find any clear specification online. I found numeric values easier to read than letters though, and easier to explain to my players.

I've added CLIENT_NAME and CLIENT_VERSION to the spec, and in tt++ I'll add the name and version to the startup event.

I'm strongly leaning toward turning MVTS into MTTS (Mud Terminal Type Standard) which would be a mud client/server standard for handling TTYPE, and would deal with letting a server know what all a client supports. I'll probably go ahead and create a spec page, then ask for feedback. That would fix tt++'s issue of reporting client functionality, and given it'll be a breeze to implement client side, other clients might follow suit.

But the user will still need to write a script to return the appropriate values, right?

If that's the case, I doubt many would bother, and some of those who do will probably think it's funny to send back a silly CLIENT_NAME - so I might as well just stick with using TTYPE. Changing that would require changing the source code, which is more hassle than most people can be bothered with.

I'd use the CLIENT_VERSION, but only if I couldn't retrieve the version from a built-in protocol.


How about a "Mud Client Status Protocol" (MCSP) - the same as MSSP, but works the other way around.

I would rather discuss this one on MudStandards though. It would be far better if it had the backing of other client developers from the start.

Anything related to MSSP will indeed be scripted. With tt++'s open protocol support TTYPE can be hijacked by a script, and subsequently report whatever, though most users lack the know how to do so.


My idea is to re-use the TTYPE option so I think Standard fits better than Protocol, and it might be better to write it as Mud TTYPE Standard, still abbreviated as MTTS.

Regarding MudStandards; There's been zero interest for outside protocols or finding common ground, and I don't think that's going to change.

Just a brief update, to keep anyone in the loop if they're interested…

I've now got my MUSHclient plugin showing dungeons as well - that was the main big thing that was still outstanding. There are still a few tweaks I'd like to do (like add some buttons), and I want to do a little more testing, but the important stuff is working. That means I'm now very close to having a fully functional plugin based on MSDP, which will be pretty nice for promoting the protocol.

The developer of a new client is adding native MSDP support - he's been using GW2 to test it, and has spotted a couple of problems with my implementation, which I plan to fix soon. His client identifies itself as EMACS-RINZAI, but I don't know any other details about it yet.

One of my players is working on a TinTin++ script, using the MSDP data to display energy bars, maps, and other information. He's not finished it yet, but he's posted a screenshot here. He has his own internal table for the map characters, with the MSDP data providing only an index, so if there were a custom font it would be very easy to use it here - you could just replace the values in the table.

Pretty cool, only downside is that your plugin won't easily translate to a DIKU mud because of your tile based world, but it does demonstrate that the protocol is pretty solid.

The only thing that's lacking is file transfer, though in my opinion that'd be best dealt with using a separate protocol, MFTP or something, though if you accept a 200% overhead you can send binary data using hexadecimal notation over msdp. Might be worth the headache of getting the community's input on it.

I've put my font project on halt for the moment, mainly due to a lack of a good bitmap font editor (that creates fonts that work with PuTTY), and that I don't really know what a good set of generic overhead map drawing character would be. Still looking for a copy of Fury's work as well.

I have some ideas for equivalent maps in a Diku - the upper map could work in a similar way if the mud had a wilderness/overland system, while the lower map could simply show squares connected by lines, much like most room-based mappers.


Some sort of file transfer would be nice, but I'm not so happy doing it directly through the mud - unless the files were very small, or the download was spread out somehow.


Once my player has got his tt++ script finalised, I'll ask if he's willing to release it - it'd make a pretty good testbed for trying out custom fonts, as he's used a lookup table for each tile/terrain type. Add perhaps five characters to start with - a tree, a tower, a stickman, a brick pattern and a randomised pixelled texture. That alone would be a big improvement.

The MUD can send a 1024 byte chunk to the client, when the client receives it it sends a 'next' signal, upon receival the MUD sends another 1024 byte chunk. This leaves a problem with the last chunk which won't be 1024 bytes, but the client and server could negotiate total file size, and chunk size in advance, and by keeping count the client would know when a transfer is finished. Dealing with where to store the file and dealing with duplicates is another matter.


Should I stick with a two characters per tile drawing approach in the font? I could probably do a brick pattern with 1 character, but a tree would probably look nicer if I use two characters.

I think I'd need to run some tests to get a feel for it, and see how it affects performance. Why 1024 bytes, out of interest?


Well that's the beauty of it - the mud just sends you index values, what you choose to display is entirely up to you. For internal ASCII maps I currently use two characters per terrain type though, overwriting the second character with a '*' if a creature is at that position. I found the map looked squashed if I used 1 character per terrain type.

Packet fragmentation typically occurs somewhere after 1024 bytes which is easier avoided then solved. I helped one of your players with a packet fragmentation issue in the MSDP script (with the code in the msdp_report alias), still need to update it on the site, but apparently split up msdp report packets aren't handled properly. Might be possible to 'fix' the issue by doing multiple reads on the socket until no more data is available, then process it all.


It's more square looking to me as well using 2 characters. Additionally more (accidental) combinations are possible.

Packet fragmentation is extremely easy to 'solve' (use an input buffer), and regardless out of your control anyhow. Pretending you won't get fragmentation is sticking your head in the sand.

While I am maybe misinterpreting your comment, I would like to repeat something you have probably already heard me say about Putty. It is possible to send an escape code to Putty from a server to switch it to the unicode character set. Given this, perhaps there is a potential set of characters in unicode that would suit as a representation of overhead map characters?

Yeah, a good implementation should handle defragmentation, but undoubtedly several clients will implement it poorly, so that's why I'd suggest 512 or 1024 byte chunks, which will also spread out the load on the server.


I'm not aware of any other than the box drawing characters, which aren't really suited for nesw exit drawing because there are no characters for 1 exit rooms.

It might be possible to grab a 1024 range of characters in the unicode set, which would eliminate the need to squeeze everything into 128 characters. I'm not overly familiar with unicode, but to keep it compact a range could be picked that only requires a 2 byte utf-8 code. Rather than doing everything myself though it's possible to design a character set in ASCII (like I did in my mud font thread) and leave the actual font creation to someone else, this way it'd be fairly easy for others to contribute.

Going back to a point that was made last year:


Soon, there will be a point.

My "snippet" (which is now over 2K lines and could probably be more accurately called a "module") is currently being tested, and still has a minor bug that I'm trying to resolve, but it is functionally complete.

In addition to MSDP, it also offers several other features, including XTerm 256 colours and UTF-8. I can't identify if TinTin++ supports these options, so they are switched off by default.

However they are both offered as MSDP CONFIGURABLE_VARIABLES. If TinTin++ can identify support for those features at its end, it could automatically enable them using MSDP.

The current WinTin++ release reports TINTIN++ on the first TTYPE request, and xterm-256color on the second request. So if you're willing to poll terminal types that's one way to detect 256 color support.

I don't think there's a guaranteed way to detect the font selection, UTF-8 capabilities, or actual 256 color capabilities for terminal emulators.

Thanks, yes, I'll do that.


However you could allow them to be configured (and saved) at the client end, and then automatically enabled through negotiation with clients that support it - that way it would only need to be enabled once, for the first mud you played.

Not worth doing yet I know, but it's something that could be added retroactively - if we see an increasing number of muds utilising MSDP, 256 colours and UTF-8, it might worth considering for a future version of TinTin++.

MUSHclient allows me to negotiate for UTF-8 as follows:

Server: IAC DO CHARSET
Client: IAC WILL CHARSET
Server: IAC SB CHARSET REQUEST SEPARATOR "UTF-8" IAC SE

Then it responds with either:

Client: IAC SB ACCEPTED "UTF-8" IAC SE

Or:

Client: IAC SB REJECTED IAC SE

However that doesn't guarantee that the client is actually using a unicode font, only that it had the UTF-8 checkbox selected when it connected. The MSDP option would be nicer IMO, as it could be made a bit smarter - perhaps factoring in the font, and sending an update to the mud whenever the font changed.

I don't think there's a way for tt++ to retrieve the font used by the terminal, but a user could always script it with a predetermined configuration.

I've always envisioned MSDP as a scripting interface, and not something, like GMCP, that should be hardwired into the client. From that perspective it'd be best to send data that can either be used to display ASCII art, a special font, or a specific bitmap. That way the MUDs only sends data, and leaves how to display it to the client.

I thought the font was a property? Or is that just WinTin++? Or do you mean there's an "unknown" default which could be overwritten by explicitly configuring a font?


Well some clients are adding native support for MSDP, and personally I think that'll make it easier to use - my psuedo-ATCP implementation (i.e., MSDP treated as if it were a custom ATCP package) has proven far easier to use than my MSDP plugin, simply because Mudlet automatically stores the variables and raises an event.

However the CONFIGURABLE_VARIABLES take it beyond "nice to have". As far as I'm aware, MSDP is the only protocol that explicitly describes a mechanism for the client to indicate XTerm 256 color support - and one client developer has already expressed an interest in using it precisely for that purpose. There are other CONFIGURABLE_VARIABLES that are also useful - UTF-8 for example, for reasons I've outlined here. Or CLIENT_VERSION, as the only other way I know to reliably obtain that information is through MXP, which many clients don't or won't support.


When sending data about map information and such through MSDP, then sure, I send it like that.

But the UTF-8 thing is a separate issue. The only reason I mention it here is because of the CONFIGURABLE_VARIABLES - which in my opinion should be handled natively by the client. If the server can identify that the client supports UTF-8, then it can automatically display nicer maps, use line draw characters, etc. The user shouldn't need to write a script for that, any more than they should have to write a script to indicate VT100 or ANSI colour support (those are also CONFIGURABLE_VARIABLES). Nor should the user have to explicitly write a script to report their CLIENT_VERSION.

A terminal application's font is controlled by the terminal, not the application running inside the terminal.

It actually reports just "xterm" on the second request. But in combination with the "TinTin++" from the first request I can at least now identify WinTin++. It aint pretty, but it works.