Plain and simple: who uses what AND WHY (particulary if you voted "None of the above")

[unpunished]

Most definitely CMud, I've tried just about every other one listed here and CMud is my absolute favorite. Next on my list would be MUSHClient...

[Aeran]

It would be interesting if people write why they prefer a specific client as well.

[Zeno]

I use MUSHclient. It's free, open source, has a ton of features, is still being developed and has great support.

zMUD/cMUD is too bloated and doesn't even follow its own specifications (MXP). Plus it costs money. I've tried Portal, but you can't even open 2 MUDs at once unless you open the program multiple times. GMUD obviously don't compare to other clients as it is missing a ton of features. Roaclient is no longer worked on.

I'll have to look into Mudmaster, I don't think I've tried that.

I've tried so hard to find a replacement to Mushclient.
There's nothing wrong with it, I just don't like to use what everyone else uses.
But I've given up. It's just so user friendly, appealing, and fast.

P.S.: It's possibly the fastest mud client, right? Is that because of the way it's coded? What is speed dependent on?

[The_Fury]

Speed = Velocity / Time usually expressed as M/S-1

Not the answer you were looking for NO?

[Zeno]

Uh. No? :P

[Zhiroc]

And not right either

You could write: Speed = | Velocity | (meaning the magnitude of the velocity vector)
or: Speed = Distance / Time (M/S or M * S^-1)

And to further the physics lesson : Acceleration = Velocity / Time

[The_Fury]

Speed is scalar quality and velocity is vector quality, the difference is that velocity requires a direction and speed does not. So you are correct in that i gave the wrong formula, Speed is equal to distance over time s = d/t

[scandum]

Your typical mud parses input 4 times per second. Given how horribly slow that is it doesn't matter much if a mud client is ultra fast or not, as long as it doesn't hang.

I'm using TinTin++, it's as robust as a basic telnet client, doesn't have needless bells and whistles, and has a powerful yet easy to learn scripting language. As an added bonus the developer happens to be a very cool and handsome guy, and it rubs off on the client.

...do you have a picture?

[nikolausv]

You don't need a picture, Scandum doesn't lie, and he's right about his charm rubbing off on Tintin++.
Of course he's standing on a few guys shoulders, but all the best 'works' are collaborations.

(Bias: Yes, I use Tintin++)

[nasredin]

Back in 1997, when I started my mudding career, I was using a UNIX station and thus tintin was a natural choice. As an added bonus, a lot of my friends also used tintin, so we could exchange triggers and other useful things.

When I had to switch to M$ Window$, I certainly wanted to keep using my tintin configuration files, so my next natual choice was JMC. At the moment (in ~1999-2000), it was one of the most advanced clients, with lots of powerful features, including active scripting.

There was more to it than just that. The author of JMC, Sergey Il'in is my real life friend; in fact, he was the person who introduced me to mudding and . In real life, he is a team leader in a software company and a guru programmer. Thus, when he said "all MUD clients suck, I had to write one of my own", I didn't question his opinion.

BTW, JMC stands for Jaba MUD Client, not java MUD client, as many erroneously think. 'Jaba' means 'a toad' in Russian and it was the name of Sergey's most famous character in .

JMC is no longer developed by the original author, but it's freeware and open source, anyone may edit the code and add new features to it. I'm still using the latest version by the original author, though:

[unpunished]

Indeed, how very silly of me. The reasonI prefer CMud is actually due to the extensive feature set and scripting language, so I suppose in response to Zeno I prefer the "bloated" features to the other clients where those features aren't and probably never will be implemented. Truthfully I have been away in recent years and just recently returned to hang around a bit, I don't play MUDs anymore.

And before anyone says anything, yes I do realize MUSHClient among others has scriptability through languages such as vbscript, python etc. Though the only client I could find using python was MUDMagic's, but it was poorly implemented. If anyone could point me in the direction of one that does that would be great!

[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.

[unpunished]

Ah, I didn't realize MUSHClient began supporting LUA. That is excellent news! Perhaps I will take a look back that way then, MUSHClient is what I used to like and support several years ago

[scandum]

[Zhiroc]

I use zMUD at the moment, because it has (so far) won out on the ability to script. I think the class structure and multistate triggers make for very flexible and easy scripting, and while zScript isn't what I would prefer in a language, it can do just about everything you need. It also has the equivalent of array and associative array variables, and that too is powerful, though I'm sure that Lua has the appropriate equivalents. But one of the advantages of the way z/CMUD has done it is that the "data space" is independent of the scripting engine, which allows data to be shared no matter whether Lua or zScript is used. The mapper (while I no longer use it much, as I MUSH almost exclusively where it isn't all that important) is unequaled.

CMUD adds in Lua integration while keeping the z/CMUD variable types, but I haven't switched yet because I don't feel like converting what I need to, and to figure out how to get the packaging system to work like I need.

But as for the above, in z/CMUD anything you get from the MUD can be edited for content and colors, and whatever you change it to is passed along to other triggers, so yes, you can change incoming data, maybe not down to the packet level (though z/CMUD lets you make ANSI triggers that see the escape sequences, and CMUD has ATCP triggers, I think). You can also make up output yourself, which also gets passed through the other triggers.

I once wrote a system for Into the Black's HSpace system, which would totally autopilot a trip from launch to landing, following the waypoints, course correcting, and jumping. This was done by interpreting the "head's up display" output.

On the horizon, though is something called , which I am following with great interest.

[Fiendish]

One of the more recently developed features of MUSHclient that has since won me over from being a long time zMUD user is the ability to draw graphics directly to the screen.
It's detailed here:


Also, Nick's clear willingness to keep improving MUSHclient after giving it away for free and releasing all the source is a quality that is hard to find elsewhere.

Wrong, wrong, wrong. The heartbeat of a MUD is irrelevant. What matters in terms of trigger activation is the connection speed. Most MUDs can send text very rapidly in large chunks. If I receive 1000 lines in a second, it doesn't matter that the lines all came from a single pulse. Furthermore, the extent of what you might want to do with a script doesn't need to stop at sending strings back and forth to the MUD. You might want to, for example, animate global maps. That sort of activity becomes visibly affected by client parse and redraw times unless certain actions are taken in the client.

If you think that speed doesn't matter then you either don't have an eye for detail, are hampered by an underperforming MUD server, or are just thinking too small. Possibly a combination of the three. Any of these mean you have lower expectations for script fluidity and power than I do.

[jackal59mo2]

I use Atlantis, which is far and away the best client I've found for Mac OS X. It is stable, easy to configure, and regularly updated.

By the way, if you run a game, please stop telling Mac users to use Rapscallion, which hasn't been updated in eight years and won't run on the current operating system except as a cobbled-together port. Recommending it is like telling people that they should only access your Web page using Netscape Navigator 3.0.