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]

Originally Posted by 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...

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.

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

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]

Originally Posted by Violette What is speed dependent on?

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

Not the answer you were looking for NO?

[Zeno]

Speed = Velocity

Uh. No? :P

[Zhiroc]

Originally Posted by The_Fury Speed = Velocity / Time usually expressed as M/S-1 Not the answer you were looking for NO?

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]

Originally Posted by 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

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.

Originally Posted by 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 ArcticMUD . 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 ArcticMUD .

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:

Download JMC

[unpunished]

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

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]

Originally Posted by Violette ...do you have a picture?

He is extremely camera shy, but this may be the guy.
[img]
http://tintin.sf.net/download/scandum.jpg
[/img]

[Zhiroc]

Originally Posted by shadowfyr 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.

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 Mudlet, 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:
How to use Miniwindows in MUSHclient

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.

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.

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.

[Fiendish]

Originally Posted by 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.

The Atlantis website appears to have been just about completely inactive for the past few months. I hope that development hasn't stopped, but, if it has, other more full-featured clients will work in OS X on an Intel Mac through WINE or in a virtual machine.

[scandum]

Originally Posted by Fiendish 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.

It's more like calling a help desk, you'll find that in 90% of the cases the guy on the other side is either stupid, or thinks that you are stupid..

[Fiendish]

Originally Posted by scandum It's more like calling a help desk, you'll find that in 90% of the cases the guy on the other side is either stupid, or thinks that you are stupid..

Typically when one calls a help desk it's because there is an expectation that the person at the help desk knows more or has better resources available. I fail to see where you're going with this, however. To what does "It" refer?

[jackal59mo2]

Originally Posted by Fiendish The Atlantis website appears to have been just about completely inactive for the past few months. I hope that development hasn't stopped, but, if it has, other more full-featured clients will work in OS X on an Intel Mac through WINE or in a virtual machine.

While it's certainly possible that Sparks might have to stop development on Atlantis at some point, doing so without making a very clear announcement would be quite a bit out of character. Also, a quick look at the Atlantis/Riverdark forums doesn't show abnormal "inactivity." It was six months from the last version to this most recent (June) one, so I think four months without a release shouldn't be much cause for worry.

However, if someone wants other Mac options, there's also Trebuchet. I don't like its user interface, but it may be alright for most. And, there's TinyFugue. Neither of those are clients I'd use, but at least neither of them require setting up and running WINE (talk about potentially flaky development) or a virtual machine. For that matter, someone could install Windows through BootCamp and running MUSHClient in Windows... but why go to all that trouble for text on a screen?

[scandum]

Originally Posted by jackal59mo2 However, if someone wants other Mac options, there's also Trebuchet. I don't like its user interface, but it may be alright for most. And, there's TinyFugue.

A universal OS X binary is available for tintin++ and quite a few Mac users have been very enthusiastic about it.

Haven't both Trebuchet and Tinyfugue been out of development for over a decade.

[jackal59mo2]

Originally Posted by scandum A universal OS X binary is available for tintin++ and quite a few Mac users have been very enthusiastic about it. Haven't both Trebuchet and Tinyfugue been out of development for over a decade.

Thanks for the reminder about tintin++, but as far as the others - no, they haven't been out of development that long. It would be hard for software that runs on Mac OS X to be over a decade old, since that OS was not publicly released until 2001. Stuff from before then that has not been updated won't run on a Mac. That's the problem with Rapscallion, which The Mac OS MUD Zone: Clients says existed only in a "half-Carbonized" (i.e., rewritten for OS X) version when development was abandoned back in 2003.

Sourceforge gives the latest version of Trebuchet for MacOS as Dec 03 2005, and the latest version of TinyFugue is from Jan 14 07 for 5.0 beta 8 (I can't find the date for the 4.x stable version). It looks like tintin++ certainly has them beat as far as current updates, but I have used both and found that they work at least as recently as MacOS 10.4. Of course, even Savitar works, kind of; it just makes me sick to use an application with a GUI design that would have looked like ass on Windows 3.1.

[Disillusionist]

I use gMud for a whole host of untenable reasons:

1. It's free.
2. I started using it probably 15 years ago, and I'm a relentless creature of habit.
3. After playing a bajillion muds on it, all with macro sets, aliases, preset login output, etc, I'm too lazy to translate all that data from one client to another.
4. I used an older unsupported version of zMud for a while, and all the bells and whistles didn't do much more for my actual play experience than the act of taking up hard drive space.
5. I've found or created a hack or two for it that makes up for its dearth of font choices, and a few other shortcomings.
6. I can live without a pause feature in my scripting, although it IS a pain.

[scandum]

Originally Posted by jackal59mo2 It would be hard for software that runs on Mac OS X to be over a decade old, since that OS was not publicly released until 2001. Stuff from before then that has not been updated won't run on a Mac.

Most C programs written for Linux compile on OS X without too much trouble, even if over a decade old.

Sourceforge gives the latest version of Trebuchet for MacOS as Dec 03 2005, and the latest version of TinyFugue is from Jan 14 07 for 5.0 beta 8 (I can't find the date for the 4.x stable version).

Trebuchet is indeed more recent than I thought. The 4.x stable version is from 1999, which I guess means that 5.x has been in beta for 9 years now. Maybe Hawkeye is going for a world record of some sort?

[Mugo]

Where is tintin on that list! I use it because it quick as heck and i run osX so I use x11 as a shell. 1 window = main, 2.window = tells/gsays/says/assosciation etc. (tail -f chat.txt) :P

Tintin is great because its quick and simple. If I want to edit my warrior I use my fav txt editor to edit warrior.tt and go to town. Save. #load warrior.tt = bingo .. no rebooting or any BS :P

My 3 cents!

[Zeno]

Originally Posted by Mugo Wow, where the *ck is tintin on that list?

It's just a MUD client poll, jeez.