Basternae.org

I have no clue how to build a .deb or .rpm package yet, so it’s just a .zip for now.

Though I have it working on my own Ubuntu 9 machine, I haven’t the faintest idea whether the client will run on other Linux boxen. At the very least, you’ll probably need to have the wxWidgets 2.8 libraries installed to run the client on Linux. I suppose at some point I’ll figure out how to build installer packages.

Version 0.14 of the client for Linux is now available for download. Hopefully there’s someone who can try it and let me know the result. In this case, it’ll probably be “I had to add libraries X and Y and Z before it would run”. Then again, since wxWidgets is so widely used on Linux (VLC, Audacity, etc), chances are good that most people will already have the necessary pieces installed.

I fixed the “can’t send text” problem in the client for the Mac and Linux versions.  There are still some text problems that only show up in non-Windows versions, but I was able to log in and play for a bit without much trouble.

Though I have it working on my own machine, I haven’t the faintest idea whether the client will run on other Macs.  I’ve created an application bundle and compiled it in a way that it should supposedly run on OSX 10.5 and 10.6, but I only have 10.6, so no idea whether it will work.  And, since my machine is set up as a developer machine I have no idea whether a “normal” user’s machine will have all the libraries it needs.  That’s the trouble with being a Mac “noob”.

Version 0.14 of the client for Mac is now available for download.  Hopefully there’s someone who can try it and let me know the result.

I tracked down a nasty threading problem in the status window that would explode things horribly at random intervals. Version 0.14 of the client is now available.  That’s not to say there isn’t the possibility of other horrible explosions lying around just waiting to leap out… so let me know if you find any.

Version 0.13 of the client is now available.  Cleaned up one or two things with text processing and added command scrollback (where you can push the up arrow to retrieve previous commands).  As always, let me know of any glitches you find.

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:

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.

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.

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.

I have a test port of Basternae 3 running on basternae.org 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>
<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:  http://www.basternae.org/BasternaeClientPreview_08-04-09.exe

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: http://www.basternae.org/Basternae3EditorSetup_v0.39.exe

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.

THIS IS NOT A FULLY FUNCTIONAL MUD.  THIS IS JUST SO I CAN BUILD MY “TO DO” LIST OF THINGS THAT MUST BE FIXED OR REWRITTEN.