Current driver release number: MudOS 0.8.1

This document is divided into six sections.

LPC3

(Identical to 3.0.53, swedish version, except as detailed in LPCA.)

Admin-level changes:

God-level changes:

Wizard-level:

New efuns/new efun behavior:

MUDOS

MudOS is meant to be a combined mudlib and gaamedriver release. The major and minor version numbers (0.8) represent the level of the combined release. The mudlib and the driver will each have their own patchlevel at the end of the version number, so that minor changes and bug fixes can be released between major releases. As long as the major and minor version numbers of the mudlib and driver are the same, they will work together. They may work together if they don't agree, but there are no guarantees there. So for example, the release might have the following version numbers:
	MudOS 0.8
		driver 0.8.1  (one patch since the original release)
		mudlib 0.8.5  (five patches since the original release)

Changes from the 3.1.2 release of the LPmud driver from Lars Pensj|:

[Admin level changes]

[Wizard-level changes]

New efuns:

DESIGN

File permissions:

The standard way they're done is to assign them based on effective user-id. You can think of an euid as a compact representation of an object's privileges; i.e. "larry" means an object is allowed to write to /w/larry, "Root" means an object is allowed to write anywhere. It's definitely a lot faster to compute file permissions this way.

However, you should probably give player objects a different kind of permission system, so that you can allow dynamic promotion/demotion of wizards. i.e. base it on result of valid_write/valid_read in player if the object was a player, euid otherwise.

A good idea might be to go to a strict hierarchical permission system, i.e. an object can only write to its directory or subdirectories. (And a different system for wizards).

Virtual objects:

The immediately obvious thing to use them for is virtual territories. Want to create a desert with 10,000 rooms? You can, now. You could even make it a 'sparse territory' by making it mostly virtual, with some occasional detailed rooms thrown in.

The recommended strategy is to have the compile_object() code in the master object look like:

 
    object compile_object(string fname) {
       return (object)
          "/secure/virtual_object"->compile_object(fname);
    }
This keeps the complexity of the master object down. Then have the virtual_object server delegate its responsibility. e.g. if an undefined room occurs in a wizard's castle, have it call compile_object(fname) in that wizard's castle.c file. Better do a security check as well.

Privileged objects:

The best way to allow objects to be privileged is to put the function
 
    int request_privileges()
in the master object. When an object wants to be privileged it can call that function, which does appropriate checks and grants privileges in previous_object() if appropriate.

Global verbs:

You'll need to add these for 'n', 's', etc. You could also put all the player commands up as global verbs (of course all the living objects would see them; but maybe that's a good idea...?), saving a lot of sentence space that way.

You could limit the number of player commands per heart beat very easily this way. (Plea from an avid player: Please don't do this! It's stupid!) Or at the very least, 'lock' a player when you need to.

Mappings:

A good skill system would be easy with them.