Re: The mud client poll
 

I use MUSHclient, though personally its biggest failure is that it does not properly support UTF8 input (though it DOES support UTF8 output from the MUD, oddly enough)

Re: The mud client poll
 

They do offer the "Not Listed" catch all. But I agree, Tintin and Vipmud aren't listed and they are both very popular. Maybe someone will start a new thread with an updated poll for some of the other clients. I vote that you should do it, though, since you created this thread. :p

Re: The mud client poll
 

Depends what I'm playing, and what plugins people have made.

UL has a great CMUD plugin, so that's what I use.
ConQUEST has a decent Mushclient plugin, so that's what I use to play it.

Re: The mud client poll
 

Tricky one

I primary use CMUD for most MUD's I have played / still play. Awesome program

I use Primordiax webclient for that game and a smattering of CMUD if playing alts when gathering resources due to being able to have tiny windows all visibile at once on screen

I use MUSHClient for Godwars II

Re: The mud client poll
 

I'm a little surprised to see Wintin or Wintin.NET not mentioned here. The vast majority of our player base uses one or the other. The second most widely used client is Zmud. We rarely see any Cmud users.

Re: The mud client poll
 

My players , with TinTin++ in second place, but only a handful use Wintin or CMUD. I think it very much depends on which clients the mud promotes - particularly if you've got first-time mudders checking out your game. SlothMUD for Windows users, so that's what most new players will download if they're using Windows.

I did initially notice quite a few zMUD users, but as they're slowly migrating over to Vista or Windows 7 they're finding that . Rather than paying for CMUD, as Zugg recommends, quite a few are instead switching to MUSHclient.

The open source clients have something of an advantage in this respect I think. I'm much more likely to invest my time customising something like MUSHclient, Mudlet or TinTin++, firstly because they are free (and therefore more likely to be downloaded by new players), and secondly because they're open source (meaning that even if the developer loses interest, as has happened with many clients over the years, someone else can carry on - or I can even do it myself if necessary). Thus no danger of running into the problem that zMUD users are now encountering.

And of course if I spend my time customising MUSHclient, that's what I'll recommend - and therefore that's what most new players will use when connecting to my game.

I would like to offer a Mudlet option as well, particularly for my Linux and Mac users, but I've not yet got the hang of its scripting system.

Re: The mud client poll
 

Though the difference is that Zugg's full time job is to write cMUD/zMUD. He can't just give it away for free.

Re: The mud client poll
 

I've certainly no objection to him making money from his client, I'm just pointing out that - from my perspective as a mud owner - I feel it makes more sense to invest my time into customising a client that's both free and open source. And my recommendation will influence which client new players decide to use when checking out my mud.

Re: The mud client poll
 

I see your point. What I tried to reply was that the benefit of a commercial client is that you have a developer that can spend a lot more time on the client than a hobbyist could.

If a standard protocol was made there would be little need to customize a specific client to your game though :).

Re: The mud client poll
 

If it's an open source client then you're not limited to "a" developer, nor indeed do you need to wait for other developers at all - if the client doesn't have a feature you want, and nobody else is willing to add it, you can go ahead and do it yourself.

There are a number of useful protocols out there, and a few clients that allow you to add your own - but you'll need something more if you want to offer a customised interface. That's where scripts and plugins come in. Several clients support these already, but they can end up becoming quite large projects in their own right, so you'll need to decide how best to use your time.

Re: The mud client poll
 

Assuming you know how to code. If you don't you could just pay the developer to add the feature :). The question really is if those people who moved from zMUD to MUSHclient were developers or just wanted to avoid paying for a client.

I think MXP has limited support for interfaces. Well limited as in frames, gauges, and status bars. With some fantasy you could imagine a protocol that supported a lot more - like some CSS/JavaScript but for MUD clients.

Re: The mud client poll
 

If the price is right, and they agree to do so. But if it's open source, you could pay any developer to add the feature.

They were players. But the point is they liked zMUD, and could no longer use it because of their operating system. I would hate to invest time and effort into developing a custom plugin only to discover that the client was no longer supported, and that players with newer operating systems could no longer use it. In effect, the client developer would be holding my plugin hostage. That is why I feel open source clients have an advantage when it comes to mud owners producing custom scripts and plugins.

Such features are indeed very limited - and rarely supported, even by clients that offer MXP. To be honest I'm not convinced the mud should even be controlling the interface to that degree anyway. What if the player wants to customise the interface themselves, adding their own graphics and layout?

Re: The mud client poll
 

Decided to pip in!

I primarily use MUSHClient -- I switch around systems alot, and it's extremely easy to just grab, install, and get going without a whole lot of hassle. It runs on all versions of Windows and is extremely easy to get going on Linux with wine. It has great "real estate" for maximizing and has some pretty straight-to-the-point options. I don't need a client that is designed to create the most elaborate bots ever, so this my favorite.

In the past, I used MudMaster 2000, but it became too difficult to download and no longer works well on modern systems.


When playing ArmageddonMUD, I would specifically use Portal. It's text writing feature allowed me to format and dump large chucks of text all at once, line by line, so it was incredibly useful for submitting character apps. The easy-to-use graphical bar was configurable with Armageddon's simple prompts so I saw no reason not to use it.

In fact, I would still be using Portal if it were not for the fact that it IS hard to open more than one MUD.

Re: The mud client poll
 

It should be noted that the "problem" with proprietary is that you get people not fixing things, including their documentation on the protocols. Zugg and Gammon had some discussion on, specifically, "What is the *correct* behavior for tags that are not included/defined? Can you generate a client side error, which the script can catch, and treat it as invalid, or do you ignore it, and let it pass through, as though it was plain text?" Zugg agreed, apparently, that it wasn't clear, but I dare you to show any page out there that explains what the behavior should in fact be, even if its adding one single sentence to the specification, such as, "When a tag is detected that is not defined, z/cMud's behavior of allowing it to show as plain text is the proper response." Gammon took the text, as stated in the spec, literally, and concluded, "This is an error, so you could treat it as one, instead of showing the text." Personally, I never really agreed, it screws up too many muds, coded by people that either don't have MXP enabled on them, and use <<Room name>> or the like, (if you force it on), or where they just didn't bother to read the specification "as written", but instead simply assumed that, since it worked anyway, they statement in the spec that says its invalid is irrelevant. But, its like the difference between using "strict" HTML, and the horrid mess we have had up until recently, where clients "guessed" what the proper response was, so that "something" showed up, even if it was completely written *dead* wrong. lol

And, that isn't even mentioning the fun trying to translate most forms of scripting between clients. ;) lol

Re: The mud client poll
 

No doubt. I use to use Z and like Cmud. Both are excellent clients.

Re: The mud client poll
 

The problem with open source is that normally there is a reason why they are open source. I've found alot of open source code to be very sloppy, poorly documented, and hashed together. I personally don't like working with it.

Re: The mud client poll
 

As far as I know the plugin system in zMUD wasn't used much. The main plugin that seemed to be used was MUDReader, but as zMUD and cMUD both support COM-calls it is easy to write a script that supports text-to-speech.

Then that would need to be supported by the protocol. If you don't need that kind of customization then you probably don't need to write a plugin. A script would probably do?

cMUD/zMUD also have that feature, and yes it is very useful :). Are Portal and zMUD/cMUD the only clients that support this?

MXP isn't perfect but it was a move in the right direction. What protocols similar to MXP would you say are open/standard and designed by the community, as well as having proper documentation?

Re: The mud client poll
 

Hmm. Pueblo, perhaps? Little known client, with the same concept that MXP had, *but* it intended to extend the client using standard HTML, where Zugg went a bit different. There are specialty HTML like commands added to it to support VRML, events, etc. Even a set up for "voice" channels, to well, use a mic to hear other players, apparently. It is now a Sourceforge project.

But, most mud developers "tend" to be purists, and some older systems, that where once introduced, but not often used, due to the small number of PCs that supported, for example, 256 custom colors, at the time, they got lost along the way. Also, with muds, some things fell aside, like say zmodem, which was a file transfer protocol, ironically, with the side effect being the use of often non-resumable, easy to misconfigure, not always reliable, and insufficiently self checking, FTP... One would have thought that, given the unreliability of networks when FTP was made, someone would have thought of those things, but...

Re: The mud client poll
 

I'm not sure how you'd compare the source code of an open source project with a closed source project, as you can't actually see the source code for the latter. All you can really do is compare the stability of the end products (eg Windows vs Linux). I'm not aware of any obvious decline in the quality of MUSHclient after it became open source - usually when people complain about a particular client being bloated and buggy I can guess which one they're talking about, and it's not MUSHclient.

Speaking personally, I know I sometimes cut corners if I know nobody else is going to see the code. If I'm opening something up to public scrutiny, however, I tend to be far more meticulous in my approach. Not just because I expect other people to use it, but also because poorly written and documented code would reflect badly on me.

I'm using here, where plugins are defined as "self-contained collections of related triggers, aliases, timers, variables and script routines...distributed as a single file, and installed by simply clicking on 'add' in the plugins dialog".

Although it might be nice to provide some sort of generic download protocol, you'd still effectively be using custom plugins - you'd just be distributing them (and associated graphics and sounds) directly through the mud (like an MMORPG client update) rather than the player having to do it manually. But someone would still need to write the plugin, which brings us back to the original concern; if I'm going to invest many hours of work into a custom plugin, I'd rather do it for an open source client.

As far as I'm aware, MXP is the only open protocol offering clickable links and 24-bit colour (I don't think any other clients support Pueblo links? Likewise, Primordiax seems to use its own method of adding links). You've got your XTerm 256 colours, which to be honest are probably enough for most people, but the links are a really nice feature - and I've not seen them in any other public protocols.

The other features are either too rarely supported to be worth adding, or better handled by other protocols (eg sounds and flags).

Re: The mud client poll
 

In order to reach a larger audience of both current players and new players, the concept of using a mishmash of useful protocols needs to disappear, and something standard between all servers and clients needs created. The best use of my time is certainly not trying to write plugins / scripts for the various clients out there so that users can experience my game as I intend. I believe there are a large number of folks that feel the same -- hence the use of custom Flash/Java clients on many MUDs. If we could all agree upon a widget set (minimap, status bars, button bars, etc), and a way to skin them, and allow that to be controlled by the server (similar to a web browser), then there would be no need to create "custom clients" with their "custom protocols". I could, as a MUD developer, write my game and I know users would experience it exactly the same, regardless of what MU* client they chose to use. At this time, there has been no widely supported, out-of-thebox, client supported display protocols outside of what MUDs originally used: ascii/text over telnet.


There have been projects to create and document standards (ie: mudstandards.org) -- but they seem to go down in a ball of flames.