Author Archives: xangis

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

Even More Progress On The Zone Editor

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.

More Progress On The Zone Editor

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.

Starting On A Zone Editor

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.

Rebuilding An Engine

Most of the work done over the past few days has been boring, grueling engine rewrite stuff.  There’s not much exciting that can be said about reorganizing variables, changing the way that lists are processed, and cleaning up object reference handling.  It’s a lot of code rewriting that will have little or no visible effect on the way the game is played.  It will, however, make it far easier to add to and update the code with our planned changes.

Got The Dotcom

It seems that the domain Basternae.com recently became available.  I bought it, so both basternae.org and basternae.com point here.  Yippee!

Magma MUD Codebase 3.03 Released

Over the past month I’ve been playing around with the Magma 3.02 code a bit more. I found a few crash-bugs and fixed them, mostly caused by references to rooms and objects from Basternae 2 that no longer exist.

The big change is that 58 of the 63 original Envy 2.2 zones will load in the engine. This means you can actually run a MUD with the codebase. Nobody wants to play a stock MUD, but at least you can have a functioning game world while all of your new areas are being built.

I’m sure there are still some bugs and/or stability issues, but this release is a big step forward.

Let me reiterate what I said when releasing 3.02: This is _NOT_ the code I’ve been working on for Basternae 3. This is the codebase from early Basternae 2.

It’s posted on FindMUD if you would like to download it. Runs on Linux (tested on Ubuntu) and Windows (tested on XP).

Mud Sound Protocol

Today I added the framework to support the Mud Sound Protocol (MSP). I don’t have any sounds and haven’t added support to the client yet, but when it comes time to add sound it’ll be very easy. I figure I’ll do the sound design myself and/or enlist help from some of my friends over at Darksonus and it’ll turn out quite nicely.

IT App Monitor Robot

This post on The Daily WTF reminds me of the startup script we had for Basternae 2 in the early days:

http://thedailywtf.com/Articles/ITAPPMONROBOT.aspx

Since the codebase would tend to hang or crash, we would have to watch for the process and restart it if it was missing. If the CPU usage was above a certain amount for more than about a minute it also told us that the code was in and endless loop, so the process would have to be killed and restarted. It wasn’t not quite as intricate as the WTF setup, but it was still pretty kludged.

Fixes and More Fixes

I have the client and server running well enough that I’m able to create a character and log in to test all of the available commands. In the first pass, just logging in and typing the command name to see what happens, I’ve found a fixed quite a few glitches. I haven’t fixed all that I’ve found yet, but at least it’s progress.

It finally feels like this is turning into a game again.

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.

Two More Areas Converted

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.

First Area Converted

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.

A Help Desk?

I’ve written what is essentially an online help desk system for the MUD to keep track of bugs, ideas, and typos. I’m sure it’ll need to be adjusted with use, but at least now the immortals should be better able to keep track of where the problems are and what needs to be done with them.

Fraglist, Crime, and Corpse Files Converted

The fraglist, crime, and corpse data files have been converted.  The crime file conversion required no effort whatsoever since justice doesn’t do anything with it.

Right now I’m working on a scheme to replace the old typo, idea, and bug file concepts, which were pretty useless.  The idea was that anytime a player typed “bug <whatever>”, it would go into a file on disk that could only be accessed from a shell account.  In most cases, the bug, idea, and typo files were completely ignored.  With this new system, immortals should be able to read, fix, and modify any of these issues online.  I’m still working out the details, but it’s looking pretty good so far.