A little less than a week ago I mentioned that I had broken the heck out of the codebase.
Well, it’s all back together again. The MUD engine and the zone converter are as healthy or healthier than they were before, the weather’s nice, and all is well with the world.
One thing I’ve been working on is an automatic ‘ping’ routine that checks the MUDs listed on FindMUD every few days and shows the connection results on a MUD listing so you know whether a particular MUD is still alive or not.
Since I’m no PHP expert, it tends to be rough going sometimes. I know just enough PHP to be dangerous — it’s a lot like C but not *enough* like C for me to be comfortable yet.
Even so, I’ve managed to put together a semi-automatic routine that checks these connections. Here’s how it works:
It’s a seven minute process and not too much work, but it would be nice if it were fully automatic and happened at a specified interval instead of “whenever I do it”.
The two roadblocks I have at the moment are that the shared hosting I’m using for FindMUD doesn’t seem to allow outgoing telnet connections and they also don’t allow connections to a database from outside the server. Even though I could whitelist my IP address(es) in order to connect to the DB I don’t really want to open up any of my databases.
Being able to do #1 would automatically make #2 a non-issue since connections would be made from the server running the ping test. When I get hosting for Basternae 3 it’ll be on a server I can do whatever I want on, so this process should be able to become fully automatic.
In the interest of making sure the MUD can be modified easily well into the future I’ve broken the heck out of the codebase.
Yep.
I’ve been refactoring, rearranging, renaming, and restructuring things so they make a lot more sense. That has inevitably broken a few things, but it will be far easier to add new types, flags, and enumerations in the future — things like adding a new terrain type without breaking existing terrain types or having to recompile the editor and re-convert all of the zones.
Believe me, we had quite a headache with zone file format changes on Basternae 2 and I don’t want to repeat it.
This means that it’ll take a few days before the codebase will build again and I’ll have some work to do on the converter and the editor, but it’ll be worth it.
I’m still looking at putting up a test server in May and so far Slicehost is the most likely candidate. Feel free to offer suggestions. Since it’s out-of-pocket and non-income-producing, my budget isn’t any more than $20 per month (should I be accepting donations for this?)
I did a little bit of work on FindMUD.com today. I added a page that shows the top-ranked MUDs (as rated by users) on the site. Since the site is still fairly new there haven’t been very many ratings yet, so feel free to go on over and rate the MUDs you’ve played.
In working on the new zone editor I noticed that a few things seemed a little off in some of the test zones I was working with. As much as I would like to blame the editor, since it’s new and untested, it turns out that the zone converter had an issue with race conversion between Basternae 2 and 3 zones. It was a relatively simple bug, but it was one that made all converted zones look a little stupid. Being simple, it’s been fixed with minimal effort.
Now that the converter is working pretty well I’m pretty comfortable with accepting zones that were on Basternae 2 if anyone is willing to give permission to use them.
One thing I’m surprised never made it into Basternae — bounties. It’s only natural that you would be able to set a price on someone’s head in a PvP MUD.
So I implemented about 60% of a bounty system today. There are still a few details to work out, but the core of the system is in place.
Since VS2008 somewhat rudely decided that it would become the default application for all projects, including projects that were VS2005 projects (what exactly *is* the Visual Studio Version Selector good for, anyway?), I decided to try building Basternae with 2008.
It was actually a pretty painless process.
Something changes in every version of a compiler and 99% of the time something breaks, either due to deprecation, changes in the way warnings and errors are treated, or most often due to changes in dependencies and the way they are handled. In any project of significantly large size, you can expect errors when converting to a new version of Visual Studio.
It was no surprise when the project didn’t build. It was, however, a pleasant surprise. It found three bad cast operations that shouldn’t have been written in the first place, the sort of thing that VS2005 should have complained about but didn’t. After spending a few seconds fixing those, everything built fine with no problems.
Visual C++ projects are a different story. You see, I’m convinced that Microsoft hates Visual C++ and just wants it to shrivel up and die. As long as Visual Basic and Visual C# projects are healthy, it’s safe to release a new version of Visual Studio. This time it was a bit of DLL hell along the lines of missing MSVCP90D.DLL and MSVCP90.DLL errors when trying to run a newly-built executable. WTF? Weren’t those installed with Visual Studio? You mean we can build C++ projects but aren’t allowed to run them?
OK, OK, so maybe it was a missing runtime redistributable. That’s fair enough and something I could live with since that’s the way .NET works. So I download the Microsoft Visual C++ 2008 Redistributable and install it. Fail. Epic fail.
After an unsuccessful Google search (plenty of people with the problem but no clear solution) I went playing with some of the project settings. The final fix was setting “Generate Manifest” to “Yes” instead of “No” in the Linker->Manifest File section.
Today was the Microsoft “launch event” for Visual Studio and Server 2008. I attended the local presentation and walked away with a free copy of Vista Ultimate and Visual Studio 2008. It was free to attend and I got $600 worth of software out of the deal. How can you beat that? Sure the presentations weren’t very relevant to the types of development I do (all they talked about were database-driven development, MS Office add-in development, and ASP.NET web development, all of which I don’t have any involvement in.)
I may or may not switch development of Basternae 3 to VS2008 right away and probably won’t start using Vista until my next PC upgrade, but it still feels nice to get free stuff.
Lately it’s just been a bit more work on the editor (which is now at version 0.25). Here’s an updated line count:
Main Codebase:
99,360 lines total
77,693 lines of code (78%)
8,417 lines of comments (8%)
1,258 mixed (code + comment) lines (1%)
11,987 blank lines (12%)
Editor:
9,597 lines total
7,491 lines of code (78%)
1,654 lines of comments (17%)
9 mixed (code + comment) lines (0%)
443 blank lines (4%)
MUD Screen Editor:
1,147 Lines Total
887 Lines of code (77%)
184 lines of comments (16%)
0 mixed (code + comment) lines (0%)
76 blank lines (6%)
Help Editor:
696 Lines Total
512 Lines of code (73%)
142 lines of comments (20%)
0 mixed (code + comment) lines (0%)
42 blank lines (6%)
Client:
5,312 Lines Total
3,940 Lines of code (74%)
781 lines of comments (14%)
29 mixed (code + comment) lines (0%)
562 blank lines (10%)
Since we last checked in, the editor has added about 1100 lines of code, the engine has added about 450, and the help editor and client are new to the list. It’s not that the client is new, this is just the first time we’ve counted it.
This really is a fairly large project.
When booting up the MUD engine with only my two zones (the Thri-Kreen hometown and the Kobold Village), Basternae 3 takes up 22,256 kilobytes of RAM.
That somehow manages to drop to 20,096 kilobytes of RAM when I connect with a single player. I think it was probably just timed to coincide with a garbage collection. Moving around for a while brings it back up to 20,500.
A boot up with no zones loaded starts at 22,116 kilobytes of RAM.
So, at this point the MUD engine takes about 22 megabytes of RAM plus however many zones are loaded. I can’t imagine players taking more than 8 kilobytes, and with zones taking up about 1 megabyte per 3000 rooms, we’ve got plenty of room to grow.
With 32 megabytes available, we could support:
27,000 rooms
128 simultaneous players
No problem.
The entry-level VPN servers I’ve been looking at start at 256, but that’s for OS plus applications. It’ll be running Linux so I’ll have about 128 megs for OS and 128 for apps. We could run 300,000 rooms and nearly 800 players before needing to upgrade.
I definitely don’t miss the “bad old days”. When I first started writing MUD code it was normal to only have 32 MB in an entire system.
Over the past few weeks I’ve steadily been adding more MUD listings to FindMUD. It has now has over 200 MUD listings. That’s not super-impressive, but it does have more than MudBytes and Betterbox and is quickly gaining on some of the older sites (many of which are rather neglected these days).
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:
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.
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.
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.
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).
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.
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.
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