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.

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.

The latest update, which I call “version 0.03”, now has a ‘cancel’ button on each editing screen so you can revert to the original room/object/mob/whatever if you screw something up.  Saving changes to edited objects is a fairly large revision, and so far the only things you can make permanent changes to are resets.

I’ve built out most of the editing screens in the zone editor to the point where you can at least load a zone and browse it.  Not every field is represented and nothing can be edited yet, but it’s one large step closer to being able to create zones (I call it version 0.02).  No screenshots, since I’m away from the computer with the code on it at the moment.

I’m also in the process of fixing up and moving into the house I bought a little while back, so I can’t really devote too much energy to the code at the moment.

I mentioned a while back that I would need to write a zone editor for Basternae 3. Although zones edited with DikuEdit 3.0x will load in the MUD engine after running them through the converter application, DE won’t be updated to work directly with the Basternae 3 area format — it’s an old DOS app and there’s far too much effort involved in adding XML support to it.

I’ve started building a .NET version of the area editor. The intention is to make it run on both Windows and Linux.

Here’s a super-early screenshot of the development, which I call “version 0.01”:

It doesn’t do much yet, just save and load areas, show the stats of a loaded area, and list the names of mobs/objects/rooms. One of the biggest roadblocks to creating an offline editor in the Basternae 2 days was the saving and loading of zones. Now we just link to the MUD codebase as a library and call Area.Load(“filename.xml”) and it’s loaded. Saving is just as easy — Area.Save();

Most of the work will be in actually building out the screens where you can set values on things, but the fact that it loads and saves zones goes a VERY LONG way toward getting things going.  It’ll get a lot prettier and more useful with time.

I had to spend a while improving the Basternae 2 to 3 zone converter, but it’s a LOT better now.  The Thri-Kreen hometown and Kobold hometown are now converted and loading.  There’s still more framework stuff to do, but I should be ready to start acquiring and attaching zones before too much longer.

Don’t get too excited, it’s not even a real area — it’s what was formerly known as “limbo.are” — the area that contains all of the objects and mobs used by spells, such as the items created with the “minor creation” spell and elementals created with the “summon elemental” spell.

Even so, this means that we have a conversion program that works well enough to convert mobs, objects, rooms and area data. It still needs some work, but is more-or-less usable. In theory we could start adding zones. If we had any.

The next thing I’ll be working on is the character creation process. Some of the changes I made during the rewrite broke it a bit, so I’ll need to spend a solid day reworking it.