Category Archives: Client

Building The Client On Linux

It’s been 3 years since I’ve tried to build the client on Linux. I started building the client long before there ever was a Basternae 3 project, and since then plenty of files have been added and removed — for instance, we no longer use Xerces-C or SDL in the project.  I was using Ubuntu 6.06 then, and now I’m on 9.04.

After updating the old makefile, I found there were a few minor issues. Of course there was the expected forward/back slash in filenames and that’s an easy fix. There were two that were a bit of a surprise:

warning: cannot pass objects of non-POD type ‘class wxString’ through ‘...’; call will abort at runtime

error: no matching function for call to ‘wxRichTextCtrl::AddPendingEvent(wxCommandEvent)’
/usr/include/wx-2.8/wx/event.h:2400: note: candidates are: void wxEvtHandler::AddPendingEvent(wxEvent&)

The first one is because I was passing wxString arguments to the wxString::Format function.  Visual Studio was smart enough to convert those to the char* type that printf commands understand for %s, while GCC doesn’t make any assumptions and does what you tell it to rather than what you intend. Differences like that have been known to start religious wars.  Adding .c_str() to the arguments in a dozen places sorted that out for me.

The second one was a bit of a stumper, and the folks at the wxWidgets Discussion Forum helped me out. I’ve dealt with a lot of user communities for various APIs and toolkits, and the wxWidgets folks have always been the most helpful and knowledgeable.

I was able to get the client to build.  I was even able to get it to run.  I could almost even use it.  Here’s a screenshot:

Basternae Client on Linux Screenshot

The main problem with it is that the input window doesn’t actually work — you can type until you’re blue in the face but nothing ever gets sent to the MUD.  Strangely enough, if you program a hotkey and click that, the text goes across fine.  I was able to clumsily log in and fight something using that method.  I’m sure there’s some OS-specific stuff in the key handler for the input window, but that probably won’t be too daunting to figure out.

Now I’m going to have to learn how to create Debian (.deb) installer packages so I can distribute the thing.  I might also have to figure out how to do .rpm, but since I don’t run a Redhat/Fedora-based version that might be a little low on the priority list, especially since I’d have to set up VM just to build/deploy it.  I might be the only one who uses Linux that would connect to Basternae anyhow.

It would also probably not be too tough to get this working for MacOS and Solaris, but since there’s zero chance of me having a Mac to work with and the only people who run Solaris work at Sun Microsystems, those aren’t really a priority.

First Release of the Basternae 3 Client (v0.11)

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:

Client status window screenshot.

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.

Some Solid Client Progress

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.

Client Screenshot

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

Equipment Window

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.

Hotkey Window

Hotkey Editing

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.

wxWidgets Client Resurrected

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.

New Release: Zeta Telnet Version 3

One of the first things I wrote when I was learning C# was a basic telnet client. It’s not like the world needed another telnet client, but it was a fun, easy project to learn the .NET socket libraries.

In the process of working on bug reports for Basternae 3, I found something annoying: Windows Vista doesn’t have a telnet client installed by default.  How silly.

Normally I use Putty as my telnet client. Since I was doing a lot of connecting and disconnecting during my code-build-boot-test-shutdown cycle, the fact that Putty closes the window every time the connection was lost became a little annoying.

I know I could just grab a copy of WinTin, but I felt like updating that old telnet client. So, here goes: Zeta Telnet Version 3. Grab it if you need a basic telnet client. If you need a full-fledged MUD client with aliases and the like, it’s not what you’re looking for.

Basternae 3 Test Port Currently Running

I have a test port of Basternae 3 running on port 4502.  This is only temporary for the purpose of testing.

Here’s a list of things that need to be tested.  Feel free to spend as little as 1 minute testing, or as long as the server is up.  I only plan to have it up for a few days or less.  Please report any results to xangis at the yahoo dot com email service.  One big email is far better than lots of little emails.  Also let me know the name you’d like to be listed in the credits as (up to you whether you want to use your handle/nickname or your real name).  As I receive testing reports I’ll post what sections of this list have been covered so there’s not too much overlap of effort between testers.

1. Tester: Create one character of each race and one of each class to make sure that:

– The help file/info is displayed properly for each race and makes sense.
– The help file/info is displayed properly for each class and makes sense.
– The character creation process is logical, sensible, and user-frieldy enough that someone who has never played a MUD could make sense of it.
– Nothing weird happens.
– Nothing looks too un-customized.
– You actually start in the Kobold Village instead of a room with no exits.
– Text formatting glitches are under control.

Report any ideas/suggestions/observances during the process.

2. Tester: Check help entries for all commands and report any that don’t exist.

The “commands” command will give you a list of the commands available.  “help <command_name>” should display the help for that command.

3. Tester: Check help entries for all skills and report any that don’t exist.

Type “skills” to show the skills available for your character.  “help <skill_name>” should display the help for that skill.

4. Tester: Check help entries for all spells and report any that don’t exist.

Type “spells” to show the spells available for your character.  “help <spell_name>” should display the help for that spell.

5. Tester: Test all spells available to you and report any that don’t work.

Until I have the “auto advance to max level” stuff going there’s not a whole lot you can test with this.  In addition, spellbook/scribe classes will have trouble.  Just do what you can.

6. Tester: Try all commands without arguments and report any that malfunction, fail to give any feedback, give badly-formatted responses, or give responses that look like a stock codebase.

For instance, try “score”, “attributes”, “who”, and any other commands shown when you type “commands”.

7. Tester: Try all socials and report any that malfunction, print output that is garbled or nonsensical, or looks like a stock codebase.

Type “socials” to get a list of the available socials.  Then try these different combinations with each social:
<social_name> me
<social_name> <some_mobile_in_the_room>

8. Tester:  Try combat and see whether you’re able to successfully kill a mobile.  If anything strange happens, report it.  This includes messages that don’t make sense, like getting kicked by a creature with no legs, bitten by a creature without a head, etc.

During the history of Basternae (1 through 3) there have been issues with combat round timing, corpse creation, and deathblows.  I’d like to identify any of those as early as possible.

9. Tester:  Try combat and see whether you’re able to successfully get killed by a mobile.

During the history of Basternae (1 through 3) there have been issues with combat round timing, corpse creation, and deathblows.  I’d like to identify any of those as early as possible.

10. Tester: Log in with two characters and see whether you can successfully kill another player in PvP combat.  If anything strange happens or if you’re unable to fight another player, report it.  Try with characters on the same racewar side (i.e. Troll vs. Ogre) and with characters on opposite racewar sides (i.e. Dwarf vs. Orc)

There’s all kinds of extra logic involved in PvP combat and there’s plenty of room for weirdness.

11. Tester: Check help entries for all bard songs and report any that don’t exist.

This assumes you’ll be able to create a Bard and that they actually have songs defined..  I haven’t tried.

12. Tester: Walk through a zone looking at mobiles, objects, and rooms and report anything that is formatted weird or doesn’t display properly.

Although issues of that nature are usually zone file related, it’s entirely possible that with our entirely-new socket and text formatting code that something will look wrong.

13. Tester: Download the Basternae client and try using it with Basternae 3.

It’s available here:

I know it’s only barely functional (none of the extra windows do anything yet), but it’d be nice to get a little feedback, and to know what it would require before you’d consider using it as your main MUD client (if you’d consider using it).  And, of course, if it doesn’t run on your main OS that’d be nice to know too.  It’s probably worth running it side-by-side with another MUD/telnet client to make sure that text comes across OK (it’s entirely likely that the text parser isn’t 100% right).  If anything looks wonky, screenshots might be helpful.

14. Tester: Download and try to use the Basternae zone editor and take note of what parts of it are confusing and/or unclear.

The basternae editor can be downloaded here:

There isn’t any documentation for the zone editor yet, so it might help to have some input as to what a new zone writer would want to know how to do and what guidelines should be made clear.  If you’re feeling really brave you could write a basic conceptual overview or intro tutorial.

The editor currently only runs on Windows and requires the .NET framework (you’ll already have it if you have Windows).

15: Tester:  Download the Basternae zone editor and try creating a 2-3 room zone with a mob, a quest, and an object.

Just try it out and see if it works, offer usability suggestions, and/or report anything weird.  Once you’re done, send me the test zone and I’ll see if it actually loads in the MUD engine.  Quality does not count — this is only a test.  You could create an entire zone if you want to, but I don’t recommend it until after these tests are done because there could be some breaking file format changes.

A few things to be aware of:

The code was written and compiled on Windows and is currently running on Linux under Mono.  Since Mono doesn’t have full support for everything in .NET there’s a chance something will go haywire at some point.  While doing some initial testing a few weeks ago I saw CPU usage on the server spike to 100% for no obvious reason.  If this happens, I’ll have to kill the process because I have about 15 or so other sites running on the server and I can’t let them be taken down.

I’m sure some of these tests will not really be able to be run effectively without some code changes/fixes.


The New Client In Action

In working on the new WPF-based client, I’ve redone the way I handle ANSI character code processing. Instead of a horrible multi-hundred-line nested if-statement-monster, I’ve created something based on regular expressions that is about 25 lines or so of code. It’s not absolutely perfect, but it’s already better than what we had with the wxWidgets + SDL client (what I call “Client #2”). (FYI: Client #1 was an SDL-only client that used a ridiculously huge amount of CPU and was unworkable in resolutions above 640×480).


There’s still plenty more work to do on the client.

The New Client So Far

It’s just screenshots of windows without anything in them — no fancy colors, images, or any bells and whistles yet.  This is just to show that it really exists:

.NET Basternae Client First Screenshot

C++ Is a Pain in the Arse (New Client)

Yesterday I opened up the source code for the Basternae Client in order to make a few changes, fixes, and updates.  What I had forgotten in the two years since I had been programming C++ actively is what a pain in the behind it is to get anything done in C++.

Sure, you can do anything with it, but there’s so much tedium and overhead involved that it takes forever to get anything done.  Sure, it’s great for low-level code where you’re tossing bits and bytes around, but for user interface development it’s just too unwieldy.

Out of frustration, I sat down and rewrote most of the client in C# in a few hours.  Mind you, it’s not fully implemented, but it’s usable as a telnet client.  I’d say about 8-10 more hours of development time and it’ll be ahead of where the other client was.

That makes this the third version of the client.  The first version was pure SDL with C++.  The second version was SDL combined with wxWidgets.  The third version is C#.NET and WPF.

Another benefit of switching to WPF is that the CPU utilization of the client has gone down tremendously, mainly because we’re using only one interface drawing library now.

Back From Vacation

OK, so maybe I didn’t announce the vacation in the first place, but I took some time off from working on Bast to enjoy the summer.

I’ve been working on the client a bit, and I had almost forgotten how much I dislike C++.  It’s just so messy and inefficient to work with.  You have to spend about 30% more time to get anything done and then once you’re done you have a pretty good chance of having to do some memory-based debugging.

Enough of the whining (because that’s what it is).  Just posting a note to let folks know work is continuing.

Client Progress

Most of the development for the past few days has been on the client application.

Here’s a screenshot giving an idea of what it looks like so far. It’s quite a bit different from what it looked like a few months ago:

Click on the image for a larger version. It obviously needs more work, but I’m liking it so far.

A Custom Client

I don’t believe I’ve mentioned it here yet, but around 2005-2007 wrote a custom MUD client using wxWidgets and SDL. It runs fairly well on Windows and tolerably on Linux (there are one or two glitches). I designed it to work with Duris and its prompt system. It shows maps for a zone if they’re available and keeps track of hits, mana, and moves via a meter system. The graphics are pretty simple, although I had planned to improve them a bit. This program was written from scratch and could form the basis for a custom hybrid 2-d/text-based Basternae client at some point.

Here’s a screenshot (while playing Duris):

(Click to enlarge)