The Nightmare IV LPC Library
		 History of the Nightmare LPC Library
		 created by Descartes of Borg 950419

Originally, Nightmare was an LPMud using the LPMud 2.4.5 driver with
the LPMud 2.4.5 Mudlib.  It rose out of a split of the admins of an
older MUD by the same name.  The split created the Nightmare LPMud
using LPMud 2.4.5 and Phoenix LPMud using the LPMud 2.4.5 driver and a
custom mudlib.

In the summer of 1992, the sole administrator of Nightmare,
Shadowwolf, had dwindling time to deal with the MUD and recruited
Descartes of Borg to supervise a rebirth of the MUD using the MudOS
0.8.11 driver.  At that time no publically available mudlib existed
for the MudOS driver.  You could, however, grab a copy of the
half-written mudlib run on TMI (aka TMI-1) which was also used for the
development of the MudOS driver at that time.  Nightmare therefore
decided use this mudlib (now commonly called the TMI-1 Mudlib or the
TMI 0.8.11 Mudlib) as a base of development.

Version 1.0 (January 1993)
Nightmare evolved this mudlib into a complete mudlib and released
Nightmare 1.1.

Version 1.* still retained the basic TMI 0.8.11 structure, with the most
notable differences being the creation of a working limb oriented combat
system, many extra inheritables, and some spiffy features.

Version 2.0 (Summer 1993)

Version 2.* marked the point at which the Nightmare Mudlib was no longer
"an enhanced TMI 0.8.11 mudlib".  The entire living object was new, as
was much of the simul_efun object, most commands, and the login object.
Over the course of 2.* development, socket handling (which had been
borrowed from the Basis Mudlib during 1.* development) actually took
on characteristics which look more like the old Nightmare tcp network.
A major trend during the course of 2.* devlopment was a dramatic increase
in mudlib effeciency.  Still remaining in the mudlib from TMI 0.8.11 was
the master object, the security system, some simul_efuns, the user shell,
and the basic object and container.

Version 3.0 (January 1994)

Version 3.* marks a near complete rewrite of the basic mudlib.  A new
system for races, a brand new security system for 3.0, then again for
version 3.3, languages, faster code, tighter integration with the driver,
a new user interface that gets rid of the old one that has hung around
mudlibs since the early days of LPMud, a complete rewrite of room.c, a
new mailing system, a udp network for communicating with CDlib muds, a
more modular header library including a more consistent use of headers.
Still stuck in tact from TMI 0.8.11 are a few simul_efuns and obscure
commands. 

Version 3.2 introduced an entirely new directory.  In addition it is
the first release in which the number of SimulEfuns is drastically less
than the preceeding release.  This is largely an effeciency release.
It is marked by a *huge* leap in the efficiency of the mudlib code, as
well as a much more intuitive mudlib structure.  In addition to reducing
redundant and useless SimulEfuns, we have also cut down on the number
of daemons in the mudlib.  No new daemons have root access.  Many old
ones have lost root access and now exist in the directory /daemon.  And
a lot of old daemons have been thrown out the window.

Version 3.3 is a tremendous departure from the old mudlib.  Nightmare
has dropped UID security in favour of a stack based security using
object priveledges.  This new security system owes A LOT to ideas
given to me through conversation with Ellery and Zellski.  In
addition, Beek and Rust put their 2 cents in, often which I took.  The
new security system is matched up with a new directory structure which
reflects how it works.  New features include player law and disease.
 
Version 4.0 (April 1995)

Nightmare IV:  The basic goal for version 4.0 begun after the release
of 3.0 was to create a brand new mudlib.  Earlier versions suffered
from the TMI-1 base which was used to develop the mudlib.  Namely it
was started as an extension of that mudlib without any vision or
design applied to it.  At the time of version 3.0, I realized this
lack of vision with the help of useful criticism from Cygnus.  Given
the very stagnant nature of MudOS at the time, I figured MudOS was
dead.  I therefore made it my goal to write a properly designed mudlib
retaining the functionality of Nightmare 3.0 from scratch, release it
as Nightmare IV, and quit MudOS development in favour of DGD.

Well, the rewrite has taken 14 months to complete, and the stated
goals have been completed as well as many advancements not originally
on the table.  Nightmare now uses an event driven, limb and skill
oriented combat system.  Player objects are no longer real clones, but
instead virtual objects.  Nightmare has a clear basic design which is
closely tied to the advantages of the MudOS driver.  This basic
design's highly object oriented nature makes it now easy for someone
using the lib to separate out functionality which is not desired as
well as build on top of that which exists.  The security system makes
it easy to maintain a secure mudlib without constantly having to
rethink everything you do for security holes.  

Version 4.2.4 (May 1996)
We are very meticulously debugging things.  That in combination with
the slowed pace of driver development has delayed a lot of our goals
for Nightmare V.  We have all of the features implemented, we just
need to get the bugs fixed.

Version V (planned for September 1996)
The features of Nightmare V exist in the current release.  Nightmare V
is the bug-free version of what currently exists/

Version VI (planned for January 1997)
This will have Nightmare working perhaps with the Pueblo client or
perhaps through a custom Java client.  It will include more
inheritable objects.

	Descartes of Borg
	borg@imaginary.com