The mud client poll
 

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

Re: The mud client poll
 

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

Re: The mud client poll
 

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

Re: The mud client poll
 

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.

Re: The mud client poll
 

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?

Re: The mud client poll
 

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

Not the answer you were looking for NO?

Re: The mud client poll
 

Uh. No? :P

Re: The mud client poll
 

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

Re: The mud client poll
 

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

Re: The mud client poll
 

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.

Re: The mud client poll
 

...do you have a picture?

Re: The mud client poll
 

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++)

Re: The mud client poll
 

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:

Re: The mud client poll
 

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!

Re: The mud client poll
 

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.

Re: The mud client poll
 

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

Re: The mud client poll
 

Re: The mud client poll
 

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.

Re: The mud client poll
 

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.

Re: The mud client poll
 

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.

Re: The mud client poll
 

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.

Re: The mud client poll
 

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

Re: The mud client poll
 

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?

Re: The mud client poll
 

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?

Re: The mud client poll
 

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.

Re: The mud client poll
 

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

Re: The mud client poll
 

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.

Re: The mud client poll
 

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

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?

Re: The mud client poll
 

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!

Re: The mud client poll
 

It's just a MUD client poll, jeez.

Re: The mud client poll
 

Hmm sorry! I was going by the most mainstream mud clients, but totally forgot about TinTin. Forgot about the Mac clients too. And I guess no one uses 'telnet' really unless they're forced to. Darn, there's no way to edit that poll.

Re: The mud client poll
 

Its ok. Don't worry .. we all know that Telnet is the way of the future! *duck

Re: The mud client poll
 

I use something called SecureCRT to log on to the shell, and then I use the shell to log on to the Mud.
It isn't a Mudclient, but it's good for building, which is basically all that interests me.

To tell the truth, I never used a Mudclient in my life.
I used to mud with plain telnet back in the old days. I used to have a crappy and really expensive dial-up connection back then too.

Re: The mud client poll
 

Yeah, shell programs are all you need for building. Putty, Secure CRT, X11 (for mac) .. I actually run tintin using multiple x11 windows.

Was actually quite useful on multi-play day on my fav mud. See screenshot :P

Re: The mud client poll
 

I play using JMC(Jaba Mud Client). I used GMud when I first began MUDing but moved into JMC because of the neat little scripts you can create with it. ZMud has some nice script properties but was just too confusing and too much to go through. Also, it seemed odd that JMC wasn't even listed and yet telnet was lol. Okay, maybe not odd just a little funny IMO.

Re: The mud client poll
 

Never heard of a JMC, so I took a look.

Is it lacking on a lot of features, or did I miss them? Aliases? Multiple worlds open? Triggers?

Re: The mud client poll
 

Zeno,

It looks like you missed something. The original (Runglish) help files for JMC are a pain to read; Jaba was (and is) a brilliant programmer but not a native English speaker (to say the least).

Certainly, JMC has aliases and triggers (the latter are called #actions). In fact, it was developed to be fully compatible with tintin++ and that was one of the reasons I choosed JMC when switching from a Unix station to a Windows box. Further on, JMC was the very first client to implement some powerful features (e.g. active scripting).

Jaba retired several years ago and opened the source code for the client. However, there are other groups of developers that keep working on JMC. You may have a look at:



P.S. Just as a historical fact, Jaba was an active player in ArcticMUD in ~1996-2003. Back at that time, other clients were lacking many important features and JMC was originally written just as a powerful client for personal use. I remember at least 2 or 3 other ArcticMUD players who also implemented their own clients, but unlike JMC, those applications were never made public domain and remained unknown to the MUD community.

Re: The mud client poll
 

I use tintin++. It works most of the time. Although I hate when #split messes up sometimes.

Re: The mud client poll
 

Wintin95 and the newest version Wintin.NET are used by at least 50% of our player base. Of course one of our creators was the developer but .net has everything a person could want from a client!

Re: The mud client poll
 

I use jmc - jaba mud client. I have tried zmud and tintin++ but jmc is the ****! Btw I didn't know that jmc 3.5 exists! :D I was using 3.26 all the time. I am very curious about the fact that jmc is open source because I might be wanting to write a couple of modifications for it :)

Re: The mud client poll
 

CMUD, hands down. Mushclient is a quality client as far as its featureset is concerned but can not compare to cmud in terms of user interface.

Re: The mud client poll
 

zMUD on Vista. Don't see a need to upgrade to CMud.

zMUD above all the others listed, because of the breadth of options possible, gauges, DDE to Excel, databases, etc. All honey for power users. :)

Re: The mud client poll
 

There is an irony in that. The whole point of a non-shared variable space, or more specifically plugins, in the first place was to "prevent" interference between different sections of code, which might be using the same variables, for one reason or other. You can end up with a lot of problems when that happens. It does create some complications when passing data between different scripts, but there are methods to do it, and they are like most applications, in that they are "specific" to implementation, not just, "Through it all in the same basket and don't worry about what happens." We used to have code run in a single space, as one language, just in the master script, but, due to how it worked, it was a) hard to add to, b) could clobber existing variables, and c) if injected via a trigger or such, existed only temporarily in the code space, while executing, unless you created a function to call (it was these temporary injections that caused errors in data, since someone throwing together a scrap of code might use 'count' for something, only someone's script, added in earlier to the main file, also used it, and thus the injected code would screw up what ever the master script was trying to track.

In short, we concluded that this was actually a "disadvantage", and suggested strongly that it shouldn't happen. The only real drawback is that you then have to treat your scripts are "actual" separate code, and create a function to a) register compatible plugins with each other, b) process data passed between them, into the correct data space for the plugin that needs it. Hardly a huge problem, though perhaps initially complicated, since there is no "standard" code to do those things. The biggest issue has been load order, where if the plugin that needs to load last doesn't, it can lose track of what is loaded or not. But, the solution has been to simply have it ask on connect, or some other condition, where all plugins "must" have been loaded already. Though.. I think I might have an idea on that...

Re: The mud client poll
 

I mainly use kmuddy, but starting to play with Mudlet more. is a new, open source and cross platform, client that uses Lua for scripting. Pretty darn fast too.

Re: The mud client poll
 

It's good to see a new client being worked on, particularly as its cross platform, however AFAIK it doesn't yet support MXP which is a deal breaker for me. There's often discussion about ways we can enhance the presentation of MUD output and, while it is far from perfect, MXP is a well established way to do that.

Re: The mud client poll
 

Strangely enough...I actually use telnet. Oh, and Wintin95. :p

Unlike a lot of the Mudders that I know, I do not require triggers, macros or any other type of convenience. I've been using telnet, or some type of java-connector, for about...ten to eleven years. *shrugs*

I reckon it's all upon what you need. I don't need all the fancy bells and whistles to have a good time.

Re: The mud client poll
 

tintin++ because it's fast, powerful, and runs on linux.

Re: The mud client poll
 

Well I chose MUSH. My first few muds had their own clients (Darkness Falls on AOL and Gemstone/Dragonrealms)

Later I think I moved to Threshold who supported cMud - I think. Soon after a tried several other clients. I played a game where macros and scripts were needed for the boring stuff (the grind) in between the fun stuff (the RP), so I tried Zmud like everyone else had. I found it a little too much for me at the time. Plus, as a broke teen I didn't want to pay.

I moved to MUSHClient after a long time and I've never looked back. Back in the day, I never paid for it, but now that I actually have income coming in, I'd like to donate. It's a great client and infact, it is one of the reasons I started to like programming. After trying to figure out how to make scripts for Lusternia in Lua, I became curious and started learning more.

Also, I like that you can be in several different worlds at once without opening several clients. Its a godsend when playing two slow moving MUSHes.

Also, I've read the MUSHClient is pretty fast. When dealing with combat in the IRE games, it seems that the speed of the client pays a big difference. I wouldn't know from personal experience as my scripts were just for bashing and (trying to) keep my characters alive if I should happen into to combat by accident.

Anyway, MUSHclient is the best!

Re: The mud client poll
 

I voted RoA... but I also use Midpssh on the blackberry

Re: The mud client poll
 

I'm old school, so I'm using Gmud. Never ran into much trouble with it, so never needed to look for a replacement.