Talk:List of MUD clients

CLI

Can someone explain this note? "CLI: command-line interface using redirection, not to be confused with system (C standard library)". I have no idea how that relates to scripting or SSH.

Also, I removed the note about Ruby being able to work with other "scripting languages like C". Seems kind of ridiculous. I mean, you could create a COM object, P/Invoke, etc. in most of these languages and interact with whatever other interpreter or compiled code you want. It seems a little absurd to say that, since then pretty much every one of those columns would have a little note like that. 209.121.200.4 (talk) 15:02, 12 November 2009 (UTC)

tintin and kbtin have redirection support which allows running external console applications within the client, including ssh, lynx, and stunnel. Additionally tintin supports a higher level form of redirection that allows running external scripts and feeding the output back into the client for evaluation. It's a bit of a catch all like WSH. Not sure if there's a better way to list it, not to mention there are different levels of shell integration.

It's difficult to say where to draw the line, zMud has MMCP support through a plugin, and the same goes for MUSHclient's MSP support, does your reasoning imply their 'yes' status should be changed to 'no' ? I think it's primarily a matter of accessibility. --Scandum (talk) 21:04, 12 November 2009 (UTC)

CMUD and zMUD not client-specific?

I reckon CMUD and zMUD shouldn't be listed as using TINTIN for their language, but a client specific language. It uses a TINTIN-like syntax, but it's definitely something different. The Zuggsoft website's support section has loads of info on it.

Also, when CMUD 2.0 comes out its SSH entry will need to be changed from "No" to "Yes", and perhaps a new column for Lua could be added? CMUD will have built-in (not WSH) support for it.

Oh, and is the C column really needed since no clients support it?

84.65.56.183 14:07, 17 July 2007 (UTC)

The zmud site still claims: 90% compatibility with TINTIN and TINTIN+ text-based clients. [1] The scripting language is clearly tintin derived which is more obvious in earlier versions, so yes, I'd say it's a TINTIN language as much as Mercthievia is a DIKU MUD. (since TINTIN was public domain software that's where the comparison ends) There is also a note under the scripting table that states: Some clients run a significantly modified version of the original TINTIN scripting language, which I added with zScript in mind.

Feel free to remove the C column and add a Lua one, preferably alphabetically sorted between 'Client Specific' and 'Perl'. And I'm sure someone will update the page sooner or later when v2.0 comes out. --Scandum 23:41, 17 July 2007 (UTC)

I've made these proposed changes, corrected zMUD's scripting support (it listed many languages as WSH when in fact it only supports JScript and VBScript via WSH, neither of which is in the table), and clarified the TINTIN statement you added to explain that clients running modified versions of TINTIN's scripting language are listed under TINTIN. 90.241.170.33 (talk) 23:56, 9 January 2008 (UTC)

At least theoretically, support for VBScript via WSH implies support for .net, and all the languages that that implies. Martin Rudat(T|@|C) 15:10, 21 May 2008 (UTC)

JScript is now in the table, so I updated zMUD. Why not add a column for vbscript, though, since it appears to be still missing. Or should there just be a WSH in the vb.net column for zMUD?

Muby

Just a quick note - I updated some references for muby. I'm a minor dev so I do have some knowledge, but I don't have all of it so I'm leaving some of the items blank. -- Sy / ^(talk) 17:34, 29 June 2007 (UTC)

I checked out Muby today.

Regarding Operating Systems: I'd only add Windows if your site offers an installer.

Color Support: Badly Supported, quite obvious when using background colors, it's not an issue on most muds though.

VT100: Server side VT100 is not supported, probably due to the client side VT/ncurses input bar. If the input bar could be disabled some VT options might work.

TELNET: Not supported.

NAWS: Not supported.

EOR: Looks like it's not supported since the client doesn't seem to support telnet negotiations.

GA: Seems to break the client.

ECHO: Not supported.

MXP and MSP are obviously not supported. --Scandum 23:36, 29 June 2007 (UTC)

TELNET -> SSH

I replaced the TELNET option with SSH for the following reasons:

• Many editors seemed to mistakenly select telnet.
• Most clients claiming to support telnet only support a small subset and generally fail to connect to strict servers, *nix servers being pretty lenient.
• In order for telnet to be useful you'd want VT100, Character Mode, NAWS, and various other annoying to implement features to work as well.
• Many servers do not allow telnet logins and only accept ssh logins for security reasons.
• A client supporting NAWS and ECHO is likely to be able to connect to *nix servers as well.
• SSH seems to be a commonly requested feature, probably because some muds support it, while there's little use for most mud clients to connect a telnet server.

Hopefully nobody is offended I changed this without discussing it first. --Scandum 22:06, 8 July 2007 (UTC)

Well, a couple points. First, VT100 is not part of the Telnet specification; that is a terminal emulation. If you mean telnet as in 'connect to a shell,' that is different and I agree you need VT100 or ANSI or some useful terminal emulation. Second point is 'SSH' itself: do you mean SSH as in actual SSH -- OpenSSH and so on -- or just SSL? I know of plenty of games which use SSL encryption, but I do not know of any which use the full SSH protocol. (SSL and SSH are not the same thing.) I suspect you mean SSL, as I know that TinyFugue supports SSL but I have heard nothing about TF supporting actual SSH. I personally have no objection to the changes, but think those two points should be clarified. :) SeattleSparks 23:22, 12 September 2007 (UTC)

I was indeed referring to shell access. Text editors require VT100 support to work.

I meant SSH in general to connect to *nix servers. I'm not familiar with any muds that use SSL (could be a mush thing), though I do know muds that forward a ssh port to the mud port. --Scandum 08:08, 13 September 2007 (UTC)

I have not seen a mud that uses SSH for encryption/authentication, I have seen a few that use SSL... SSH support requires either a custom implementation of SSH (which is probably non-trivial), or that your mud's user accounts are also user accounts on the machine that is hosting the mud, which is probably not a good idea. SSL support on the other hand can be retrofitted to a mud by using a wrapper, and allows you to continue to use the mud's internal authentication system for access control.

The ability to perform actual telnet option negotiation is required to implement MCCP, and ECHO (for reading passwords), and apart from implementing only a subset of the required telnet options, any mud client that supports negotiating MCCP, or turning off and on local echo for reading your password is also a valid telnet client. I would agree that a supports telnet is uninteresting, because supporting MCCP, NAWS, ECHO, START-TLS, etc. implies supporting at least telnet option negotiation and a subset of telnet options.

I'm not certain what sort of (valid) telnet server would be upset at a mud-client attempting a connection, any behaviour that caused the telnet server to become upset would (as far as I know) class the server as being invalid (according to the RFCs). The only thing I can think of is the client not saying WON'T to any incoming DOs (which I can't find anything about the validity of), because any valid telnet client or server must support the other end saying that they won't do anything other than the default. Martin Rudat(T|@|C) 15:07, 21 May 2008 (UTC)

It seems pretty silly. A MUD client is a program that connects to a MUD server. One cannot connect to a MUD server via SSH. Therefore, I don't think SSH support is a very relevant MUD client feature. The reason I removed it, however, is because several editors were conflating TLS/SSL support with SSH support. Some of those clients listed certainly will not let you connect via SSH. And I have no earthly clue what the CLI identifier distinguishing the different types of "SSH" support was for. If someone wishes to add back the SSH column, please make a separate column for it (I believe only DF Client and CMUD supports this). Don't lump it in with SSL. 209.121.200.4 (talk) 14:56, 12 November 2009 (UTC)

GMud - scripting?

What scripting does GMUD support? It's listed as a Windows client, so I presume it's the GMud that I know, not some GPL'd software (which would probably be "gmud" not "GMUD" anyway :) ). I've marked it off as "No" on all the scripting entries; they were all either No or blank except "Client-Specific" - if someone knows of a version that does do scripting, feel free to mark that one "Yes" again.

Also - I've written a client, a derivative of GMud, but way more powerful. Would it be a conflict of interest if I mention it here?

Rosuav (talk) 04:22, 14 April 2008 (UTC)

Wine Support

Does running under Wine count as being able to run on a platform? Virtualisation definitely shouldn't, but as the acronym goes, Wine is not emulation.

--Earin (talk) —Preceding comment was added at 15:09, 19 June 2008 (UTC)

Its a bit of a gray area, but I don't think running under Wine should be seen as the ability to run on a different platform because in that case every client can claim to be multi-platform. --Scandum 18:19, 22 June 2008 (UTC) —Preceding unsigned comment added by Scandum (talk • contribs)

Savitar missing

Hey, I am afraid I'll ruin the Columns if I try to edit myself, but maybe somebody else is willing and able: The mud client "Savitar" is missing. It runs in OS X only and can be found here http://www.heynow.com/Savitar/ Thanks for your efforts. — Preceding unsigned comment added by 80.137.151.232 (talk) 14:41, 27 January 2012 (UTC)

Protocol support

The Protocol Support section table header constains some acronyms linking to TELNET, but they are not mentioned on the TELNET page. For example EOR is not mentioned on that page nor here. IMHO such acronyms should be explained in some way. Either by linking to a page about them or in this article itself. JaBoJa (talk) 16:36, 20 June 2012 (UTC)

Wine & Boot Camp

I think that clients that can run with these programs should be clarified. Readers will come to this article to see if their devices will run the clients. It is unhelpful and misleading to declare that clients such as MUSHclient cannot run on Linux or Mac OS X. Axl ¤ [Talk] 01:11, 23 January 2014 (UTC)

Fix unhelpful links

I am a contributor to the source-code and an official forum moderator to both the TinTin++ and Mudlet Mud Clients so I think it would be inappropriate to directly make such edits but I note that links in this article for specific clients have degenerated as related articles have been revised so that internal links in this article that relate to the MushClient and ZMud clients are circular and (unhelpfully) come straight back to this page; whereas the TinTin++ and TinyFugue ones redirect to the history section of the generic MUD Client page which is not really much help in given more detail about the specific clients' entries in this article.

I would suggest removing the circular links and following the example for the BioMUD and Potato client links just include an external link to the clients' own website, for the two that I know these would be Mudlet and TinTin++... SlySven (talk) 12:28, 17 November 2016 (UTC)

 Partly done It's against our external links guideline to have external links like you're suggesting. I've gotten rid of the links that just redirect pas here. ---- Patar knight - ^chat/_{contributions} 21:32, 17 November 2016 (UTC)

The links at the top of the "Protocol support" table, for: NAWS, EOR, ECHO are pointless links to Telnet in general and there is nothing there specifically about them - although they will be documented, each on one of the external RFC links as: NAWS RFC1073, EOR RFC885 and ECHO RFC857 respectively.

"MCCP" (MUD Client Compression Protocol) and "MXP" (MUD eXtension Protocol) are circular redirects right back to this page which has NO details about them - perhaps they also need to be made WP:RED like "MSP" and "MMCP" - perhaps until they could be fleshed out, in new sections, in this article, perhaps?

I originally dropped by and wanted to note that Mudlet is intending to add Unicode support ready for Version 4.0 as was announced at https://www.mudlet.org/2017/06/mudlet-3-2/ of course as the Coder who is doing this (adding support for UTF-8) I have a massive, not paid, WP:COI but I would like to have the data revised as appropriate at the point in time where it becomes relevant - but is that something I have to request rather than attempting it myself?

SlySven (talk) 02:01, 16 July 2017 (UTC)

 Done. Instead of creating more redlinks, though, I just removed the redlinks. Hope this helps. jd22292 (Jalen D. Folf) (talk) 01:16, 7 August 2017 (UTC)

Yeah, that is better. One issue though - Mudlet is not yet at the stage where Unicode is operable - at present the table now lists it as "yes" whereas it can currently only be described as "pending" or "in progress" or "not yet" - it requires some big changes internally and it isn't in place yet... SlySven (talk) 12:21, 5 November 2017 (UTC)

Sections that are not relevant

Can @Jc37 explain why they feel that the sections on MUME and MXP needed restoration? Neither are MUD Clients, the first is, instead a MUD game provided by a MUD Server and the second is a protocol for sending "Out-of-Band" data between MUD Server and Client. To be honest it feels to me that the first of these two sections is an advert, and the second should be moved to its own article if sufficiently noteworthy (though if I recall correctly that might have been the case in the past but was subsequently culled by an editor who removed such things for a number of "protocols" that MUDs make use of). SlySven (talk) 20:53, 3 March 2024 (UTC)