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.