Now with more filth!

The mudpy project aims to create a simple, generic, cross-platform, freely-redistributable MUD core engine which can be easily understood and extended. It is written in pure Python (currently compatible with 2.5 and later 2.x versions) and has no prerequisite dependencies beyond Python and its built-in modules. All configuration and data are stored in consistently-formatted plain text files for ease of administration. The core engine is unicode-clean internally and supports UTF-8 encoding for input and output of extended text characters.

The mudpy program and sample content are released under a free and open license, and any bug reports, criticisms, ideas, patches, content submissions or other offers of collaboration are wholeheartedly welcome.

I’ve committed code changes which break backward compatibility with old data… specifically the passhash facet of account elements. As of the 2010-06-17 23:49:58 UTC commit, passhash now uses a BSD-Unix-passwd-like encoding which embeds a hash algorithm index, ability to specify multiple iteration rounds, and a randomly-generated salt. The old format, a simple, one-round MD5 hexdigest with an implicit salt of the account’s name facet, can be converted to the new format using the password.upgrade_legacy_hash function.

In an effort to step up development and encourage community collaboration, I’ve invested considerable time combing through half a decade of archived preview releases and importing them accurately into a version-controlled repository complete with detailed commit logs.

I’m using Git for version control on the project from this point forward. The archive can be cloned anonymously from http://mudpy.org/git/mudpy if desired. For now, detailed commits can be E-mailed to fungi@yuggoth.org, but I’ll be setting up a developer mailing list for more open presentation and discussion of patches soon (and putting together a submission guideline document with additional, pertinent information).

I’ve also started including a GNU-formatChangeLog file (linked from the documentation page as well), generated automatically from repository commit logs. It will be included in all future tarball/zip files, since these will begin to be exported automatically after each new commit.

The Universe.initialize_server_socket() method has been adjusted to support IPv6 addresses specified in the host facet of the internal:network element. The default for this, if unset, is now dependent on the local system’s support for IPv6 (u”::” with, or u”0.0.0.0″ without). The example configuration has been modified to recommend the IPv6 localhost address of ::1 now instead of the old IPv4 localhost 127.0.0.1 address, but this will obviously fail on systems without IPv6 support (these should hopefully be few and far between any longer?).

Additional tweaks in this release include changing the shebang line in bin/mudpy to source the interpreter’s path from /usr/bin/env, and adding a feature to rename the MUD process to that of the script itself if the daemon facet of the internal:process element is set to yes.

Many thanks to Mark Kolloros (a.k.a. Colourful) for pointing out a problem with the command_say() function, where a type exception could be triggered if an actor provided parameters to the say command which evaluated to an empty string. This is fixed in today’s release, along with some cleanup and a couple of additional improvements to command_say():

Now, instead of denying parameters which look like replacement macros, they are simply escaped before being processed.

The beginnings of reorganization are present in today’s release. The original mudpy.py Python module has been renamed to misc.py in a new mudpy package under a lib subdirectory, and will start to be split up into multiple separate modules over time. Data files (with the exception of the root mudpy.conf) now have .mpy or .txt extensions appended to designate their formats. Further, all files have been grouped into subdirectories based on their status and functionality (executable, Python modules, configuration data vs. global read-only data vs. modular add-on data vs. volatile/variable data vs. …). To deal with this scattering, a new find_file() function, internal:storage configuration element and include_dirs __control__ meta-facet have been implemented, which allow arbitrarily location of data files from relative or absolute paths out of a prioritized series of potential directory trees.