disinterest.org - Sorrows mudlib 1.x
Please consider donating if you use anything I have worked on.

This a a collection of code written in LPC to be run within the MudOS driver, as a mudlib.

In 1994, I became involved in the development of a MUD and as the most prolific programmer, eventually became the leader of the project. The MUD itself never opened for people to play, but the mudlib reached a level where others wanted to base their own games on it. For this reason, it was made available for download.

Around this point, I moved onto building a new mudlib from the ground up, working around the constraints imposed by the mudlib we had inherited. Eventually, the mudlib was maintained by the developers of another MUD for several years, but after that it disappeared from the internet around 2001.

Note that this mudlib is derived from the pre-existing works of others. Primarily, from the Discworld mudlib. However, the majority of the additional systems and code were written by both myself, and my fellow developers. More detailed credits can be found within provided archive.

Download: sorrows-1.84.tar.bz2 (1.09 MB)
Why use it?

It is a matter of preference. At one time, there were a decent number of MUDs developing games based on this mudlib. It is reasonably polished and takes a different approach than most other mudlibs out there. There are at least two MUDs out there using it as of the time of writing, one of which is violating the included licensing agreement and not crediting either us, or the Discworld mudlib.

Unfortunately, it has been a long time since I used it myself, and as such I am unable to define the reasons others choose to adopt it instead of the alternatives. The best way to decide if this mudlib is for you, is to compare it to others and see which appeals most. A selection of the most interesting systems are described below, but this is by no means a comprehensive list.

Feature Description
Autodoc

Having documentation markup within code is a pretty standard feature these days. This system worked in much the same way. I wrote the system to monitor the files containing the code that comprised the mudlib, scanning them periodically for changes. When a new file was encountered, or it was detected that an existing file had been changed, the file would be parsed and the documentation markup within it was extracted as standalone help files. These help files were then available on demand through the ingame command line.

Designed and implemented by Richard Tew.

Parsed defines

In the environment provided by an LP game driver, a file is loaded as an object. In order to reference an object, you looked it up by the path of its file.

Example: A contrived object lookup and a function call on it.

  find_object("/directory/filename.c")->some_function(an_argument1);
Locating an object through the use of its path was cumbersome. It prevented that file from ever being moved to another directory, given that any number of other files could be refering to it by its current path. And the path did not necessarily give a clear idea of what the object defined by the given file actually did.

The idea behind parsed defines was to allow the defined symbol for the object to be used in place of the path. Not just in other code, but in parseable references to that object anywhere, even in the custom domain specific language files.

Example: The preload file defined using a DSL.

    list
    name: preloads
    type: ordered
    begin
      HANDLER_BASE
Etc..
      FTP_H
      HTTP_H

      # Loading this connects us to the Intermud 3 network.

      INTERMUD_H
    end
And, getting a little more complex..

Example: Defining what directories can be accessed by what systems.

    table
	name: HANDLER_SAVE_DIR
	type: simple
	begin
	  +rw  | -              | BOARD_H COORD_H PROJECT_H USER_H
	  +rw  | -              | QUEST_H CHANGES_H ORGS_H MATERIALS_H
	  +rw  | BANK_H[<1]     | BANK_H
	  +r   | HELP_H[<1]     | HELP_H
	  +rw  | HELP_H[<1]     | AUTODOC_H
	  +rw  | NROFF_H[<1]    | NROFF_H
	  +rw  | ROOM_H[<1]     | ROOM_H
	  +rw  | SOUL_H[<1]     | SOUL_H SOUL_COMP_H
	  +rw  | WEATHER_H[<1]  | WEATHER_H
	  +rw  | LIBRARY_H[<1]  | LIBRARY_H
	end

All of the upper-case names within the shown markup, are defines provided by one of a number of LPC include files. A suffix of [<1] indicates that the actual filename, rather than the path should be used. Or, to put it another way, splitting the path up by /, and taking the last element (the file name) discarding the preceding ones (the directory names that make up the path).

Designed and implemented by Richard Tew.

Domain specific languages

Rather than hard-coding exceptions into the relevant systems, domain specific languages were implemented to allow data and rules to be placed into configuration files instead. Excerpts from some of these configuration files are shown above under "Parsed defines".

Decoupling the code from the data and rules allowed the quality of the code within the mudlib to be improved significantly. Code became clearer and more general purpose, and correspondingly the data and rules were more easily readable and of course changeable.

Designed and implemented by Richard Tew.

Stacked security

As we were developing our mudlib, stacked security came into fashion. We acquired our stacked security system from Discworld, modifying it to limit security using whitelists defined by the configuration scripts defined above.

Stacked security is a system where the call stack behind a sensitive operation is analysed, and the operation fails unless all participants have permission to be involved in it. Prior to the development of this more advanced approach, only the object actually invoking the operation was checked, often allowing creative programmers to use the object to do the operation in unintended ways.

Intermud 3 client

As we were developing our mudlib, the Intermud 3 network came into being. Originally we obtained code for a client that allowed connection to the network from Discworld. However, in its current state, the mudlib contains a custom implementation of an Intermud 3 client.

Designed and implemented by Brian Behlendorf.

Web server

As we were developing our mudlib, the idea of having a web server integrated into your mudlib came into fashion. The web server being an LPC object, could invoke game code and introspect game state, allowing all manner of interesting things to be done with it.

FTP server

Editing files through a telnet connection is cumbersome. Like other MUDs at the time, we acquired and integrated an FTP server. With this in place, developers could code on their local computer and then upload their work into place.