-=< Heaven Seven LPMud Lib >=- (c) 1994. This mudlib was developed with a few features in mind - * To run nicely under - Amylaar 3.2 Compat - 3.1.2 Compat - OK312 (MSDOS) in COMPAT mode * Capable of running under - NATIVE mode drivers - MUDos (at least it does for OK09193c (ms-dos)) This is acomplished via 'include/mudlib.h', which is (almost) autoconfiguring, depending upon the driver type used. It features extensive use of the inheritance feature of LPC. This cuts down memory overhead, and disk space. However, due to its extensive features it is on the largish size. With everything it takes about 4-5 Megs of disk space. But it can take up less space if you remove some of its features such as intermud, party system, guideline docs, and some of the 'skills' code. History: * The mudlib started as a standard 2.4.5 lib on GumbiMud (2 years ago), after which there was a brief development at Dragons Path (2 - 3 months of intensive programming). Further development is as follows: * Sands of Time - 12 months. At Sands of Time it underwent a major rewrite/debug At which stage the mudlib was named HEAVEN7. * The first release of HEAVEN7 was without a small area of play, and contained a few small compilation problems for new time users. * The next release, only a few months later, has improved features, and a small area for players. Overview: From Players Viewpoint * Built in skills for fighter, thief, mage, cleric, with MULTI-CLASSING in these skills. * Over 100 skills already developed. * Fully integrated race system (with various benefits and penalties which are race dependant) * Simple and user friendly saving party system * Not 20, 30, 40 or 100, but INFINITE level system. * Spells can be easily made, and have features such as area effect, spell immunities, magic resistance, casting times, spell components, and casting messages. * Ability to enchant magic items, scribe scrolls, brew potions * Searching, swimming, climbing, weather, day & night. * Cut and paste features between bulletin boards and mailer (and 'more' cmd). * INTERMUD system for emailing between muds. * Player privledges at higher levels, including keeps, houses, and the like. * Quit feature allows entry into the same room which you left, if so desired. * 'Intelligent monsters' to fight (they also are able to use the same spells and skills as players do.) * Inbuilt 'alias' & 'do' command (macro) system. From Creators Viewpoint * Domain structure has been provided, so as to allow writing of variant mudlib themes (future, modern, marvel-comics, whatever). * The creator also has the advantage of coding within his own home dir. * Flexibility of own directory access. You can grant anyone read/write access to one file, a dir, or all your things! * Extensive documentation allows better understanding of the lib, and the creators part in coding, from armour to weapons, to quests and spells'n'skills. * There are extensive "wiztool" commands, too numerous to write. With cmds such as deltree, tree, find. Extensive object locating cmds. Eg. stat users Put users::room dest sword 2 in bag in chest in zilanthius find all orcs dest all orcs (find_living usually only handles 1item) * Automatic checking of objects with 'stat' (monsters, armour, inventories, etc) with QC documentation, outlining illegal items, and noting where changes are required. From Admins Viewpoint * Lib security is reasonably tight when using the amylaar driver. * When using 3.1.2 it is as good as it can be without going overboard. We recommend the amylaar driver as it is faster, more secure, has intermud facility. But entire mudlib is BACKWARD compatible. * Security within the creators own home dir, or the domain security, may easily be changed via an access.c file. This allows only those without normal access to certain files, either 'read' or 'write' access if the creator so desires. This cannot, however, bypass global security routines. * There are some domain features if you want to separate themes. * Extensive documentation of armour, weapons, monsters, their suggested abilities, stats, and a complete listing of their functions, how and when to use them, why, and examples is given. * QC system which allows for certain 'Quality Control' persons to gain READ access to creators files (for help in their coding as well as illegal item spotting!) * Separate security leveling system, higher access granted to higher security level. Level system wide enough to allow manipulation by admin to suit its purposes. * Separate player/wizard objects mean players cannot 'hack' creators powers or access to the mudlib (as the routines are simply not in their object). * The main mudlib has the following inheritance pattern: inherit/base/base_obj | | |----> inherit/armour ----> inherit/magic_armour | ^ | | |----> inherit/weapon -------------+--> inherit/magic_weapon | ^ | | |----> inherit/treasure ----> inherit/wand | ----> inherit/container | |----> inherit/room2 ----> inherit/std_pub | ----> inherit/std_bank | ----> inherit/guild | ----> inherit/store | | inherit/base/actions | | | | |----> inherit/base/living ----> obj/player ----> obj/wizard | | | ---> inherit/monster ----> inherit/undead | | |----> inherit/base/consume ----> inherit/drink | ----> inherit/food | | |----> inherit/clothing | | |----> inherit/chair Getting Started Compile your lpmud driver. It should be either a: 3.1.2, Amylaar 3.2 (or Mudos in a pinch). The prefered driver mode is COMPAT_MODE. Edit include/mudlib.h and define the appropriate driver type. You should be able to login with telnet . The user name 'admin' will give you a character with the highest security access. Notes for NATIVE_MODE (and MUDos) The main mudlib is able to run in a pseudo-NATIVE_MODE. This is not equivalent to a true NATIVE_MODE mudlib. File/object access runs in a compat configuration, every object is given an uid "root". The file_name() efun has been simul_efunned to behave as in compat mode. All room code (/room directory) is written in COMPAT, you will have to write you own room code. Notes for MUDos There is an example of the startup configuration file, "config" that was used with Olav Kolbu's OK09193c MUDos compilation. Conclusion There are many more features, and development continues even without a solid and dependable site from which to work. Overall, having worked on and run several muds, this system has been devised so as to benefit both the players as well as all creators (from admin to apprentice). If you have any problems, don't hesitate to email either one of us. Zilanthius (Ray Gilbert) Email: c8435802@wombat.newcastle.edu.au Angel (Matthew Hodgson) Email: c9036596@cc.newcastle.edu.au