-=< 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 <local host> <port number>. 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