Monthly Archives: January 2008

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.