1. Added support for loading 4 of the 5 remaining Envy 2.2 zones that wouldn’t load.
2. Bundled the MakeZonesFast32 and DikuEdit 3.10 zone editors in the MUD package.
3. Added DOS conversion utilities for assembling DikuEdit zones (makezone.bat).

MagmaMUD 3.04 is available for download at FindMUD.

http://basternae.org/blog/2007/07/26/jetbrains-resharper/

It was OK, but not all that special. It had potential, but wasn’t quite “there” yet.

I just finished trying out Resharper 4.0 and you could paste the Resharper 3.0 review in its place. It’s neat, but not so neat that it’s a ‘must have’ utility. The features added in the latest version really aren’t anything I find useful — I don’t refactor Visual Basic, don’t use LINQ, etc.

It does, however, appear to run a little faster than version 3.  That might just be the system I’m using it with, but the slowness is no longer an annoyance.

I’ll keep my eye on it. Maybe they’ll add something I can’t live without in a later version.

BasternaeEditorPreview2.zip

The same warnings from preview version 1 still applies.

BasternaeEditorPreview1.zip (download removed, see the post about preview version 2)

Some warnings:

1. This is a pre-release version and it’s entirely likely that it will be unstable and lacking in features.
2. It has no help files.
3. It has no icons for the edit window buttons — just colors.  You have to guess what they do.
4. The map edit and walkthrough edit modes are not done yet (and haven’t been started yet either).
5. Save your work often and keep backup copies.

This is just to download, play around with a bit, and get a feel for.  I don’t expect that the area file format will change in a way that will break zones created with this editor, so you can actually start trying to use it to build something.

Check it out, see if it’s usable, and feel free to make requests, bug reports, or just say what would make you more likely to want to use the tool to create a zone for the new Basternae.

The “core rewire” still needs some work, but I should have an “alpha”, a.k.a. “try it and see how broken it is or isn’t” version of the zone editor out sometime this month.

http://www.mudconnect.com/mud-bin/new_prev/review.cgi?rid=25705

I’ve always enjoyed Duris and still play it off and on (maybe half a dozen weeks a year), but it has always had so many flaws that I end up getting fed up and walking away after a while. Part of it is administrative, sure, but a lot of the problems are core game design — at the core it’s an excellent MUD, but so much of it is an unnecessarily frustrating mess that it doesn’t really have much longevity for me. I think it comes from the original philosophy of the design — the creators really didn’t differentiate between “difficult” and “irritating”.

For example (and I’m mainly referring to Duris from a few years ago because that’s what I know best):

Randomly killed by random-spawn unpredictable scan-track mobs in the underdark for no logical reason, or = annoying.

Instantly killed because you were attacked by a drunk orc when you try to leave the inn in your hometown and since you’re level 1, assisting guards one-shot you (and your class doesn’t have sneak) = annoying.

Getting killed in artifact-wielding players in low-level zones and having your corpse looted of spellbooks/totems that you are too poor to replace because you’rer a newbie = annoying.

Player-wiping because you want to refresh the player base, purge an overabundance of equipment, or replace the world maps, or cover up the fact that the game mechanics still need some work = annoying.

Needing to use your head to come up with a strategy to defeat mobs, complete a zone, or accomplish a task = difficult.

Being forced to rely on your wits and diligently reading room descriptions to solve quests or puzzles = difficult.

Optimizing your equipment and stat bonuses based on how you want to perform in combat and doing so by real combat experience rather than reading the source code = difficult.

Somehow they seem to think that and difficult are both beneficial. Difficult makes players keep playing because things aren’t too easy. Annoying makes them log in to WoW.

I still find it incredibly amusing that I was more-or-less programming for Duris during the 2000-2001 “arms race” with Basternae 2 — every time I added a feature or convenience command that was neat but didn’t affect game balance it would show up on Duris a week later.

Even so, I can’t really say I have anything against any of the admins of Duris. After all, I’ve never even met any of them (except Xyzom from old Duris, who I actually lived with for a while and worked on Illustrium Arcana with — nice enough fella but we haven’t kept in touch). All I can do is judge by their product, Duris: Land of Bloodlust, which needs some work.

Today I refactored it into a bunch of more sensible pieces that go together a lot more smoothly.  The 1600-line function is now 80 lines, I can actually tell what’s going on during program execution, and a handful of confusing and unused variables have been eliminated.  Huzzah!

Fairlocke
The Elemental Plane of Air
Tower of Darkness

Today I had a problem that was easier to solve by creating unit tests to point out where the flaw was. The tool uset? MbUnit.

Here’s an example of an MbUnit test I wrote in order to find a string processing bug:


using System;
using System.Collections.Generic;
using System.Text;
using MbUnit.Framework;
namespace UnitTests
{
[TestFixture]
public class MUDStringTests
{
[RowTest]
[Row(12, "12.box", "box")]
[Row(1, "cheese", "cheese")]
[Row(1, "1.pie", "pie")]
[Row(1, ".chicken", "chicken")]
public void NumberArgument(int expectedValue, string inputString, string expectedOutput)
{
string str = String.Empty;
Assert.AreEqual(expectedValue, BasternaeMud.MUDString.NumberArgument(inputString, ref str));
Assert.AreEqual(expectedOutput, str);
}
}
}

What this does is check whether we’re getting the expected output when we give a certain piece of input. It’s handy for detecting anomalies without having to boot up the server and/or mess with production code. Mind you, there’s no such thing as ‘production code’ since we don’t have a server up yet, but this sort of thing is likely to be handy in the future.

I’m not the type that has any chance of turning into a ‘write the unit tests first’ and ‘unit tests are more important than code’ evangelistic freaks, but in some (or many) cases it can be easier than using trial-and-error to track down a bug.

I still hate the way WordPress formats my code.

I also fixed a few immortal commands that will make it easier to create immortals and set command permissions for their abilities.

The say, emote, whisper, yell, shout, ask, and immtalk commands were broken (all messages came across blank), and are now fixed.