Website Zones Page Updated
Wednesday, March 31st, 2010I updated the zones portion of the Basternae website today. It’s been a while since it was updated.
I updated the zones portion of the Basternae website today. It’s been a while since it was updated.
I’ve converted and connected “The Cavern of the Worms” by Zaeru, “Fairlocke” by Lortar, and “The Elemental Plane of Air” by Lortar. There are a few more zones that will be ready connect as soon as I can improve the zone converter to handle them. Dang cobbled-together thing chokes for the silliest of reasons.
25 more spells are working today, mostly defensive beneficial sorcerer and cleric spells like ‘fly’, ‘invisibility’, and ‘protection from fire’. There are quite a lot more to work on, but it’s good progress.
Most MUDs have mobiles of very limited intelligence that stand around waiting to be killed and often don’t even bother to remember that you attacked them ten seconds ago. Some games have more intelligent creatures that actively try to defend themselves and take down the enemy by the most effective means (always fireballing trolls, dispelling undead opponents, etc.) What MUDs have you played with more advanced/detailed mob AI? What was it like?
Sure, there are the obvious ones from the Basternae ancestry, but I’m looking for the ‘best of breed’ so I have a standard to measure against.
I finished up more of the new spell engine and damage spells can be used now. I’ve only tested magic missile so far, but it worked beautifully.
Handling a skill or spell with multiple modifiers in code has always been a bit of a nuisance. I changed that around a bit so that they work they way I want them to.
So, here’s what adding three effects looked like in code beforehand:
Affect af = new Affect( Affect.AffectType.spell, spell.Name, 12 + level / 4, Affect.Apply.intelligence, 3, Affect.AFFECT_NONE );
victim.AddAffect(af);
af.ApplyType = Affect.Apply.constitution;
af.Amount = 8;
victim.AddAffect(af);
af.ApplyType = Affect.Apply.dexterity;
af.Amount = -5;
victim.AddAffect(af);
You’ll notice that the target has 3 separate affects added just for one spell. That’s because each affect could only handle a single modifier.
After making the modifiers into a list that can have a variable length, here’s what the same code looks like:
Affect af = new Affect( Affect.AffectType.spell, spell.Name, 12 + level / 4, Affect.Apply.intelligence, 3, Affect.AFFECT_NONE );
af.AddModifier( Affect.Apply.constitution, 8 );
af.AddModifier( Affect.Apply.dexterity, -5 );
victim.AddAffect(af);
Now it takes half as many lines of code to do the same thing and looks a lot cleaner. The codebase also shrunk by about 300 lines of code in the process.
This also means that some spells or skills that used to show up multiple times on the score screen will only show up once.
I finally got the spell ‘plugin’ system to work as intended for the first externally-coded spell.
Each spell is stored in an XML file outside the MUD engine, i.e “Fireball.xml”. The file has a bunch of settings for the spell like casting time, target type, modifers, etc. It also has an optional code section for more complex spells.
Yesterday I got the simple case working, that of a single-effect spell with no custom code like detect magic. It just sets the ‘can detect magic’ ability on the target for a number of game hours.
Today I got the more complex case working — that of a spell that uses compiled custom code. The example spell is ‘minor creation’. It has a lot of custom code to process keywords and select predefined objects based on those.
The code I put together a year ago almost half-worked. It could load the spell code from the file and compile it, but when it came time to execute it failed. Turns out that most of the issue was how namespaces were being referenced and how types were being created — lots of detailed C# reflection stuff.
Now that I’ve worked that out there are no more roadblocks to ‘modernizing’ spells. Sure, only 2 are converted so far and there are 419 to go, but now that the groundwork is in place it shouldn’t be too difficult.
So far this is only on my local machine - not up on the server yet, but will be within a day or two.
Looks like I sorted out that nasty little affect removal bug, so onto the next…
With this and the previous fix, now would be a great time to sign on and start testing the heck out of things. After all, you don’t want me to run out of work to do, do you?
It looks like there was a nasty bug in the zone converter for two of the three format types that we convert that caused the “wear flags” to be mapped into the “extra 2″ flags. The wearable flags include the “carryable” flag, so with those being broken, that’s why things could not be picked up in most (but not all) zones.