The Grendel Project - A Windows MUD Server        (c) 2000-2002 by Michiel Rook



= Modules ====================================================================


As of 0.4.0 final, the Grendel source contains so called 'modules'. These
modules (or plugins, if you will) can be loaded on demand by the server,
and can contain arbitrary functionality that you may wish to enable.

It also provides a more suitable platform for 3rd party code, which will
rely less on the core functionality, and thus better survive the
rough tide of code improvements and version changes.

Modules are built & loaded through the native Delphi package mechanism,
and as such they are simply "enhanced" DLL's (or shared libraries).

There are however a few guidelines and requirements for these modules,
and they follow below.


1. Requirements

- Each module should have a unique name 

- The package definition (.dpk) should reside in Grendel\modules. When built,
  the corresponding library (.bpl, or .so) will appear in the same directory
  
- Add a {$DESCRIPTION} line in the .dpk file of the module, with
  a small description of the functionality of the module
  
- Any units or other sourcefile that contain the pure functionality of
  the module should reside in a directory under Grendel\modules,
  preferably Grendel\modules\<modulename>
  
- Make sure the units in the module do not collide with units in any
  other module. Good common practice is to prefix all units with
  the abbreviation of the modulename


2. Guidelines

- Use proper initialization and finalization blocks in the units of your
  module, as the module may be loaded or unloaded at any time,
  more than once

- Add a corresponding unregisterCommand() in your finalization block
  for each registerCommand() in your initialization block
  
- Add a corresponding unregisterConsoleDriver() in your finalization block
  for each registerConsoleDriver() in your initialization block