Re: The mud client poll
 

TELNET

Because it was what I started with. I am of the pre-client generation. <g>

I have tried some clients of course. Zmud, POWWOW (still use for MUME since it has specials for that mud) or POWTTY (under Windoze). But all in all for nostalgia's sake (main reason I mud still) I prefer telnet. It's also clean and simple and lets me concentrate on the mud not the interface to the mud. The only thing I've ever missed while telnetting is the ability of a client to up arrow and repeat/edit a command. That's all. That's really the only good thing a client has to offer.

Hmmm actually I use MS-KERMIT a MS-DOS terminal program with its origins in 1989. It's mainly for kermit file transfers but it also functions as a telnet program. I have edited its keys to let me use the keypad as a shortcut to move. I am not sure that is possible with telnet. I guess it depends on what telnet. VAX telnet? UNIX telnet? Windoze telnet? I guess MS-KERMIT is DOS telnet with a few extras. Hmmm quite a few come to think of it. Session Logging, Keyboard redefinition, Scrollback. Okay I guess I should have voted OTHER! <rolls eyes> It's hardly plain telnet I just realized. I DID use plain telnet for many years.

Re: The mud client poll
 

I use kmuddy because i love the output windows and guages (have the chat channel fired off to another output window, took a bit of trigger tinkering and still get a few false positives but its getting there!)
i also parse the HP SP EP output to show a graphical guage of my health etc....

i have also used kildclient which is great too
and tf when im in a terminal
but i havent quite worked out how to get macros working in tf

Re: The mud client poll
 

This poll seriously sucks.

(I've since fallen hard for Mudlet)

Re: The mud client poll
 

Z/Cmud is the only one with all the features I need. Most notably spellcheck (with the little red underline -it's all that hides my idiocy from the world- and a split screen.

Re: The mud client poll
 

Beware if wards that ore spilled correctly bit stall wring.

;-) ;-) ;-)

Re: The mud client poll
 

Well... Mushclient has had spellcheck for a while now. Its also, recently, added scriptable windows, which includes graphics, as well as text, and finally, a plugin that uses these to run a mapper. Still some work going on with that, but it works, unlike the simple system that was in it before.

Re: The mud client poll
 

Does that translate to a split screen so easy a child can do it?

Re: The mud client poll
 

Well... Probably not. But the nice thing about it is the source is available, so someone that knew how to do that could. lol Mind, the first one to do so would have a harder time managing it. ;)

Re: The mud client poll
 

I was a longtime user of GMud. It was the first client introduced to me and did everything I needed, honestly. Whenever I bring someone new to the world of MUDding, I tell 'em to download GMud.

Now that I'm advanced in age (finally "heroed," heh), I wanted a client that could do more, something I could toy around with outside of the norm. I settled on MushClient.

I've dabbled with z/cMud...I honestly don't understand why anyone would use either one of those clients when you have to pay for them...and MushClient, at least to me, does more for free.

So I'm a fan.

Re: The mud client poll
 

Could someone make a better, more updated poll?

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.

Re: The mud client poll
 

I don't think that's necessary, nor even desirable. Not all muds wish to support links, or sound, or graphics, or data compression, or cursor movement, etc, etc. And while it can certainly be advantageous for a client to support a wide variety of protocols, many client developers simply lack the time or interest to add them all, or don't feel certain protocols are appropriate for their client. Bundling everything together into some "Universal Mud Protocol" won't suddenly cause all the client developers to implement it - it'll just result in a load of partial implementations.

In my opinion it's much easier to deal with a library of useful protocols, each serving a different purpose.

I believe the main advantage of browser clients is that they don't require the user to download, install and configure anything before they can play - i.e., it's a great way of lowering the entry barrier for new players. However for established players I would still prefer to offer a customised version of a well established and feature-rich client with years of development behind it.

You could already do that with some sort of generic plugin, and have it create the layout, maps, bars, buttons, etc, based on commands from the server. However the less generic you want your interface to be, the more complex the plugin (and instructions from the server) would become - you'd reach the point where it would be easier just to create a custom plugin for each game and provide a way for the client to automatically download and install it upon connection.

That's not a bad solution (and it's been discussed before), but I wouldn't want to force players to use my interface - I think they should have the option to create their own if they wish.

MXP has display options, it's just that most implementations don't include those features. ATCP and GMCP include a status sequence that's intended to be used for energy bars, but I'm not sure if any clients use it automatically. I would hope not, as that should really be left up to the user, and automatically adjusting their interface could interfere with other plugins they may have running.

There have been more? I thought MudStandards was the first. It's certainly gone quiet, but perhaps it'll pick up again.

Re: The mud client poll
 

I don't recall anyone ever saying that muds MUST support the new protocols. We have a least common denominator: text over telnet. If all you want to do is support that with your MUD, feel free. What I am recalling, though, is several folks wanting clients to support certain standard 'things'. The 'things' seem to be common across a lot of MUDs -- status bars, minimaps, menus, etc.

Generic plugins? So, you're telling me that plugin code I would write for MUSHClient will run without change and provide the identical user experience in other clients? I have yet to witness anything "generic" outside of telnet. What we currently have, as far as I know, is a huge amount of fragmentation across various clients that support various ways to do things( over and above Telnet). You might love that, but I think it stinks and is very inefficient.

Browser clients may indeed require zero install --- but I wasn't referring to browser clients only -- I am referring to "custom clients". And, as stated, there is a HUGE advantage to the developer in creating a custom client as it then provides the user experience that the developer wants.

Re: The mud client poll
 

This is actually a misnomer. Browser clients require zero install if and only if you have previously installed the browser updates and/or plugins required to run a browser client (which aren't really browser clients but really addon feature clients like java/flash).

I've yet to see a browser client that will run from a generic browser.

Re: The mud client poll
 

I was referring to your suggestion that "the concept of using a mishmash of useful protocols needs to disappear, and something standard between all servers and clients needs created" - my point being that "Not all muds wish to support" the various features such a protocol would include.

Thus I think it makes sense to offer a selection of different protocols for different things, rather than design a new Universal Mud Protocol that covers everything.

Sure, but I doubt they all want their bars, minimaps or menus to look the same. People go out of their way to avoid stock gameplay - but in many ways it's even more important for the interface, as that's the first thing new players will see when connecting to the mud.

No, I'm saying you could create a generic plugin that would provide "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)". You'd need to create different plugins for other clients, but that same plugin could service multiple muds - so if a player used MUSHclient and installed the plugin, their interface would automatically change depending on whether they were playing MUD X, MUD Y or MUD Z (assuming all three muds supported the plugin).

However, as I also mentioned, the plugin would become increasingly complex the more flexible you wanted it to be.

Actually you said "custom Flash/Java clients", which is why I assumed you were talking about browser-based clients. If the client needs to be downloaded then I don't think it has any real advantage over an existing client with a custom plugin.

You can already get that with a custom plugin - for much less work. Is there something in particular you want that an existing client can't do?

Well there's the and the , but most of them are tied to a specific mud (the version of FMud is particularly nice IMO).

Re: The mud client poll
 

I'm not advocating the creation of a universal mud protocol. We have one: telnet. ;-) We certainly do have a broad set of protocols to choose from. But, we do not have broad adoption of those protocols outside of telnet. I am referring to protocols like MXP/MSP/ATCP etc...

Er, yeah. I agree -- that's why I used the word "skinning" in an earlier post regarding components/widgets. ;-) It would be super neat if there was a skinning standard... a broadly accepted one.


Its a matter of broad adoption of things across multiple clients. Its not about what one or two existing clients can do. Why? Because I cannot guarantee what client a user is going to use(nor can I guarantee what plugin (s)he is going to use, given more than one plugin for a particular feature). Therefore, I cannot create an environment that is consistent throughout the playerbase. Web browsers used to be absolutely terrible in following standards -- now they are only somewhat terrible (and getting better!) But, at least they have some standards which developers can leverage and create cool things with. All without needing to create a plugin for IE, a hack for Chrome, another plugin for Safari, and yet another plugin for Mozilla ... just to implement a much desired DIV tag. Obviously my example is not real, but hopefully it illustrates the point.

Some of the things are so common (minimaps? health bars? login screens? inventories? menus?) that clients should probably provide standard and generic ways to instance, control and skin these widgets without needing people to write plugins. I think that if these things were broadly standardized, more people would code to them.

It would be super cool if clever game developers could write one set of standardized code to graphically render a minimap, status bars, a text output window/input bar, an inventory window, etc... and skin it all, and know that it would look, feel, and behave the same across all MUD clients(without being also required to write and maintain N plugins). If people turn off minimaps, whatever. At least I'd know the minimap would look the same for everyone who had it "on", regardless of what client they were in.

Broad adoption of the HTML/CSS standards would even go a looooong way. Any clients out there use webkit?

Re: The mud client poll
 

Don't know about standalone webkit clients, but there are PHP (PHUD) and JavaScript (Decaf, jMUD) browser clients that basically give you that I think.

Re: The mud client poll
 

Both are flash clients. There are no browser clients that do not require pre-installed add-ons. Which means, in affect, downloads and installs.

Re: The mud client poll
 

Support is , but several of the clients allow you to add your own protocols, so it shouldn't be hard to find one that meets your needs (this really comes back to my earlier point about muds recommending a particular client to their players).

Well if you developed a generic MUSHclient plugin as I described earlier, you could then do the same for Mudlet, CMUD, etc, with each plugin following the same standard. So it's certainly possible to do what you suggest - you'd just need to come up with a standard and a set of plugins. If the standard became popular, perhaps some clients would even add native support for it.

I'm not convinced that that's a major problem. If the player has to download a client anyway, then I think it's sufficient to offer them a "recommended" client. The fact that you also support other clients to some extent is really just a bonus - it means that players who already have a favourite client will be more likely to check your game out. Once they're hooked, they're more likely to be willing to download a different client, or perhaps even develop and distribute a new plugin for their preferred client.

No, the WGFriends client uses WebSockets, not Flash (although it does also offer a Flash fallback for browsers that don't support WebSockets). However Flash is so common that many people already have it installed - particularly if they play browser games. And even if they don't, they're not required to download something specific to your mud.

I would speculate that most first-time mudders these days are more likely to have Flash than even a basic telnet client, and the former can provide a far prettier interface, as well as look more familiar than a terminal window to today's generation.

Re: The mud client poll
 

YAUNWP.

;-) Newworlds, you kinda remind me of Donkey from Shrek....minus the comic relief. ;-)

Re: The mud client poll
 

Yeah, none of this discussion really explores a major problem. Its more a fact there is a desire amongst folks(including me) to see MUDs evolve a bit, especially in terms of the client. This is evidenced by the growing body of custom clients out there. And, maybe that's where it needs to end: with the custom client. *shrug* I just see huge opportunity for the MUD community to embrace a few more standards (yet to be defined?), which in turn will help developers on both the client and server sides work more with less effort. Depending on how far the standards would go, they should also increase usability of MUDs and help inject a lot more players into our shrinking/growing/whatever-your-metrics-tell-you playerbase.

Re: The mud client poll
 

Custom clients remind me a bit of custom web browsers. Years ago some websites actually recommended you what web browser you should use to be able to properly view them. Today that is very rare. You can use a range of different web browsers.

A very big benefit of supporting many MUD clients is that it makes it easier for the players. E.g with zMUD/cMUD you can play on many different MUDs and the software keeps track of them for you. A player also doesn't have to install multiple clients so they can focus to learn the features of one.

Re: The mud client poll
 

I share that desire, but I'm primarily a server developer, and my time is a finite resource. I would rather customise a popular, well-established and feature-rich client that's already had decades of hard work poured into it than create yet another mud client from scratch.

And how many of those custom clients can match the features offered by the big clients?

Throwing away decades of feature development? That sounds like a step backwards to me.

Re: The mud client poll
 

Okay, lets back up the assumption wagon a bit, here. Who says "Throw away decades of feature development"? Actually, what are those decades of features you're not interested in throwing away? I have no idea how creating some new standards by which client developers and server developers should adhere to is a step backwards. Substitute "create" with "adopt" and it's still something else....an addition... an evolution. Which would you prefer? A standard way to display, skin, and control a status bar which would work in all clients that support the standard or come up with your own protocol, select a client, write a plugin for it, and call it a day? In the former, your game will provide the experience you want your players to feel, across all clients(hey! Minimal work for you as a server dev). In the later, your game will provide the experience you want your players to feel in only that one client, and only if they installed your *custom* plugin (Hey! Lots of work for you if you want broad client use).

I guess this does illustrate a major problem: coming up with standards and more importantly, getting client and server developers to implement/conform to said standards. I'm guessing its not gonna happen. That's why I said "that's where it needs to end:..." --- because the real standard is simply telnet. If you want to offer more, then you're free to with your own custom coding/client/plugin/control/mind bending technology/widgeting-ding-a-ling.

It would be cool to see what features are important to players --- and why. Same for developers. You might find that some of those current client features which represent decades of feature development become obsolete when replaced with standards and proper UI elements.

Whatever the case, I'm feeling like a broken record. There are blatant, obvious reasons MUD devs are creating custom clients for their games... and that reason is not hubris.

Re: The mud client poll
 

Perhaps, but when I dumbed down my IE it wouldn't run either of those clients within the browser. Still your point is taken that almost everyone has flash, but flash and java are not part of the install package and are seperate systems/patches.

Re: The mud client poll
 

See here:

If you're developing a custom client rather than customising an established one, then that means missing out on the decades of development and testing that have gone into those established clients.

Things like aliases, hotkeys, triggers, command-execution timing, variables, multi-session support, cross-platform support, ansi/256/24-bit colour, speed-walking, extensive scripting in multiple languages, macros, regex, toolbars, smooth scrolling, scrollback, logging, customisable fonts and colours, compression, chat, built-in text editor, configurable output buffer and text wrapping, debugging tools, text hyperlinks, spell checker, tab completion, configurable command window and input options, mapper, autosay, open protocol support, configurable sounds, NAWS, TTYPE, ECHO, fully customisable graphical skins (including buttons, energy bars, avatars, icons, mouse hotspots, etc), and so on and so forth. Not to mention the years of extensive testing by many, many users.

Of course it wouldn't, why would you think that? My comment was a direct reply to this statement:

If people decide that "the best use of [their] time is certainly not trying to write plugins / scripts for the various clients out there", but is instead to develop their own custom clients from scratch, then they're losing out on decades of development and testing. That is what I consider a step backwards.

I can understand people wanting to create their own client for legal reasons, or because they want it to run from a browser (not much available to reuse in terms of browser-based mud clients), or even just because they enjoy the challenge. But reinventing the wheel just for the sake of it? I can think of better things to do with my time.

Of course I'd prefer it if my plugin worked on multiple clients, but I can't realistically see that happening. What you could do is what I mentioned previously - design a standard for skinning, and create plugins for multiple clients that support the standard. Then any server that added support for the standard could indeed offer the same interface to multiple clients without the need to create any further plugins. No doubt some people would still prefer to design their own plugins, adding things that aren't covered by the generic plugin, but perhaps it would be useful as a backup option for clients you didn't explicitly support, or for muds that lack the skill or desire to do any work outside of the server itself.

Yes, getting client and server developers to agree on implementing a standard is very hard. However the plugin approach sidesteps the client developers entirely (anyone can create the plugins), and if you're already a server developer then you could use your own mud as the prototype for the standard, and/or release a snippet for other server developers to use.

Actually I suspect hubris may be one of the reasons. Others include those I mentioned earlier - legal concerns (particularly for commercial muds), wanting it to run from a browser, or simply for the challenge. Or perhaps just an unawareness of what modern clients are capable of?

Re: The mud client poll
 

Personally, when thinking about implimenting something for Mushclient, back before it got added, I had the thought of using markup to create the "layout" of the design you wanted, then either download that, or have the mud send it. The problem I ran into is that you have to create all custom controls. Why? Because MS doesn't even try to make it easy to use "design mode" for controls, outside their own IDE environments, and that assumes you are using controls that recognize it anyway. Worse, one reason to go with something like Lua, instead of tying the client to something in .NET, or COM, is to, at least in principle, allow someone to port it with a bit less insane recoding. Using Windows "native" system for controls kind of screws that, especially if you actually got design mode to work at all.

I have a vague sense how you could, but its... not documented in anything like a direct fashion. Its more like knowing that you can install front wheel drive, but having *never* seen how the whole system ties into the steering, or being able to find a manual showing how to do it right. Knowing the general idea of how it should isn't the same as actually being able to build it. :( I drove myself nuts for a while trying to find "anything" clearer than the vague hint buried in MS' own site (and their non-working link to a demo that supposedly used it), before giving up on the whole idea.

In any case, in general, the best solution is "likely" to take something that already has a huge set of features, and works fast, then try to work out how to correct some of its.. oddities. For example, ages ago you could find "fast" text clients for muds, which supported similar features, including scripting and triggers, but also supported text positioning, which Mushclient doesn't. Its not trivial, but not impossible either, everything in existence that is designed to do rich text *has to* be able to remap a document, if you delete internal tags, change the text, or page up/down. This isn't "much" different than what you need to adjust both the buffer display, and what is on the page. In the case of the old days, ones like Telemate, basically recorded the "final" state of a line, once it was no longer on a page, and treated pages just like page breaks in a document editor.

Point being, you could take an existing client, port it to something less platform dependant, as long as it was designed to start with to be that way, then just add the things that are missing. But, only for the open source ones. ;)

Flash... Seriously, I watch movies via that, and used for that, it seems to *eventually* lag what ever it is in, until it either slows the whole system down, or crashes the browser. It has known problems. An interesting alternative seems to be PHP, with java, which, interestingly, has even been used to make things like EyeOS, which is an entire virtual desktop, which runs in the browser. However, Flash is so annoyingly ubiquitous that it even shows up there, for things where it is "easier". So is, imho, trying to use a skate board and a rope, tied to someone else's car, compared to actually having to drive one, but... lol

Re: The mud client poll
 

Couldn't you do it in MUSHclient by discarding the text window, and diverting the output to a miniwindow?

Re: The mud client poll
 

Not.. Efficiently. The mini-window isn't designed for it at all, and coding the extra stuff in script, to handle paging.. It would really have to be done more directly, in the main window, not via scripting, I think. Mind, not a lot of muds actually use the stuff anyway, its just a tiny few that do, and its often buried in the prompt systems (like changing the line of the prompt to update time, or something, without sending an entire new prompt), etc. Its not necessary to even have the feature, but its damned annoying for it to be missing, if you a) need it, or b) want to connect to something running an older game. An example might be trying to run TW2002, via a mud client, so you can take advantage of its scripting ability. It was written for dialup, it works, with some help, via Telnet, but almost nothing in existence supports **all** of the text control functions in ANSI, while also having any sort of complex script system, of any kind at all. FSM forbid someone got it into their head to do some of that stuff on a mud, and found that 99% of the clients either don't support it well (there is no protocol for asking, "Do you support all of ANSI, of just bits of it?", really, and certainly not color, but not cursor movement codes, since the former was added later than the "more critical" cursor controls...), or work poorly, or are almost feature non-existent, if they did.

Re: The mud client poll
 

TinTin++ supports full ANSI (typically called VT100), character mode, complex scripting, and runs on all major platforms.

Re: The mud client poll
 

Hmm, sounds like a winner and we're not even promoting TinTin on the NWA website with some other clients we promote. Send me a PM or email with download/contact info Scandum and perhaps we'll add it.:)