Yearly Archives: 2008

Zone Reset Modes

In  the old days of Basternae 2, there were really only two area reset (repopulation) modes — either an area would repop at a fixed interval, or the area wouldn’t reset until all players had left.

In the process of rewriting the way areas reset themselves for the new game engine, I’ve added a few more reset types that might make for some fun zones:

  • Empty of Mobiles:  The zone won’t reset until every monster in the zone has been killed.
  • Empty of Objects:  The zone won’t reset until every takeable object has been removed from the zone.
  • All Quests Completed:  The zone won’t reset until all quests inside the zone have been completed.

The way things are done it’ll be pretty easy to add new conditions if the theme of the zone requires it.

Real Progress on the Editor

Now that I’ve started trying to use the zone editor I’m finding all sorts of things to fix and/or improve.  I’m not sure how long it’ll be before I can get a small zone put together using it, but it’s getting quite close to usable.  Far from pretty, but usable.

HTML Help Workshop = Epic Fail.

Anyone who has wondered why the help systems in Windows applications are typically so abysmal has to look no further than Microsoft’s HTML Help Workshop. Not only is rotting tripe more pleasant to deal with, it’s more likely to help you get the job done.

You’d think that maybe an application designed for editing help files would have a decent help system. Not so.

After trying to figure out the interface to HTML Help Workshop and failing (after getting screens full of incomprehensible errors) I went in search of an application with a less counterintuitive interface. I found HelpNDoc. It looks a lot prettier, but it’s also completely incomprehensible. It might not be all that bad, but after my HHW-induced brain meltdown I just didn’t have the patience to decrypt the interface.

I guess if you were meant to be able to get useful information out of the help files for an application they would have made it easy. Failures like Microsoft HHW are why the software training industry is a massive cash cow.

I ended up falling back on the manual method — creating the index, table of contents, and individual topic files by hand. This is the same method I used when creating the help files for PixelSwapper. To put it in perspective, having to do so is just as retarded as writing a letter to your congresscritter using a hex editor because your word processing program is too terrible to use.

Luckily the file formats are well-documented. Not so much by Microsoft, but by the folks who made the Win32 API usable — wxWidgets. I’ve used wxWidgets extensively, and if you’re going to write an app for Windows without using .NET it’s the only sane way to go. Down the path of pure Win32 lies madness. Yes, the Windows API was designed by Cthulhu. Luckily he has since moved on to the world of embedded design and development (cellphones mostly), so post-Win32 Windows programming is no longer painful.

Better String Visualization in VS2005

The text visualizer in Visual Studio 2005 isn’t very good. When you’re looking at a string in the debugger, you won’t see what you’re looking for if there are any null characters in the string. As far as I can tell this is a holdover from the bad old days when null-terminated C strings were the norm.

This is a pain in the butt if you are dealing with data stored in a System.String. I regularly work with data that needs to be viewed in hexadecimal format. That’s why I created the hex string visualizer, thanks to THIS POST by 4 Guys From Rolla, which is a mighty fine tutorial on creating visualizer plugins.

Here’s what the not-so-informative text visualizer looks like:

Here’s what my hex string visualizer looks like:

I’ll leave it as an exercise to the reader to figure out which one gives better debugging info.

This is more useful in my day job as a home automation programmer, but it will also come in handy when it comes to debugging low-level communications in the MUD.

It’s available HERE if you want a copy. Just drop it in your My Documents\Visual Studio 2005\Visualizers directory and it’ll be available in the list of string visualizers next time you run Visual Studio 2005.

A Help Entry Editor

Editing help file entries has always been a pain, mainly because it’s always been a huge unorganized text file that has to be edited by hand.

I spent about an hour and a half building a simple help file editing application today. It will load/save help files, allow searching and browsing of entries, and of course, editing.

It’s nothing fancy, but it does make the task of editing help entries a little easier. It doesn’t have visualization for colorized help screens, but that would be easy enough to add.

Here’s a looksee:

Help Editor Screenshot

(Click the image for a full view).

Improving The Zone Editor

Over the past couple days I’ve done quite a bit of work on the mob and object editing screens in the editor.  I also found and fixed a few problems with the area converter.

The hard part of building the zone editor is going to be adding the map-based and walkthrough visualization modes.  They aren’t needed for building an area, but they will help quite a bit with visualization and layout.  I haven’t put much thought into how I’m going to go about implementing those features, but it’s something I can worry about a bit later, once I have the zone editor fully functional (which shouldn’t be too much longer).

Smashin’ More Bugs

Now that the communication routines are a lot smoother I’ve been able to test and debug more of the rewritten code.  I fixed a bug in the new command interpreter and one in the string builder today.  I also came up with a better way of handling per-area repop points so it’ll be a lot easier to set up new hometowns with race/class spawn points, especially since I’ve added repop point editing to the zone editor.

A Day Of Bugfixes

I spent today working through a handful of bugs in the new communication code in the MUD engine and fixing a few problems in the Basternae version 2-to-3 zone converter.  Some of the text formatting still needs some work, but things are a *LOT* better now than they were before, especially with the network portions running smoothly and reliably now.

Now would probably be a fine time for a line count on the project:

Main Codebase:
98,868 lines total
77,254 lines of code (78%)
8,375 lines of comments (8%)
1,261 mixed (code + comment) lines (1%)
11,978 blank lines (12%)

Editor:
8,191 lines total
6,350 lines of code (77%)
1,446 lines of comments (17%)
8 mixed (code + comment) lines (0%)
387 blank lines (4%)

MUD Screen Editor:
1,137 Lines Total
876 Lines of code (77%)
185 lines of comments (16%)
0 mixed (code + comment) lines (0%)
76 blank lines (6%)

Since we last checked in, the editor has just shy of doubled its lines of code while the core codebase has shrunk a little thanks to a bit of recent code cleanup.

An ANSI Screen Editor

One of the things that was always a pain in the butt was creating and editing the ANSI color screens for the MUD intro, race and class selection screens, and the menu. With our new screen format it was actually pretty easy to build an editor specifically for Basternae screens. I spent a few hours today and here’s what I came up with:

MUD Screen Editor screenshot

(click for full image)

It’s nothing spectacular, but it does make the task of editing MUD screens a little easier. Since applications like TheDraw and ACIDDraw have been just about completely lost to the sands of time (and they were DOS apps anyway — yuk!), it’s hard to find an ANSI screen editor that will run in Windows these days (this runs on Vista and XP).

With the built-in “import” and “export” options it can actually be used to edit any ANSI screen. It only does foreground text colors, but it should do for now. I expect I’ll release it as freeware soonish since other MUD admins might find it useful even though the file format is specific to Basternae.

UPDATE: Yep, released it here: http://findmud.com/mud-screen-editor

A Few Fixes

I found and fixed a few minor bugs in the core MUD engine today.  I also found and destroyed some duplicate code and unused functions.

I’m not sure, but I think about May might be a good time to put a server up.  It’d just be for development until the game was in a playable state (read: had enough zones to make it worth playing).

A Bit More On The Editor

I spent a while working on the zone editor again today, and the quest editing section is complete.  Even though the version numbers I’m using are completely arbitrary, the editor is now at version 0.14.

Flag Editing in the Zone Editor

There’s a ton of things in the MUD engine that use flags. Rather than go through and create a separate dialog box to edit each batch of flags, I’ve come up with a way that just lets me tell the flag editor dialog what type of flags it’s using and it will fetch them and populate itself. That means it only takes a few lines of code to be able to edit the flags on a mob/object/room/shop/exit/etc.

Here’s an example:

private void btnEditExtraFlags_Click( object sender, EventArgs e )
{
int value = 0;
bool parsed = Int32.TryParse( txtExtraFlags.Text, out value );
FlagEditor editor = new FlagEditor( FlagType.item_flags, value, 0 );
DialogResult result = editor.ShowDialog();
if( result == DialogResult.OK )
{
txtExtraFlags.Text = editor.Value.ToString();
}
}

This means that something that would have been an entire class (probably >150 lines of code for each set of flags) is now reduced to <10 lines of code per item.

Here’s the resulting dialog:

Flag Editor Screenshot

There’s a fair amount of behind-the-scenes code, but it’s still pretty easy and efficient.  With this change I’m pretty far along on the zone editor.  Sometime in early March I hope to be able to create a working mini-zone with it.  After I declare it usable I’ll make it available for download.

A Self-Populating .NET About Box

One thing that has always been a little annoying is updating/changing the about box every time the program version or date changes. Here’s a neat little way to make it pull the values from the assembly info:

private void aboutToolStripMenuItem_Click(object sender, EventArgs e)
{
Assembly assembly = Assembly.GetExecutingAssembly();
AssemblyCopyrightAttribute copyright =
(AssemblyCopyrightAttribute)AssemblyCopyrightAttribute.GetCustomAttribute(
assembly, typeof( AssemblyCopyrightAttribute ) );
AssemblyTitleAttribute title =
(AssemblyTitleAttribute)AssemblyTitleAttribute.GetCustomAttribute(
assembly, typeof( AssemblyTitleAttribute ) );
System.IO.FileInfo info = new System.IO.FileInfo( assembly.Location );
DateTime date = info.LastWriteTime;

MessageBox.Show(
title.Title +
” version ” +
assembly.GetName().Version.ToString() +
” released ” +
date.ToShortDateString() +
“.\nThis application is ” +
copyright.Copyright +
“\nWritten by Jason Champion (Xangis).\nFor the latest version, visit http://www.basternae.org.”,
“About ” + title.Title );
}

With the following AssemblyInfo:

[assembly: AssemblyTitle(“Basternae Editor”)]
[assembly: AssemblyCopyright(“Copyright © 2006-2008 Zeta Centauri, Inc.”)]
[assembly: AssemblyVersion(“0.9.0.0”)]

We get the following about box:

About Box Screenshot

It’s pretty easy to customize it to grab other assembly attributes once you know how to retrieve them.

Got The .NET

Not much to report today, but I picked up the basternae.net domain.  Now the full trilogy points here (.com, .net, and .org).  Yippee!

An Inelegantly Elegant Solution

One problem I’ve had to solve in building the Basternae zone editor is the conversion of Basternae-style colorized strings into something that will display properly in a GUI.

Apparently text boxes aren’t smart enough to decipher Basternae-style text color codes (&+R, &n, &+y, etc.). In fact, there’s only really one control in the standard .NET forms library that supports multcolored text — the RichTextBox.

In order to use this RichTextBox, I’ve had to write a routine to convert all of the Basternae color strings into RTF format. Here’s the code:

public static void BuildRTFString(string text, RichTextBox target)
{
// Add header and build color table.
string rtfHeader = “{\\rtf\\ansi{\\colortbl\\red192\\green192\\blue192;\\red0\\green0\\blue0;
\\red0\\green0\\blue255;\\red0\\green255\\blue255;\\red0\\green255\\blue0;
\\red255\\green0\\blue255;\\red255\\green0\\blue0;\\red255\\green255\\blue0;
\\red255\\green255\\blue255;\\red0\\green0\\blue128;\\red0\\green128\\blue128;
\\red0\\green128\\blue0;\\red128\\green0\\blue128;\\red128\\green0\blue0;
\\red128\\green128\\blue0;\\red128\\green128\\blue128;\\red192\\green192\\blue192;
}\\cf0 “;
// Replace each color one by one.
string parsedText = text.Replace(“&+l”, “\\cf1 “);
parsedText = parsedText.Replace(“&+B”, “\\cf2 “);
parsedText = parsedText.Replace(“&+C”, “\\cf3 “);
parsedText = parsedText.Replace(“&+G”, “\\cf4 “);
parsedText = parsedText.Replace(“&+M”, “\\cf5 “);
parsedText = parsedText.Replace(“&+R”, “\\cf6 “);
parsedText = parsedText.Replace(“&+Y”, “\\cf7 “);
parsedText = parsedText.Replace(“&+W”, “\\cf8 “);
parsedText = parsedText.Replace(“&+b”, “\\cf9 “);
parsedText = parsedText.Replace(“&+c”, “\\cf10 “);
parsedText = parsedText.Replace(“&+g”, “\\cf11 “);
parsedText = parsedText.Replace(“&+m”, “\\cf12 “);
parsedText = parsedText.Replace(“&+r”, “\\cf13 “);
parsedText = parsedText.Replace(“&+y”, “\\cf14 “);
parsedText = parsedText.Replace(“&+L”, “\\cf15 “);
parsedText = parsedText.Replace(“&+w”, “\\cf16 “);
parsedText = parsedText.Replace(“&n”, “\\cf16 “);
parsedText = parsedText.Replace(“&N”, “\\cf16 “);
target.Rtf = rtfHeader + parsedText + “}”;
}

The inelegant part? It builds a big, ugly string in realtime. Yes, we’re essentially building an RTF document by hand.

The elegant part? All I’ve had to do is wire up the text changed event to any part of a mob, object, or room that supports color codes. All that mess above lets us use the following code:

private void txtDescription_TextChanged( object sender, EventArgs e )
{
Form1.BuildRTFString( txtDescription.Text, rtbDescription );
}

Yes, we can wire up any text box with a realtime colorized visualizer in a single line of code. Every character we type is shown as it would appear on the mud as we type it. Even with all the string replacement calls, it’s fast enough that there is no noticeable lag at all.

Here’s a screenshot of what it looks like (visualizer windows have a black background):

Screenshot of Basternae Mob Editor

I still hate the way WordPress formats my source code.

Project Line Counter Revisited

When I decided to switch development efforts to C# I assumed that Project Line Counter didn’t support counting non-C++ code. It turns out I was wrong, so here’s an update on the codebase line counts:

Main Codebase:
99,482 lines total
77,947 lines of code (78%)
8,252 lines of comments (8%)
1,285 mixed (code + comment) lines (1%)
11,976 blank lines (12%)

Editor:
4,402 lines total
3,281 lines of code (74%)
927 lines of comments (21%)
1 mixed (code + comment) lines (0%)
193 blank lines (4%)

If you saw my line count post from last May, you’ll notice that there are about 16,000 fewer lines of code.  It’s not because features have been been removed from the MUD engine.  Just about all of the reduction in code is from converting the save/load code to .NET XML serialization.  Letting go of the old, buggy, hacked-together text file formats has done wonders for reducing code-spam.

First Post From The New House

The computer’s plugged in, the internet access is turned on, my desk is half-assembled… almost fully moved in.

Over the past week or two the zone editor has been improved and is in a state I refer to as “version 0.06”.  It still has a long way to go, but it’s coming along.

Progress will still be slow until around mid-February as I get this place into a more liveable state.

Visual SourceSafe 2005 Is The Worst Application Ever

First off, don’t think I’m using VSS2005 for Basternae because I’m not – I’m using Subversion. However, I am using it at work. If I had a choice what source control application we used I’d be using Subversion there too.Over the years there have been many deeply flawed software applications. Luckily market Darwinism has weeded out most of the unbearably bad programs. If nobody wants to use an application, it fails to sell and ends up perishing.

The problem is that Visual SourceSafe 2005 seems to be immune to this force. That might be primarily due to the fact that each release has about fifteen minutes worth of code updates added to the previous release.

Here are some of the problems with VSS:

1. Unbearably slow. I’m on a gigabit network and have a very fast server and it still takes ten minutes to check for code updates.
2. The interface is completely counterintuitive. It’s as if the design team studied up on good design principles, high-quality user interfaces, and even performed user testing studies just so they could do the exact opposite of what would make using their software a pleasant experience.
3. Don’t try to fork or branch your code. You’ll never understand it and you’ll completely screw it up, no matter how many times you have done it before.
4. When your code differs from that on the server, you get a dialog box asking you whether you’d like to keep your changes or replace them with the code in the repository. Nevermind that they managed to word the dialog in such a way that it’s hard to tell what you’re actually doing — the “Apply to all items” checkbox does absolutely nothing.
5. VSS is far too opaque. Unlike Subversion, which tells you exactly what it’s going to do before it does it so you can make changes or cancel, SourceSafe will just do whatever it wants, whenever it wants, without your permission. It’s incredibly easy to screw up a directory structure, check out things you had no intention of checking out, or perform all sorts of spooky voodoo that you never even gave the app permission to do.
6. It’s so terrible even Microsoft won’t use it.
7. It doesn’t encourage you to leave comments when you check in code. In fact, the comment window is disabled by default in Visual Studio 2005.
8. It’s hard to figure out who broke something when you want to revert, mainly via a combination of #7 and #2.
9. It slows down Visual Studio and sometimes even causes it to crash. VS.NET is already a resource hog, so adding an unstable plugin isn’t the best idea.
10. Don’t ever try to work offline/disconnected. VSS will screw everything up in very creative ways. For instance, I modified a single line of code in a single file while offline and it somehow managed to check out 500 code files when I reconnected. None of these files had been modified.

I’m not the only one who hates VSS. For further reading:
http://www.codinghorror.com/blog/archives/000660.html
http://www.codinghorror.com/blog/archives/000079.html
http://www.highprogrammer.com/alan/windev/sourcesafe.html
http://www.developsense.com/testing/VSSDefects.html