I’ve made a couple minor updates to the client.  First, the status window wasn’t clearing the tank and enemy condition bars when there was no tank or enemy combatant.  That’s fixed.

Next, I’ve added what appears to be working support for aliases.  They’re created accessed using the “#alias” command (#al for short).  They cannot yet be saved/loaded, but they do stay in memory as long as the client is open.  Saving/loading is probably the next thing I’ll work on.

Here’s an example:

You can download it here.

You should be able to tell from the version number that it’s far from done yet.

I spent some time working on the status window, and it now appears to work more-or-less as intended:

There are a handful of issues I know about, and probably a good solid handful that I don’t know about, so feel free to report anything that is broken that you wouldn’t expect to be broken in a partially-done MUD client.

I’m also curious to know what this client would have to do for you to give up your current favorite MUD client, whether it be ZMud, WinTin, tintin++, or some other app.  I’ll throw one out there — before I’d be willing to use it as my main client it would have to support aliases, all those extra newlines that show up in the main window would have to go away, and room description formatting would have to be less wonky.

The cool thing about having our own client is that we’re no longer just restricted to 16 colors of ANSI text.  We could do 2-D graphics (i.e. the sample tiled map that shows when you first run the app — since we don’t have surface maps yet it won’t do anything, but hey..)  We could do any number of colors.  We could do anything we have the skills and motivation for.

I don’t at any point plan to make this client mandatory — you should always be able to play with Windows Telnet.  It’s just going to be there for those who want the “full experience”.  Tinker with it imagine some neat possibilities that I wouldn’t have thought of yet.

You can either click on the link in the sidebar (which will always have the most current version), or you can get it HERE.  There are no real instructions, but you’ll get the hang of it.  The other dialogs can be shown with the “View” menu.

Over the past two days I’ve made some good progress on the client.  It’s now working with colored text and functioning scrollback.  There was a bit of difficulty in figuring out how to post text from the network thread to the main window, but that’s been solved thanks to the helpful folks at the wxWidgets forums.

The equipment window works now, but the equipment names are not in color yet:

The earlier screenshots of the client just had some placeholder text — now it actually processes your equipment list and displays it.

The hotkey (hot button) window also works — you right click to set a command and a hotkey name.  When you click the button the command is sent.

The prompt processing and room info display still needs some work, but it’s coming along nicely.  I haven’t even started on the group info window yet.  I think it may be about three solid days away from being able to release a test version, but I can’t recall the last time I’ve been able to get in a “solid” day of development.  Usually it’s anywhere from one half to four hours at a time.

As I mentioned in my post yesterday, not being able to support scrollback with the client was a problem in the wxWidgets-based version. This is because it used the Simple DirectMedia Layer (SDL) for the text rendering, and that just has a 2-D panel that text can be rendered to. Adding scrollback to that kind of system would be a large amount of effort.

Since the original development on the client was started back in 2005, wxWidgets has added the wxRichTextCtrl control, which lets you create rich text box — as in, a text box that has color, images, and all sorts of happy goodness like that.

I spent some time ripping out all of the SDL portions of the client and replacing them with the rich text control. The end result is that it does everything it did before, but has scrollback, uses less CPU, and has less memory copying going on (which means fewer possible points of failure). It still needs some tuning, but it already uses five fewer code files than the previous attempt.