Version 2.0 of AFKMud has been released.

This is the long awaited C++ conversion of the AFKMud codebase that's been talked about now for quite some time.
This release has no patch support from the previous 1.x series as the changes have been vast.
This document is only an attempt to track down what's been done since proper record keeping has not been done.

Extending upon our proud tradition of being the kings of idling, we foolishly allowed real life (*GASP!*) to intrude upon our little project. So much so that even as this is being written, other projects we have moved on to are not receiving the attention they probably need. Or perhaps even valuable man-hours our jobs would prefer we were not investing in this. As a result, the conversion to C++ has not gone as we would have hoped and is more or less in a stalled state that shows no real signs of improving in the short term. So unless the user community steps up and begins offering patches to fix things, complete things, convert more parts of code, or add new stuff, what you see is likely to remain what you get outside of any glaring bugfixes we might be fortunate enough to spot on our own.

Try to keep these things in mind before deciding to type out a lengthy insult of our terrible abilities, the supidity of a codebase built on mixed C/C++ code, what a piece of crap this stuff is, or whatever else you might be tempted to laugh about and then post. We already know about it and don't need other people reminding us of it. It would be far more productive to those around you to offer a patch or two. Even if it's something small.

Attempts have been made to maintain compatibility with the 1.x datafiles but this is not guaranteed to be possible. Keep this in mind should something break, but we would like to know about it anyway in case something can be done for future releases.

It goes without saying that all reported bugs against the 1.x series have also been fixed here, so it really does not need to get repeated.

Some of the major things that stand out:

The biggest of the big. The format of the area files has been changed over to key/value system. What's that mean for you? It means that the areas now save much like a pfile, deity file, or any other common data file the mud uses. This helps to provide far better fault tolerance in the area file when you are editing them offline. Wait, offline? Yes. There are a whole lot of people lately who do this, even if it's just editing by hand in wordpad. The new format is not backward compatible with any older formats. The code will support the old AFKMud formats up to version 22 as well. Which is another benefit of the new structure. There won't be as much need to insert versioning blocks to get around the strictness in the format.

The rent system has been replaced with percentage based resets and item ego to control rare items. This has been done partly because rent systems are cheesy. They tend to punish those who do not follow the "get as much gold as possible" style of playing. So it was decided that something a bit more flexible should be done. The percentage based resets do not stop with just items though. All resets can be given a percentage chance of firing. So you can have mobs that only appear sometimes, doors that are only open/closed sometimes, and even traps which are not always there. This should provide some new variety for admins and players alike. Areas with rent data will have the information automatically converted into ego values for the items. The default percentage for all resets is set at 100% so you will have some work to do in order to bring balance back to your game.

Many data structs have been converted into classes. This is scattered and incomplete, but it should be obvious which ones have been done and which ones have not. This should be most noticable in the descriptors and characters, even though there is still a lot to be done in this area. Related to the class conversions, several file IO systems that support them have been converted to use STL based file streams to read and write the files. The functions to do this are probably not well done but they do work.

All uses of CREATE/DISPOSE for structs and classes were converted into new/delete. This necessitates some additional work to initialize some values in the code but the end result is better memory management. char* strings still make use of the standard STRALLOC and DISPOSE macros. And these macros have been made mismatch safe if your environment will allow it.

All of the linked lists have been converted into std::list. If there are any leftovers that have not been done, they have been overlooked and should be reported so they can be converted as well. This makes managing linked lists tons easier and more stable. It also allows the compiler to impose type protection so that you don't accidently try to link an object to a character list and so forth. This kind of thing could potentially have happened with the old macros. It led to many many subtle but nasty bugs.

Zarius' AFK Mapper code has been added. This puts a small mini-map display next to room descriptions as you wander about. It is enabled by default on all characters and can be toggled via the config command. It is a rather nifty piece of code which provides something we've been wanting for awhile now.

The old mapout code from the ancient days of SMAUG has been reintrocuded thanks to Remcon's work. Basically this is a system which allows you to open an editor session on the mud and provide it with a map to create rooms with. It lays out the grid and sets the sector types according to how the map is input. This system is probably pretty crude but has been demonstrated to work nicely. See the "mapout" helpfile while online for more details.

Password encryption on pfiles has been converted to use SHA-256. This was done as a result of the MD5 algorithm having become less effective after hackers found ways to reduce the time needed for a brute force attack against it. Existing pfiles using MD5 will be converted up as they log on. MD5 support will remain in the package for a few releases to support the conversion but this should be considered deprecated and expected to be removed later.

Overland maps have been converted to read standard PNG files. This requires that your environment have access to the gd-devel package as the code depends on being able to include this to read and write the graphic files. Most Linux/BSD systems should have this, and there is a library for it available in Cygwin as well. The code will read your old RAW files as well.

A routine at startup has been added to allow the mud to check and be sure that any required support directories exist. Because people often unpack the archive in Cygwin using Winzip or some other brainless method that won't create empty directories, this became necessary. Missing directories will cause the game to crash in alot of cases. So it's just not cool. Once it runs, a file is dropped called DIR_CHECK_PASSED so that the mud does not repeatedly go through this. This check cannot prevent a catastrophic failure like the system dir and all of its files being missing, but obviously that should not have happened anyway.

MXP support has been cleaned up and should be mostly working now. Complaints about broken behaviour in Zmud will not be fixed. Zmud does not follow the spec Zugg himself laid out. So some things may not work properly. It should go without saying that I am a fanatic about following standards. If Zugg wants to turn this into a client war similar to the IE vs The World situation web developers find themselves in, then so be it. Our code will follow the standards, period. Clients known to work just fine: MushClient, Mudmagic, Kmuddy. Not surprisingly, these clients all follow the standards.

Intermud-3 support has been removed from the codebase. The code grew to be too unwieldy to maintain and the network itself is too unstable to be of much use. You could have found copies of the I3 code on mudmagic.com but Kyndig decided to be a prick and delete the code from the repository. The latest available copy of the old I3 source is available at http://www.mudbytes.net/index.php?a=files&s=viewfile&fid=560. It may work, it may not. Installing it is at your own risk and will be unsupported.

Extended bitvector support has been replaced with the std::bitset functions in the STL. This allows essentially unlimited bitvectors to be used. Nearly all of the old BVxx and EXT_BV flags have been converted to this format for the sake of consistency. There are still a few spots where the standard bitvector macros are used.

The code has been tweaked to reduce the strain on CPU usage when running idle. If nobody is logged on, it makes little sense
to keep the entire world running at full steam.

So when nobody at all is online, the only things game_loop will do are:
1. Maintain any active events still running.
2. Maintain the connection to the IMC2 network if it is active.
3. Maintain the pfile pruning, rare item checking, and DNS cache pruning.
4. Maintain the interport channel connections if any exist.

When an immortal ( or player ) logs on, the following items wake up:
1. Descriptor I/O processing. (DUH)
2. All items handled by mobile_update. Including wandering mobs etc.
3. Authorization channel updates.
4. All items handled by char_update.
5. All items handled by obj_update. Corpse rotting etc.
6. All items handled by char_check.
7. Object and character extraction queues.
8. Teleport and mob aggressiveness updates.

The following is only awakened when players who are not immortals log on:
1. Time update routines. Day, month, year etc.
2. Weather update routines.
3. Calendar based player updates such as hunger, thirst, or whatever else.
4. Overland environmental updates.

The net savings in this is very significant. When nobody is on your mud will basically go into
suspended animation and consume very little CPU resources. In some cases it may register as using
nothing at all on your ps listings.

The random treasure code has been overhauled some and given more variety across level spreads. It became apparent that the existing system was not providing enough reward for the risks involved in going after higher level targets. So the generation routines have had the formulas adjusted to account for this. There are also two new reset types for loading random treasure items on to mobs that work basically like G and E resets do. This way you can have mobs who always carry a random item of some sort. This can be further narrowed to a specific type of random treasure item. There is also one new mudprog which can load a random treasure item.

The webserver code has been removed and all of the data it handled has been converted into statically generated HTML files
that are suitable for inclusion in provided PHP web files. This was done because the live webserver port has proven to be
buggy and unreliable and in some cases has been known to trigger the infinite loop detection in the game. There are also
security concerns which were just easier to solve this way. The wholist can now be updated at a set interval via the cset
panel, or disabled entirely. Wizlist, arealist, and imclist are statically dumped to HTML files at bootup and will be updated as needed when new information is added to the game data that governs them.

Core SQL support has been added to the codebase. While not used for anything right away, it is there for those who wish to develop things to make use of it. Short term plans right now are limited to producing a snippet for converting helpfiles into a database table. This could open up some possibilities for web searching and PHP based OLC support.

Skill and Spell helps are mostly dynamically generated. All of the level, damage data, affect duration, saving throw, and mana use is displayed automatically from the data loaded by skills.dat. Anything not covered in that file is not affected. This system is probably not perfect, and may need tweaking as time goes on.

If a helpfile is not first found in the database, it will search the skills.dat information next. This avoids a skill/spell from blocking help on another subject with the same name. Much like a social should not block a command by the same name.

Some work has been done on modular plugin support but so far does not function. Most of the needed infrastructure to compile modules is in place. Just need some way to be able to call code within modules. This won't get any further attention without help - we're stumped on what to do with it next.

No doubt there is more that we have forgotten. Enjoy the mystery of discovery or something.