Yes, I'd do it that way. Internally the mud may want to keep a list of PLUGIN_IDs, but I think each plugin/script should only send one (its own).


I don't currently support either, but I would prefer SERVER_TIME and WORLD_TIME.


It's written in Lua, so the players download it as source code - and I've no objection to other muds using it, modifying it, etc. It's only the background images I wouldn't want other muds distributing to their players, but I doubt they'd want those anyway.

It doesn't yet handle dungeons though, and I'd like to get that working before promoting it too heavily. Once that's in place I could provide a series of screenshots though, and we could bump the adverts every couple of weeks with new screenshots, new plugins, new scripts, etc.

I'm not sure what your MTH telnet handler is - do you mean you'd turn MSDP into a built-in protocol? If so, I think that might encourage people to take the protocol more seriously, because right now MSDP isn't natively supported by any clients, even though you, as its creator, are a major client developer!

It might also be worth creating MSDP snippets for a few of the more popular codebases, even if they only offer a minimal variable list.

MTH is a public domain snippet I wrote in C that adds telnet support for NAWS, TTYPE, NEW-ENVIRON, MCCP, and MSSP. I could probably add generic MSDP support to it which might make it easier to implement for mud devs.

One issue with promotion is that there is VT100, MXP, ATCP, ATCP2, 102, and ZMP besides MSDP, maybe you could create a list of pros and cons as you've worked with most of them.

Also, what do you mean with native support? TinTin++ has a specific MSDP handler, though it's very generic and besides turning arrays back into key-value pairs only provides a data interface. Would there be more I could do to make MSDP easier to use in tt++?

Ah, your general snippet for server-side support? Yes, adding MSDP would be a good idea.


VT100 escape codes? Not really used them except for colour, but I'm not sure I'd put them in the same category - you're transmitting in-band data. The same is true for MXP (although I believe Zugg has added out-of-band support for his latest version of MXP, I don't think anyone else has followed suit, so for compatibility reasons its probably not something you'd want to rely on).

Really you've got four main candidates for transmitting out-of-band data.

ATCP: Vague specification, due to be replaced in the future with ATCP2 (although not even the name has been agreed on yet, let alone anything else). There are apparently certain options that can be selected, but data is sent in packages (such as a 'vitals' variable which has a group of associated values). It's supported by the IRE games and Avalon (the German one), and other muds have expressed an interest. It's natively supported by Mudlet and there's a browser-based client that's planning to add support for it as well. I think the latest version of MUSHclient may support it natively too (I didn't think it did, but yesterday I noticed it responds to my ATCP negotiation with a WILL). Zugg has said that he's adding support for ATCP2 to CMUD.

102: Created and used by Aardwolf, and (as far as I know) nobody else, and there seems to be little public documentation on it - it doesn't even have a name! Is Aardwolf even going to keep using it, or are they moving to ATCP? Anyone know? It uses a Lua-style syntax, which may be a pro or a con depending on your personal preferences - I'm not sure how well this would work with clients that don't support Lua. Natively supported by at least Mudlet and MUSHclient.

ZMP: Looks like there was once some good documentation on it, but I kept coming up with dead links. The spec is much less vague than the others, but also much less complete - you'd need to design your own packages, it's not an "out of the box" protocol like the others. I don't know of any operational muds that support it (other than mine), and it uses NUL bytes which quite a few people dislike. Natively supported by MUSHclient.

MSDP: Specification is clear, design is simple but open-ended, and my script-writers dropped ZMP and starting using MSDP as soon as I'd added it to the mud. Allows the client to specify exactly what data should be sent. I don't know of any other muds that support it, but the design and data format is very similar to MSSP, which has been adopted by more muds than the other three protocols combined, so it's not entire untested. Not natively supported by any clients as far as I know, although there are scripts available for using it with MUSHclient and TinTin++.

I think ATCP looks like it'll be the most widely adopted, because the clients will obviously follow the big servers, and most muds will follow the clients. However TinTin++, MUSHclient, zMUD and CMUD allow you to define your own protocols, and as you'll need to create your own scripts/plugins to take advantage of the protocol anyway, it's not such a big deal to miss out on the built-in protocol support - it's more of a psychological thing IMO.


Perhaps I have an old version of TinTin++ then? To use MSDP I currently need to use the msdp.tin script, which handles the negotiation and reads in the data - as opposed to (for example) MSSP, which does it without any special script.

Using VT100 you can create a tactical interface, though you're limited to text. The biggest advantage is no client side downloads aside from having a VT100 capable client. I guess in a way it could be considered out-of-band data. VT100 interfaces are used by about 9 MUDs, and most console clients utilize VT100 to create a split screen interface to create an input bar.

I think MXP can be used to create server side tactical interfaces by utilizing frames, but I've never seen a MUD actually do it, possibly because of bandwidth issues.


I could add something like #config msdp on, but in my viewpoint that's not much different from the player adding #event {IAC WILL MSDP} {#send \xFF\xFD\x45\}. What tt++ handles behind the scenes is the IAC SB MSDP event which sets %0 as the variable name, and %1 as its value. If I remember correctly, in your MC plugin you have a low level parser to read out the key-value pairs, this part is build into tt++.

MSSP is only automatically negotiated and displayed when tt++ is in the telnet debug mode, but to do anything useful you'll have to go the same route as the MSDP script.

I suspect it's more due to the fact that many clients only seem to support a subset of the MXP features.


Why use a config option at all? Why not automatically respond to WILL with DO? That's how other clients handle ATCP, ZMP and 102, and it's not as if it's going to break anything - if the client doesn't ask for variables, the server isn't going to send them. And even if the server does go ahead and make a query which the client doesn't support, presumably the client would just ignore it.

With MSDP there really is no telling what the server would do. MUDs that only use MSDP for a handful of variables might not bother negotiating their use and start reporting them the moment the client enables it, which would make implementation a lot easier.

But even if they did that, would it actually cause a problem for TinTin++? Surely the variables would just be ignored?

It's not a problem for tt++. My general reasoning is that if it can (easily) be scripted it should be scripted as my main design goal is to keep tt++ as bloat free as possible.

But you've already added support for the protocol - TinTin++ extracts the data from the subnegotiation sequence and splits it into the variable name and value. All it's missing is the initial handshake.

The minor issue of bloat aside, it seems wrong to me to automatically respond with 'IAC DO MSDP' when there's no point in enabling it if there's no MSDP script loaded; the way I see it there's a lot more missing than just the initial handshake, not to mention the user is very likely to want to do something other than responding with IAC DO MSDP on the IAC WILL MSDP event (like sending a REPORT request as well), and when there's an event triggered the default behavior is ignored, so the user would have to send IAC DO MSDP inside the event, which I think would be very confusing as many users will assume the default behavior continues, while it makes sense it doesn't as someone might want to trigger the event to make the client send nothing at all; not to mention that if I automatically enable MSDP, to stay consistent, I should also automatically negotiate ATCP, ZMP, ATCP2, and 102, which only really requires changing some flags in the telnet_table in tables.c, but I'm very much against the idea.

Does this actually add any bloat though? Or are you just changing a '0' to '1' in a table?

I realise that MSDP has no functional purpose without a script, but it's still a useful way to identify which protocols a particular client supports (that is, after all, what the handshake represents). My players can see which protocols they've got available, and I can give them suggestions and tailor the help files to describe how they can utilise them.

This is also how every other client I've seen handles its built-in protocols - if you send IAC DO ATCP to the latest versions of MUSHclient or Mudlet, for example, they will automatically respond with IAC WILL ATCP, even though the protocol is no use without additional plugins/scripts. The same with ZMP and 102. If any clients ever add built-in support for MSDP, it seems very likely they'll implement it in the same way.

Now Mudlet doesn't let the script writer catch the IAC DO ATCP, so I've found a simple workaround. As soon as the handshake has been established, I send the SERVER_ID to the client. Mudlet can then catch this and respond with a REPORT - and after some consideration, I think this is actually a better place to put the REPORT, because it can be tailored to whichever mud you're currently playing. I will be changing my MUSHclient plugin to work the same way, and recommend people do the same with their TinTin++ scripts. If there were a writeMSDP() function as well, the script/plugin writers wouldn't need to touch or understand the sub/negotiation sequences at all.

Just changing a 0 to a 1 - though there's always documentation bloat when you add exceptions.


The handshake is for enabling MSDP however, not checking support. MVTS (http://www.mudstandards.org/forum/viewto...) could be used, but I'm not sure if MSDP and alike protocols should be in the list.


Argumentum ad populum? It wouldn't make sense to do the same thing with MSP the way tt++ handles things as the player would start getting spammed with !!SOUND messages. So MSP and MXP no, MSDP yes? Little consistency in that.


With tt++ people can (and are most likely to) attach their MSDP interface to the specific session, rather than all sessions, so this particular problem doesn't exist.

It wouldn't matter even if your approach were "correct" and the other clients "wrong". I need to support them, or I'll lose players.


MSP is a bad example, I think the protocol itself is poorly thought out. However every client I've seen that natively supports MSP does automatically accept the MSP handshake - and I've yet to see any MSP-supporting mud that didn't have an in-game way to switch sound on and off.

You should never be spammed with visible !!SOUND() messages though, the client should always remove those if it supports MSP.


MXP, like MSP, is automatically switched on by clients that support it…at least to my knowledge. Are you saying that TinTin++ could use some of my MXP tags if I added a script to accept the handshake?

It's possible to translate mxp colors to 16 or 256 colors, though I'd strongly suggest using xterm 256 colors instead (using \e
It's possible to translate mxp colors to 16 or 256 colors, though I'd strongly suggest using xterm 256 colors instead (using \e[38;5;0m to \e[38;5;255m) as it's more widely [url=http://www.mudpedia.org/wiki/Comparison_...] and easier to add for clients that don't yet support it. Other than that I can't really think of instances where MXP tags could be translated into something useful by tt++.

Spec wise I changed TIME_SERVER and TIME_MUD to SERVER_TIME and WORLD_TIME and added SERVER_ID and PLUGIN_ID.

Regarding arguing with walls, I can only use this borrowed expression: Good luck, have fun…

:sad:

FWIW I'm pretty interested in the stuff you're doing, and I'm actually rather sad that you're running into opposition on such simple yet important points.

The latest tt++ versions report the client name on the first ttype request, and terminal type on the second ttype request, the terminal type can be used to determine xterm 256 color support, XTERM, XTERM_COLOR, RXVT, etc.

I think easiest for a MUD server is to use some kind of internal color code, and have a routine that determines whether to translate it to 12, 8, or 4 bit colors.

Regarding versions, might be an idea to add CLIENT_NAME and CLIENT_VERSION to MSDP. Handling <send> is difficult, most workable might be printing (F1) behind a link and create a macro that executes the command, then the second link would be (F2) and after (F8) it would loop back to (F1) overwriting the previous macro. Being a console app tt++ doesn't really know where text is at once it's been printed to the scrolling region, so I can't use xterm mouse support, that is, not without creating a local copy of the virtual terminal.

Useful for TinTin++ users, but I'd need to handle other clients as well. I could have a hardcoded internal table of client types to cover most possibilities, but that wouldn't be perfect either, so I don't think there's any way to avoid an in-game config option.

Still, I could use TTYPE and an internal table to determine the default colour mode when they first create their character.


12-bit? Do any mud clients actually support that? I'd have thought 24-bit (MXP) and 8-bit (256 colours) would be enough to cover most clients, falling back on the standard 16-colour ANSI for the others.


TTYPE already covers the client name. CLIENT_VERSION might be useful if MSDP were built in to the client, but if its handled through a script it would be too unreliable to be useful - I doubt any users would bother updating it.

Maybe I was overthinking the problem. I've just added support for 256 colours to see what it's like, and I kept the old ANSI colours for the defaults. Players can customise which colours they see for different things, so if they don't support 256 colours they just don't set them - they stick with the normal 16 instead.

The format I've used is three digits (RGB) each in the range 0-5 for foreground, and a optional 3 extra digits for background. So "500" would be red, "050005" would be green text on a blue background, etc. It works perfectly for TinTin++, MUSHclient and Mudlet. CMUD shows the foreground colour, but apparently not the background colour.

I assumed MXP accepted 12 bit color codes as well since HTML does, perhaps it doesn't.


TTYPE doesn't guarantee the client name, and a script could retrieve the current client version dynamically.


tt++ uses a-f for foreground colors, and A-F for background colors. For the grayscale it uses g00 to g23. So <afa><AAF> would be green on blue.