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.

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.

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:

(Click the image for a full view).

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).

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:

(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

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).

Today’s improvements include editing of mob and object special functions and detailed editing of exits and resets (load commands).

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.

No fancy screenshots to show today, but I made a lot of progress on the zone editor, with a lot of good progress on room, quest, and object editing.

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:

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.

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):

I still hate the way WordPress formats my source code.