Tag: mushclient

The portals to your adventure

by Tharius

When you journey to the Realms of Despair what portal transports you? Do you use the web based client at http://realmsofdespair.com? Do you log in through a piece of software like CMud, TinTin, or Mushclient? Maybe you’re using a mobile device and BlowTorch is more to your liking.

In 2014 I wrote a draft article called SMAUG HTTP. I never published it because I knew that the tremendous effort needed to convert the game engine that runs the Realms of Despair from a Telnet server to a HTTP based engine was unlikely to gain support. I speak only as an outside observer but I imagine that any of the handful of coders active on Realms would rather put their time into changes that will add more fun and adventure. Not at all an unreasonable point of view!

I abandoned that idea and looked at the Realms Web Client, which I think has been a phenomenal tool for allowing new players to experience Realms without undertaking the burden of installing and configuring a new client. It just doesn’t fit with today’s model of how software is delivered, does it?

When I started on Realms the idea of downloading software and spending an hour getting it set up before I played for 1 minute was absolutely standard. Now you log into a web portal and if you can’t have an account inside a few minutes, pfffft, next!

The problem we have in our community is that we are past the peak era when lots of people were actively contributing to projects. Not just SMAUG itself, but also the clients that are available. Zuggsoft hasn’t issued a new version of CMud since 2011 and seems very unlikely to do so. Mushclient was more recently updated in 2019 and is well supported on the forums. TinTin is in active development with the hopes of converting it to a commercial project.

The problem becomes that each has strengths and weaknesses and none of them hit it out of the park. CMud has a mapper that is hard to beat, and a relatively friendly window system, along with robust scripting capabilities. On the down side it is Windows only and full of very irritating memory/file corruption bugs. If you’re like me and able to work around those issues, it’s hard to beat. I may be biased, I started with Zmud more than 20 years ago, and the old dog likes to make maps.

Mushclient is, in my opinion, the most stable piece of Windows mud client software available with top notch scripting capabilities. Written by Nick Gammon the client makes it very easy to create a structure to share scripts between characters and suffers from no corruption issues I’ve ever encountered. I’ve used it for my bots and been very happy with it. Unlike CMud it’s much harder to see the active state of memory if your variables are involved, but like anything that is a trade off that can be worked around.

Most of its files are text based making for easy sharing and easy backups. The menus are not bad, once you get used to where everything is. I made a serious attempt to move to Mushclient full time but I just couldn’t live without the interactive automapper. Nick … if you’re listening, let’s talk about it 🙂

TinTin is an older product that has had new life breathed into it. Myrr reached out to me about getting involved with using it, and introduced me to it’s mapper. Like Mushclient its mapper is of limited interactivity. It records things that CMud’s does not, like terrain type, and attempts to auto generate a graphical map, which is very fun, but is ultimately more difficult to extract information out of than either of CMud or Mushclient. I think this is because this one is available on multiple operating systems and has a distinct linux feel to it. If you’ve been living in that command line world with no windows available then this one might be up your alley. It lacks new user friendliness, even setting it up for the first time is non-obvious. The names of files you need to edit aren’t documented and you find yourself on the Discord channel feeling like a fool trying to get the thing running at times, but I applaud the author’s determination to revive the software and make it not only useful, but progressive.

All of these products are computer based. I’ve used a couple of different mobile technologies which I’ve blogged about before. The biggest thing to say about playing Realms on mobile is that you better set up buttons for things. Where you can argue that fast typing can get you away from macros or triggers on a PC, even the finest Bluetooth keyboard is going to be a pain for mudding on a phone. Not introductory level, but absolutely cool once you’re ready for it.

Which brings us back to the Realms client. I’ve used it many times and though it suffers from some of the critiques I mentioned on the other clients it has the distinct advantage of being web based. Fire up a browser and go. It is developed and supported by the people who are working on Realms and so feature wise it can be tailored exactly to our game. I genuinely believe that it has the potential to be the client of choice for our player base.

To create an experimental development environment I asked some of my students to create a HTML5 Websocket client that could connect to Realms to try to play around with it and they did in just a couple of months time. Another project team chose to work on a web based mapping software for Realms that could read and render CMud’s map files. Another success. Bringing these ideas together and then expanding on them further could make the Realms client top notch.

I think that there are questions about this though, for example I have no idea how much server overhead administering the client creates. The client itself runs on your device, but it has to be back ended by a Realms server. Not only that but the original point I made about developer’s time … any time spent on reinventing the wheel with a client is time away from expanding the game itself.

I saw a recent TS vote pass that suggested multiple characters connected through the web client. This was part of my student’s project as well. We know that players need multi-character support. Whether it should be added to the Realms client comes down to the intention of that client: is it a vehicle to get people to try the game and then they will be vested to install a stand alone client, or is it an opportunity to demonstrate the full capabilities of a custom SMAUG installation on a 25+ year old adventure game?

Maybe there is a possibility of custom web clients in the same way people used to make stand alone executables. This one is problematic because you’d have to trust the person running the client not to steal your passwords or you’d have to have your own online database that you configure a connection to … we’ve done some stuff like this using DropBox or Google shared drives to sync our CMud profiles across computers, so it might not be that far fetched. Update (2020-08-05): One possible work around to the trusting someone with your passwords problem raised here has already been solved in industry. If the Realms server were willing to provide a third party login authentication service in a similar way that you can log in “using your Facebook account” to other sites, this could keep the control of your password between you and the Realms site while allowing a custom browser client to be built by third parties.

I still think the Realms client has great potential. If only the escape key would clear my input bar ala Z/CMud and not disconnect me routinely.

Have fun, stay safe!

Configuring Mushclient

by Tharius

(This is the second in a serial describing my experience with migrating from Zmud/Cmud to MushClient)

In the last article I talked about installing Mush and some basic thoughts about how I was going to lay out my characters in this new environment.  This post will go through getting some templates set up that will eventually be copied to create those characters.  I’m using a template because in fact there are very few characters I use that I need triggers specific to that character.  Almost every trigger I have I’d prefer to have on most of my characters, give or take some variations for race or class.

For those who would like a way to easily download the files and not go through the pain of doing this all by hand I will make a link available at the end of the series with a default basic configuration.

Ok, so I created a new world. This is going to be the basis of all my class specific templates, it’ll need to be tailored as I go along but I can set a bunch of stuff that I want to be the same in all of them.  These settings are under the World Properties link in the Files menu.

I fill in the world name as Realms of Despair and the address as realmsofdespair.com. Next I go down to output and up the lines in the output buffer to 20k… I like a lot of scroll back for extended afk sessions. :> While I’m on this tab I hit Auto-wrap to window size and copy selection to clipboard.

Under input->commands I change echo my input in to a pale yellow (I think it default uses grey … I’m very used to the yellow and I look for it). Let’s go ahead and enable spam protection every 19 identical commands send “spam”. As a Cmud person I’m tempted to change the speedwalking prefix from “#” to “.” but for now I’m going to simply leave it disabled. I’m sure I’ll circle back to this one, the problem is that # is not only the repeat command in Zmud but the command command … like #LOOP or #CONNECT … which I won’t be able to simulate here regardless. .5swen in Zmud would work exactly as #5swen would work here (I think). I’ll skip speedwalking for now. I’m just not sure heh. I am sure I need to turn command stacking on and may as well keep “;” since it’s pretty universal.

Down to input->keypad to check off “Escape Deletes Typing” and “Ctrl+Z goes to End of Output Window” to make it feel zMudish … which when button mashing on a run will be important … hmmm… not too sure about changing the arrow key defaults for now, so I’ll leave them until I have a reason to double check. Onward we go down to keypad. Here the 5 key is useless to me, so I want to change it to look instead of who. I’m also changing the * to stand and . to rest and 0 and / I’m going to blank out for the moment. I may revisit these since they’re not keys I’ve used in the past.

Finally I flip down to scripts … as I said when planning my layout I want to have each character have it’s own set of local variables. The kicker to it is that I need the same information from every character, but I will set that up as a trigger in the usual way instead of using the World Events… Also though I need the same information on each character, I’ll go through the same procedure to gather the information on each character. So it’s better suited to a global connection plugin. What I want to change here is that I have downloaded LuaEdit as an editor and I’m going to use that instead of the default built-in editor. If you’re not planning to do a LOT of script writing, I wouldn’t bother with that.  I’ll also click note errors to make sure my script errors don’t give me a pop up box and mess something up later but rather show up in the normal scroll. I’m going to go ahead and fill in a script prefix here too… now this is where I’m tempted to use something like “#” from Zmud since it’ll have a similar functionality … but since it’s going to let me run Lua scripting from the command line I’m going to break with habits and use “/” instead. I won’t set the external script file just yet as this is the per world (character) scripting and I’ll fill it in as I create characters if the variables don’t save with the world file (or if I need a one off trigger for a particular character).

We can close the settings up now and move on to setting up a default plug-in.  This is where the global triggers are gong to go.  We don’t have to build the triggers now, but we want the world to know about the plug-in name.  I decided to do one “Tharius’ Realms of Despair” plug in instead of a list of them that are more modular and encapsulate one function (for example equipment damage monitor).  The fact is that the latter approach makes a lot more sense, however, there are so many ways I can think of to split things off that in the interests of keeping things moving along I’ll go with a catch all Realms plug-in and will re-factor it down the road.  This is more of a programmer/distributing my triggers decision.  For the average user it shouldn’t be an issue.  Besides it’s easy to move things into their own file later on.  I plan to go ahead and make class and race plug-ins separately, we’ll come to that.

Ok, so I’ll quickly whip up an empty plug-in and add it to this world, and them I’m ready to start making the class files.  I use the plug-in wizard to create an almost empty plugin.  The only thing in it is the help alias 🙂  I’ll add to this file later on extensively.  I won’t rely on the plugin retaining state because I’m going to have the variables in the per character configurations.  I told it to include the standard Lua constants, I’m not sure if that’s the way to go, but I can remove them later if need be.  I clicked ok to get out the wizard, added the plug-in to the world and immediately noticed an error.  When I moved my directories I didn’t move the contents of the default plug-in directory to my new directory.  If you didn’t move your folders then you won’t see this error, but I did so I have to go to the hard drive and move them to my new folder.  Error went away so I went ahead and saved the world.  I chose not to use the global plug in option because I am creating everything from scratch here. If I had to add something later on down the road then I suppose I might use it.  Also there’s always the chance I won’t want it in world, like a build port or some other mud (gasp) at some point so this gives me a little more fine tuned control over things.

Ok.  From here I want to have a plug in with class specific triggers for each class.  I take my default template and make copies of it for each class (RoD-Thief, RoD-Cleric, etc).  Once I’ve got them all I opened each world, one at a time, created an empty plug in with the class name (ThariRanger, ThariDruid, ThariClassname…) saved it to the hard drive, added it to my class specific world and saved and closed the world.  I also went ahead an opened a world so I could create files for each race but I didn’t add them to any world yet because that’s something that will be far too character specific to do in any good, general way.

That’s it for today.  I made a back up of this whole structure, and will make it available in the next blog post where I start adding some basic triggers.  Right now I have 14 worlds, 1 default and 13 class specific, 1 generic RoD plug-in, 13 plug-ins for classes and 14 for races.  It seems like a lot but that’s the majority of the file creation finished.  Next comes adding characters to Mush and then trigger writing.  Stay tuned … (in not out!!)

Migrating from Zmud/Cmud to MushClient … a rambling adventure

by Tharius

So here we go, at long last, I will make the jump into the MushClient world.  This started out as a project for the guild bot characters so that they could access my databases but it’s grown. It has taken so long because I’ve been inordinately busy with life and school and also because I could not get the server configuration I wanted working (I still cannot but I will!!). Instead I’m forging ahead with my current setup but I’ll add all my functionality and transfer it at a later date.

For those who are not interested in installing and configuring MushClient very little of interest will appear in the next few blog posts.  My initial post was far too long to keep in one piece and so I’ve split it up into several steps.  You may find the discussion of triggers interesting when we get there or may wish to read for ideas on how to refresh your own client of choice’s setup.  Either way, once I’ve accomplished this it’s well past time to go back and reflect on all the guild turmoil of the last few months.

For background’s sake, I have been a long time Zmud user and recent Cmud convert. I loved Zmud back in the day, it did all I wanted it to. The mapping system draws me back time and again. I just cannot keep it stable on my Windows 7/8 systems. I purchased Cmud since it was pretty stable … until I started pushing it. Now I can crash it by rearranging the windows. There is no doubt in my mind that it has a few memory leaks or fails to do some sort of garbage collection. The problem grows the longer you use it or the more windows you open and close. I’m not even touching how often my character setting files corrupt or the fact that I can’t open character A without disconnecting character B. I’m ready for a reinstall … but I know I’ll be back to this point in a couple months. The straw that breaks the camel’s back is that Zugg is no longer developing the software. If he were then I might hang in there in optimistic faith that the bugs and glitches would get sorted out but the fact is that it’s a business and he’s not making any money at it anymore. I say that without judgement, it’s got to either be something you love or something that pays … when it’s neither it becomes a burden. I wanted to add database support to my bots and discovered I would have to pay more for Cmud pro … to do something that is available in a free Lua library that is not provided by Zugg at all.  Next I want to play with MDSP and a graphical interface similar to what KaVir or Sepharoth worked on some time ago.

I guess these things contribute to my breaking point. I read a rant about Zmud users not wanting to buy Cmud even though it was an overhaul … I am not in that category, I paid for both. I’ve used both. I’ll keep using them both for specialty tasks for the time being… but bring on MushClient by Nick Gammon.

My first experience installing Mush under Windows 7 wasn’t pretty. It turned me off Mush enough that it took an ordermate extolling it’s virtues to convince me to try again. The new 4.84 installer is MUCH better. Ignore most of the instructions on the Mushclient website, grab that installer, change your paths to point to somewhere you can find them, install that old winhelp if you like and bang, you’re up and running.  I stopped at the global preferences, rearranged a few directories, tick off the reconnect on disconnect button and I’m up and running.

Next is to set up a world.  This bit of terminology tripped me up since I think of world=mud.  Here we’re using world=character.  You can use world=mud but then you will lose the ability to enjoy the autoconnect features.  The one character, one world setup works for me and how I do my triggers.  The world file will have all the variables about the particular character and I will bring in my (for example) THIEF trigger set as a plug-in and let the triggers use the variables.  This way I can share my triggers without my variables messing anyone else up and of course all my (example) thieves will have uniform triggers but don’t have to have uniform equipment or setups, etc.  More on triggers later.

For now, how to organize things.  I only play one mud, so I don’t need a separate folder for Realms of Despair characters but do I want to lump all my characters in one folder or split them up?  My instinct is to split them up.  In Cmud I could rename the icons to things like “Tharius – Ranger” and “Lareawan – Thief” … or in time I just used seperate icons for each class so lumping them in one window was fine, I could glance about and find what I wanted but here in MushClient I’m only presented with a Windows open file dialogue.  I loathe it 🙂  Things like this go on my “it’s open source, if you hate it that much then write some code” list.  Anyway, I dislike this because I cannot dynamically rearrange my listing to suit whatever piece of information I’m trying to extract.  Usually I want them sorted by class then by name … I can accomplish that by filename but if they’re in folders I won’t be able to re-sort them quickly by last connect date … or whatever …  So at the end of the day I won’t bother with folders, and I’ll use file names like Thief – Lareawan so that I can use the Windows file explorer to sort by name or date or whatever I want … I need to go back and check off “Save world on exit” so that it will properly save the time stamps but other than that, we’re off to the races, as long as that doesn’t show up in the window title bar, we’re good.

 

(Next time, configuring the world … default setup and getting ready for a mass character import)