November 29, 1992

Copper II is basically my modifications to the original Copper I beginning in
January, 1992. For the most part, it consists of changes within the normal
diku structure, since dramatic changes would require altering the playerfile,
significant rule changes, or a complete player purge, none of which having
been common to this point. With Copper III, this will change.

My first contribution to the mud was the Salesman, roughly during the spring
or summer of '91. It never did work right until I got code access and slowly
purged the bugs from it. At the time I got access, my primary character was
Smandoggi, though I generally didn't play much (too much schoolwork during my
last semester, plus a job - the usual sorts of things). When I started, I
generally made my comments with a -Sman note beside them. Later, when I needed
a character for diagnosing various sorts of problems, I had another character,
dbra, raised, since conceivably I might have wanted to play as a mortal from
time to time (which never really happened). So...I also have comments marked
"dbra" as well. If you get confused, feel free to curse my name(s).

***

Okay, enough personal stuff. Some of the stuff that I have put in has been a
bit controversial for various reasons, most stemming from the fact that they
were changes from the norm which the players were not used to (as of this
writing, I don't know how they are going to take Copper III). Seeing as to
how other people might want to use this code as a relatively bug-free base
and not want to endure my personal foibles, I have included some code for
conditional compilation of various things. Here is a list of things that
may currently be configured (see config.h):

	Jail system - the Copper jail system requires offenders to spend
real time in a jail cell, as well as arrests people who commit crimes
against humanoids in general, rather than just players. If you prefer
having to go without the jail system, set CONFIG_JAIL to 0. (You'll have
to remove the jail-related mobs and rooms from the files yourself if this
is what you want).

	Autorent - This is technically a misnomer, since the rent system
is not used for saving items, but rather the crash system (Autocrash would
not seem to be a suitable replacement term). With this system, players are
removed from the game after they have been idle for 48 hour-ticks, their
equipment saved as well. This prevents lag due to the extra processing of
players and items on ticks as well as allowing for things to "repop" faster.
The major reason to not set this would be to make true renting something
actually worthwhile (albeit a negative incentive).

	ATT vs BSD: These varieties of Unix have different mechanisms for
setting various resource limits. MUDs generally need lots of open files,
as each connection to the mud amounts to an open file. The actual Copper
machine is BSD, but rather than express preference for one flavor of Unix,
there are two config defines, CONFIG_ATT and CONFIG_BSD. One and only one
of these should be set, depending on the machine the code is being run on.


Having said that, there are still some unsolved problems in the code, not
yet fully looked into - the sorts of things that will continue to appear
no matter how many of them get fixed. Here is a list of currently known
problems:

	Jail time is not saved in the player file, causing people to
serve extra time because of crashes or being autorented in the middle
of a sentence. Also, there is no record on type or number of crimes
committed to factor into different lengths for sentences (a mass murderer
can serve the same amount as a petty thief).

	Room Light Sources: sometimes these get out of sync, with the
occasional -1 light sources in a room. This appears to be linked with
the loading of mobs carrying lights. (possibly fixed, but not confirmed).

	A new character who loses link on the motd can sometimes enter
the game with what amounts to a "trash" character. This is related to
preventing the duplication of names and when a new character "really"
gets added to the game.

	Twice in the past month or two the mud has fallen into an
infinite loop.

	Something in the code seems to write randomly in memory, though
apparently not very often. This comes from the examiniation of a number
of core files that either contain no useful information (no record of
where the program terminated, for instance), or those obviously caused
by trashed structures.

	Teleport items are not the friendliest feature of the game,
ultimately, since they are designed to work with any command. The
routine that handles these items is checked before normal command
processing, and can interpret things differently from the way the
command normally would. For instance, someone who does a "recite scroll"
might trigger a scroll in the room (if it were a teleport item) instead
of one being held (this is just an example - the problem might surface
in different ways).

	Weather.c could use a thorough going over, with a better way to
even out the available mana in an area.

	There are most certainly more problems that could be listed here
that haven't yet come to (or have currently slipped from) our attention.