[shadowfyr]

Back in the day I was looking for a client that would do what I wanted, without being slow, supported the widest set of features, didn't crash, and wouldn't cost anything to use. Mushclient you could use without paying, with just a nag screen, was really fast (sorry, but speed matters to more than how fast the stupid server can process things, and the estimate of 4 commands a second isn't necessarilly accurate), it supported a mess of stuff, and, at the time, VBscript was the major language it uses, which I knew pretty well. Since then, its gone all Lua for its "default" language, since it can be directly integrated, without relying on the ActiveScript system, so it will run perfectly under WINE in most cases (few odd versions that it won't, but not sure why exactly), which means if I ever make the complete switch to Linux, I don't lose the client. If Zugg ever got around to making a decision about what the specification for MXP actually "says", and made his client conform to it, Mushclient would be right behind him (but, for now, Mushclient treats syntax errors as "errors", not as stuff to be dropped through to the client without processing, something the specification implies, but no one, including cMud/Zmud follow.) The only things that I considered "missing" where ways to design your own windows, for displaying specific sorts of information, and some way to edit plugins, like the regular internalize per-world aliases and such can be. It just recently added a mess of stuff that can do most of the former, though, not quite in the way I had hoped, while the later... you still have to edit in an external editor.

But, those plugins are one of its most powerful features, since they combine the existing ability of some clients to load in a mess of code, to create new functionality, with the ability to "enclose" that code in its own execution space. In other words, in most clients, if you use a variable in patch A, and you also use it in patch B, the two will mess with each others variables. With Mushclient's plugins, the two batches of code can't even "see" each others variables, unless you use functions to explicitely pass the values between them.

Oh, and, one things even cMud/zMud probably can't do.. You can edit incoming data, down to the packet level, and pass it back into the parser, so that if something from the mud is formatted a way you don't like, uses the wrong colors, or contains data your plugins need, but which would have otherwise been lost through the MXP process, or color decoding, etc., you can retrieve or alter the result. Heck, you can even write a plugin to help people play a mud, if you wanted, that would "look like" it was coming from the mud, complete with the ability of the person to write triggers to match on its contents, react to what it displays, etc. If you use the functions to process your own plugin generated lines, like it came from the mud, the users scripts, can tell the difference. A mud developer could make a "helper", that would run entirely on the client end, which could watch the person play, and make its own suggestions, without needing it to be on the server side, or even code an extended "newbie" area, which helps them learn to use the client itself, as one of a collection of "plugins" to be installed for the game, without using server bandwidth or resources, or even connecting first. If someone wanted to do that.

Sometimes what this client can do is just nuts.