-=< Heaven Seven LPmud Lib >=- (c) 1994, 1996. This mudlib was developed originally from 2.4.5lib as a base, and reworked into a brand new mudlib with many new features. It is a COMPAT mode mudlib. It will - * Run nicely under - Amylaar 3.2@118+ Compat (suggested) - Amylaar 3.2.1 Compat - 3.1.2 Compat - OK312 (MSDOS) in COMPAT mode (suggested for off-line wizards) * Capable of running under - NATIVE mode drivers - mudOS (at least it does for OK09193c (MSDOS)) This is acomplished via 'include/mudlib.h', which is (almost) autoconfiguring (except for OK312), 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 3-4 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 Den (2 - 3 months of intensive programming). v1.01 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. v2.01 * The first release of HEAVEN7 was without a small area of play, and contained a few small compilation problems for new time users. v2.07 * The next release, only a few months later, has improved features, and a small area for players. v2.08a * Malevolence A few additions at the beta-stage were added to this mudlib, and then revised and re-coded to make more efficient for v3.0 * v3.0 At whitetiger development continued for v3 release. New features added at this point (see below). Overview: From Players Viewpoint * Built in skills for fighter, thief, mage, cleric, with MULTI-CLASSING in these skills (max of 3 at v3.0) * Complete class system of 4 classes (for multi-classing), and sub-class/guilds for specialisation. * Sub-class of paladin added (v2.08a) * Sub-class of ranger added (v3.0) * 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). * Player privledges at higher levels, including keeps, houses, and the like (still yet to be completed). * 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. * Saving Party System v3.0 * Saving Inventories (on a 'Quit', not 'quit') * Weapon immunities for monsters/players * Global channel system * Racial restrictions for classes/sub-classes * Advanced action commands similar to those boasted by LIMA BEAN mud, and NANNYMuds et. al. (get the shoes from the bag, get two shoes from the second bag.. etc) * Global weapon mastery system works in conjunction with weapon proficiencies using mapping skills ([ "longsword" : skill level, etc ]) Fighter-types get more proficiencies per level, next ranger/thief/paladin, then clerics and then mages. Classes hence get a wc bonus to reflect this increase in skill 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, and has possibility of adding an intermud facility. 90% of the 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. * .dat files for armour/weapon class system penalties. * 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 ----> secure/player ----> secure/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 (.1), (or Mudos in a pinch). The prefered driver mode is COMPAT_MODE. You should be able to login with telnet <local host> <port number>. The user name 'admin' will give you a character with the highest security access. If you want to make use of the parse_command features, and are using the Amylaar driver stuff (not for MS-DOS, however), make sure you you copy down the entire parse_command_prepos_list, and add it to the file parse_old.c This is used by amylaar when in COMPAT mode only. parse.c is used when in NATIVE_MODE. Find the function where the prepositions are listed (use a search routine), and add the master.c ones in there. THEN compile the driver. Only then will the parse_command features work to their maximum potential. Make sure you then set the valid PARSE_COMMAND define in player.cfg 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_efuned 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. MSDOS I have ported the Amylaar driver to a msdos platform. This is available at actlab.rtf.utexas.edu:pub/incoming/mud or at ftp.ccs.neu.edu:pub/mud/mudlibs/heaven7/heaven7_dos_2vxx.zip 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: zilanthius@hunterlink.net.au Angel (Matt Hodgson) Email: ravenloft@hunterlink.net.au