gergely/wmud
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Moved old codebase to old-codebase/

Browse Source
This commit is contained in:
Gergely Polonkai (W00d5t0ck)
2012-03-07 16:24:50 +01:00
parent e2b367dd56
commit dc1a6d7a0a
377 changed files with 0 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
old-codebase/doc/OLD-DOCS/README Normal file
View File

@@ -0,0 +1,34 @@
This directory contains documentation on various aspects of the game.
Area builders will be most interested in database.doc, dbsup.doc, defs.doc,
shop.doc, and values.doc. These five files can be mailed automatically
with the "do_mail" script in this directory. do_mail takes the recipient
as its only command-line argument. For example, to mail the documentation
to CircleMUD's author, you'd type "do_mail jelson@cs.jhu.edu".
CONTENTS:
--------
COLOR.DOC - Programmer's manual on how to use color codes
COMM.DOC - The game-to-player communications system, most importantly
the act() procedure
DATABASE.DOC - The format of the most important data files
DBSUP.DOC - Detailed information on each field in database.doc
DEFS.DOC - Important document on what rules should be followed
when creating a part of the world, to avoid complete chaos
HACKER.DOC - Insight into the art & science of programming (courtesy MERC)
HANDLER.DOC - Descriptions of most of the basic 'database handling'
procedures, found in handler.c
LICENSE.DOC - The conditions under which this game is distributed
NOTE: THIS FILE MUST ALWAYS BE PRESENT
RELEASE.DOC - CircleMUD release history
RUNNING.DOC - Directions for compiling, running, and maintaining the game
SHOP.DOC - Describes how to create a shop file
SOCIALS.DOC - Description of the 'social action' system
SPELL_INFO.DOC - Doc on spells, especially how damage is calculated
SPELLS.DOC - Info on the spell/affection system
TIME.DOC - How time is in DikuMud compared to real world
UTILS.DOC - Description of the CircleMUD maintenance utilities
VALUES.DOC - The 4 generic values for items, described in detail
WIZHELP.DOC - Description of all god commands

9
old-codebase/doc/OLD-DOCS/README-DOCS Normal file
View File

@@ -0,0 +1,9 @@
3/6/95
-----
This directory contains the documentation distributed with CircleMUD 2.2.
This directory and all the files in it will eventually disappear. They
are here now to serve as a reference while I write the new documentation.
--JE

31
old-codebase/doc/OLD-DOCS/coding.doc Normal file
View File

@@ -0,0 +1,31 @@
/**************************************************************************
* Copyright (C) 1993 - see 'license.doc' for complete information. *
**************************************************************************/
HOW TO CONVERT YOUR IDEAS INTO REALITY
A CircleMUD Coding Manual
Table of Contents
---------------------------------------------------------------------------
i. Introduction
1. Overview and Coding Basics
1.1. The Way Things Work -- Overview
1.2. CircleMUD's Structures and Lists
1.3. Frequently Used Functions
2. Changing the Code
2.1. Adding Commands
2.2. Adding Socials
2.3. Adding Spells
2.4. Adding Skills
2.5. Writing Special Procedures
2.6. Adding Classes
2.9. Adding Color
3. Changing the World
3.1. Adding Areas
3.2. Removing Areas
3.2. Writing Areas

134
old-codebase/doc/OLD-DOCS/color.doc Normal file
View File

@@ -0,0 +1,134 @@
/**************************************************************************
* Copyright (C) 1993 - see 'license.doc' for complete information. *
**************************************************************************/
USING COLOR IN CIRCLEMUD
"color.doc"
CircleMUD allows you to create colorful messages by using ANSI control
sequences. Each player may select what "level" of color he/she desires
from the four levels "off", "sparse", "normal", and "complete." Each
player can select his/her color level by using the COLOR command from
within the MUD; you as the programmer must decide which messages will be
colored for each of the color levels.
All files in which you wish to use color must have the line:
#include "screen.h"
after all other includes in the beginning of the file.
There are 8 colors available -- "normal", red, green, yellow, blue, magenta,
cyan and white. They are accessible by sending control sequences as part of
another string, for example:
sprintf(buf, "If you're %shappy%s and you know it clap %d of your hands.\n\r",
x, y, num_of_hands);
send_to_char(buf, ch);
In this example, x and y are the "on" and "off" sequences for the color you
want. There are 2 main series of color macros available for you to use
(don't actually use "x" and "y", of course!): the K series and the CC series.
The CC (Conditional Color) series is recommended for most general use.
The name of the actual sequence starts with the name of its series, plus
a 3-letter color code, as follows:
Normal : NRM
Red : RED
Yellow : YEL
Green : GRN
Blue : BLU
Magenta: MAG
Cyan : CYN
White : WHT
For example, white in the K series is KWHT; blue in the CC series
is CCBLU() (arguments defined below).
The K series requires no arguments, and is simply a macro to the ANSI
color code. Therefore, if you use a K-series color code, the color will
ALWAYS be sent, even if the person you're sending it to has color off.
This is very bad -- people who do not have ANSI-compatible terminals
will see garbage characters instead of colors. The K series is mainly
used to print colors to a string if the player's color level will later
be tested manually (for an example, see do_gen_com in act.comm.c).
The recommended series is the CC series (i.e. CCNRM(), CCRED(), etc.)
The CC series macros require two arguments -- a pointer to the character
to whom the string is being sent, and the minimum color level the player
must be set to in order to see the color. Color sent as 'sparse' (C_SPR)
will be seen by people with color set to sparse, normal, or complete;
color sent as 'normal' (C_NRM) will be seen only by people with color
set to normal or complete; color sent as 'complete' (C_CMP) will be seen
only by people with color set to complete.
To illustrate the above, an example is in order:
#include "screen.h" /* include screen.h in all files that you use color in */
ACMD(do_showcolor)
{
char buf[300];
sprintf(buf, "Don't you just love %scolor%s, %scolor%s, %sCOLOR%s!\n\r",
CCBLU(ch, C_CMP), CCNRM(ch, C_CMP),
CCYEL(ch, C_NRM), CCNRM(ch, C_NRM),
CCRED(ch, C_SPR), CCNRM(ch, C_SPR));
send_to_char(buf, ch);
}
What does this do? For people with color set to Complete, it prints:
Don't you just love color, color, COLOR!
(blue) (yellow) (red)
People who have color set to Normal will see:
Don't you just love color, color, COLOR!
(yellow) (red)
People who have color set to Sparse will see:
Don't you just love color, color, COLOR!
(red)
People who have color set to Off will see:
Don't you just love color, color, COLOR!
(no color, as you'd expect)
There are several common pitfalls with using the CC series of color macros:
* Do not confuse CCNRM with C_NRM. CCNRM() is a macro to turn the color
back to normal; C_NRM is a color level of "normal".
* Always make sure that every pair of "on" and "off" codes are at the
same color level. For example:
WRONG: sprintf(buf, "%sCOLOR%s\n\r", CCBLU(ch, C_NRM), CCNRM(ch, C_CMP));
This is wrong because if someone has their color level set to Normal,
the CCBLU code will be sent but the CCNRM command will not, causing all
subsequent output to be blue.
WRONG: sprintf(buf, "%sCOLOR%s\n\r", CCBLU(ch, C_CMP), CCNRM(ch, C_NRM));
The above statement is also wrong, although not as bad. In this case,
someone with color set to Normal will (correctly) not get the CCBLU code,
but will then unnecessarily get the CCNRM code. Never send a color code if
you don't have to -- the codes are several bytes long, and cause a noticable
pause at 2400 baud.
* This should go without saying, but don't ever send color at the C_OFF
level.
* Special precautions must be taken when sending a colored string to a
large group of people -- you can't use the color level of "ch" (the
person sending the string) -- each person receiving the string must
get a string appropriately colored for his/her level. In such cases,
it's usually best to set up two strings (one colored and one not),
and test each player's color level individually (see do_gen_com in
act.comm.c for an example).

146
old-codebase/doc/OLD-DOCS/comm.doc Normal file
View File

@@ -0,0 +1,146 @@
/* ************************************************************************
* Copyright (C) 1990, 1991 - see 'license.doc' for complete information. *
************************************************************************* */
Descriptions of the message-to-character routines of comm.c
void send_to_char(char *messg, struct char_data *ch)
Places messg in the output queue for ch, for later sending.
void send_to_all(char *messg)
Sends a message to all players.
void send_to_except(char *messg, struct char_data *ch)
Sends to all players, except the one pointed to by ch.
void send_to_room(char *messg, int room)
Sends messg to all players in the room.
void send_to_room_except(char *messg, int room, struct char_data *ch)
Send to all in room, with the exception of ch.
The following routine takes the place of all the old perform-routines. It is
to gradually replace these in the old code, and is to be used exclusively in
all additions.
FUNCTION ACT --- Process and send string to characters in a room.
SYNOPSIS
#include "comm.h"
act(string, hide_invisible, ch, obj, vict_obj, type)
char *string; /* the string to send */
int hide_invisible, /* hide the action if vict can't see us? */
type; /* who gets the string */
struct char_data *ch; /* the 'performing' character */
struct obj_data *obj; /* an object */
void *vict_obj; /* an object OR a char OR an ascii string */
DESCRIPTION
This function is used to send a string to one or more characters in a room. The
string may contain certain control characters which are expanded before the
string is sent.
Obj and vict_obj are ignored if no reference is made to them (via CONTROL
CHARACTERS), and if type (see below) is set to TO_ROOM. Thus, null-pointers
may be supplied in this case. Ch should always be defined. If String is a
null-pointer or if string points to a null-character, nothing will be sent.
When the string has been parsed, it is capitalized and a newline is added.
CONTROL CHARACTERS
Each control character is preceded by a '$'.
$n - Write name, short description, or "someone", for ch, depending on
whether ch is a PC, a NPC, or an invisible PC/NPC.
$N - Like $n, except insert the text for vict_obj. NOTE: vict_obj must
point to an object of type struct char_data.
$m - "him", "her", or "it", depending on the gender of ch.
$M - Like $m, for vict_obj. NOTE: vict_obj must be a pointer of type
struct char_data.
$s - "his", "her", or "it", depending on the gender of ch.
$S - Like $s, for vict_obj.
$e - "he", "she", "it", depending on the gender of ch.
$E - Like $e, for vict_obj.
$o - Name or "something" for obj, depending on visibility.
$O - Like $o, for vict_obj. NOTE: vict_obj must be a pointer of type
struct obj_data.
$p - Short description or "something" for obj.
$P - Like $p for vict_obj.
$a - "an" or "a", depending on the first character of obj's name.
$A - Like $a, for vict_obj.
$T - Prints the string pointed to by vict_obj.
$F - Processes the string pointed to by vict_obj with fname() prior to
printing.
$u - Processes the buffer and uppercases the first letter of the previous
word (the word immediately prior to the control code). If there is
no previous word, no action is taken. -- CircleMUD addition (09/18/00)
$U - Processes the buffer and uppercases the first letter of the following
word (the word immediately after to the control code). If there is
no following word, no action is taken. -- CircleMUD addition (09/18/00)
$$ - Print the character '$'.
HIDE_INVISIBLE
If this parameter is nonzero, the action will be hidden to those who are
unable to see ch.
TYPE
This value determines who the string is sent to. It may take one of four
values (the macros are defined in comm.h).
TO_ROOM - Send the string to everybody in the room, except ch.
TO_VICT - Send the string to the character (!) pointed to by vict_obj.
TO_NOTVICT - Send the string to everybody in the room except ch and vict_obj.
TO_CHAR - Send the string to the ch.
EXAMPLES
act("$n smiles happily.", TRUE, ch, 0, 0, TO_ROOM);
(eg: Rainbird smiles happily.)
act("You kiss $M.", FALSE, ch, 0, vict, TO_CHAR);
(eg: You kiss her.)
act("$n gives $p to $N.", TRUE, ch, obj, vict, TO_NOTVICT);
(eg: Dave gives a small sword to the giant.)
act("$n gives you $p.", FALSE, ch, obj, vict, TO_VICT);
(eg: Dave gives you a small sword.)
act("$n puts $p in $s $O.", TRUE, ch, obj1, obj2, TO_ROOM);
(eg: Jones puts a small sword in his sack.)

389
old-codebase/doc/OLD-DOCS/database.doc Normal file
View File

@@ -0,0 +1,389 @@
/* ************************************************************************
* Copyright (C) 1990, 1991 - see 'license.doc' for complete information. *
************************************************************************* */
DATABASE DOCUMENTATION
"database.doc"
1. The world file:
==================
This file contains all the rooms, and is loaded once and for all at
boot-time. It follows the this format:
--------------------------------------------
#<virtual number>
<name>~
<description>~
<zone nr>
<room_flags>
<sector_type>
{<direction fields and extra descriptions>}
'S'
#<virtual number>
.
.
.
#99999
$~
Explanation of fields:
----------------------
<Direction fields> follow this format:
D<exit number>
<general description>~
<keyword list>~
<Door flag> <key number> <to_room>
Extra descriptions
------------------
Format:
'E'
<blank separated keyword list>~
<description>~
-----
NOTE:
All the text fields above may be left blank, but the '~' should always be
there.
On the 'virtual' number:
Since the rooms for this game are expected to be written by several people,
we have made it possible to number the rooms freely. Thus, it is possible to,
say, number the rooms in zone 0 from 0 to 1000, the rooms in zone 1 from 1000
to 2000, and so on. Rooms can then be added to the room file without
upsetting the various references to rooms. In the reset command-tables, as well
as in the exits, references to a given room are made via the virtual number
rather than the array index. At boot-time, these references are substituted
with the actual array indices in order to improve the game-time execution
speed. In such places (ie the special routines for mobs/objs/rooms) where
this substitution cannot take place, a function 'real_room', with prototype
int real_room(int virtual_number)
must be used. This functions performs a binary search on the array of rooms,
looking for a room with a given virtual number. If found, the function
returns the index to this room; if not, the game is halted.
Note: Since a binary search is used, the rooms MUST be sorted (in the
room-file) after their virtual number.
-----------------------------------------------------------------------------
2. Objects and monsters
=======================
The objects and mobiles are stored in two separate files. They are loaded
once at boot-time, and then each time their zone is reset, according to the
information stored in the ZONE-FILE.
The world is split up into a number of zones that are updated independently.
The exact nature of these updates are defined by the contents of the ZONE-FILE.
-----------------------------------------------------------------------------
2.1. The Monster file:
======================
The format of this file is as follows:
#<virtual number>
<namelist>~
<short description>~
<long description>~
<description>~
<action flags> <affection flags> <alignment> <Detailed/Simple flag>
IF <Old/Simple flag> != 'S' {
<strength> <intelligence> <wisdom> <dexterity> <constitution>
<hit low> <hit high> <armour> <mana> <movement> <gold> <exp>
<position> <default> <sex> <class> <level> <age> <weight> <height>
<condition 0> <condition 1> <condition 2>
<savingthrow 0> <savingthrow 1> <savingthrow 2> <savingthrow 3> <savingthrow 4>
} else { /* Simple monsters flag is 'S' */
<Level> <Thac0> <AC> <Hit Points (format is xdy+z)> <Damage (as HP)>
<Gold> <Exp>
<position> <default position> <sex>
}
#<virtual number>
.
.
.
#<virtual number>
$~
-----------------------------------------------------------------------------
2.3. The object file:
=====================
The format is as follows:
#<virtual number>
<namelist>~
<short description>~
<long description>~
<action description>~
<type flag> <extra flag> <wear flag>
<value 0> <value 1> <value 2> <value 3>
<weight> <value> <cost/day>
'E'
<keyword-list>~
<extra description>~
'E'
<keyword-list>~
<extra description>~
.
.
.
'E'
<keyword-list>~
<extra description>~
'A'
<location> <modifier>
.
.
'A'
<location> <modifier>
#<virtual number>
.
.
.
#<virtual number>
'$~'
-----------------------------------------------------------------------------
2.3. The zone-file
==================
The zone-file contains the following information for each zone:
a) The top room-number of the zone. A room belongs to a zone X if:
zone[X-1].top < virtual_room_number <= zone[X]
for X > 0. Rooms belong to zone 0 if their number is between 0 and the
top of zone 0.
b) The LIFESPAN of the zone. When the age of the zone (measured in minutes
after last reset) reaches this number, the zone is queued for reset. The
zone is then reset as soon as possible (more or less), depending on the
value of the RESET_MODE-variable.
c) The RESET_MODE. This may take on of three values:
0: Don't reset the zone at all. In this case, the age of the zone is never
updated, and it will never be queued for reset. Thus, the value of the
lifespan-field is effectively ignored.
1: Reset the zone as soon as it is deserted, ie as soon as there are no
players located within the zone.
2: Reset the zone no matter who or what is in it.
d) The COMMAND TABLE. This is a series of commands to execute at reset. The
table is terminated by the pseudo-command 'S', and thus follows the
following format:
<command>
<command>
.
.
.
<command>
'S'
Each command consists of a letter, identifying the command-type, followed
by three or four arguments. The first argument, common to all the commands,
is called the 'if-flag'. If it is true (nonzero), the command is executed
ONLY if the preceding command was executed. If it is false (zero), the
command is executed anyway.
The commands:
M (load a mobile):
Format: 'M' <if-flag> <mobile nr> <max existing> <room nr>
mobile nr and room nr should be self-explanatory. The 'max
existing' parameter specifies the maximum permissible number of
existing units. In other words: If you only want one manifestation
of a given monster, you just specify the number '1'. If the max
number is about to be exceeded, the command won't be executed.
O (load an object):
Format: 'O' <if-flag> <object nr> <max existing> <room nr>
Load an object and place it in a room. (NOT -1)
G (give object to mobile):
Format: 'G' <if-flag> <object nr> <max existing>
Loads an object, and gives it to the last monster referenced (ie. by the
M-command).
Of course, this command doesn't make sense if a new mobile+object
pair has not just been created, which is where the if-flag comes
in handy. :)
E (object to equipment list of mobile)
Format: 'E' <if-flag> <object nr> <max existing> <equipment position>
Loads object and places it in the Equipment list of the last monster
referenced.
Note that it is NOT necessary to precede this command with a 'G' command.
Equipment position is one of:
WEAR_LIGHT 0
WEAR_FINGER_R 1
WEAR_FINGER_L 2
WEAR_NECK_1 3
WEAR_NECK_2 4
WEAR_BODY 5
WEAR_HEAD 6
WEAR_LEGS 7
WEAR_FEET 8
WEAR_HANDS 9
WEAR_ARMS 10
WEAR_SHIELD 11
WEAR_ABOUT 12
WEAR_WAISTE 13
WEAR_WRIST_R 14
WEAR_WRIST_L 15
WIELD 16
HOLD 17
P (put object in object):
Format: 'P' <if-flag> <object_nr1> <max existing> <object nr2>
Loads object1 and places it in object2.
D (set state of door)
Format: 'D' <if-flag> <room nr> <exit nr> <state>
State being one of:
0: Open.
1: Closed.
2: Closed and locked.
R (remove object from room)
Format: 'R' <if-flag> <room_nr> <object_nr>
More commands will probably be needed, and will be added as required.
Format of the zone-file:
---------------------------------------
#<arbitrary number (ignored)>
<name>~
<top of zone>
<lifespan>
<reset mode>
<command>
<command>
.
.
.
<command>
'S'
#<arbitrary number>
.
.
.
#<arbitrary number>
$~
2.2. The monster file:
----------------------
The format of this file is as follows:
----------------------------------------------
#<virtual number>
<namelist>~
<short description>~
<long description>~
<description>~
<action flags> <affection flags> <Detailed/Simple flag>
IF <Old/Simple flag> != 'S' {
<strength> <intelligence> <wisdom> <dexterity> <constitution>
<hit low> <hit high> <armour> <mana> <movement> <gold> <exp>
<position> <default> <sex> <class> <level> <age> <weight> <height>
<condition 0> <condition 1> <condition 2>
<savingthrow 0> <savingthrow 1> <savingthrow 2> <savingthrow 3> <savingthrow 4>
} else { /* Simple monsters flag should be 'D' */
<Level> <Thac0> <AC> <Hit Points (format is xdy+z)> <Damage (as HP)>
<Gold> <Exp>
<position> <default position> <sex>
}
#<virtual number>
.
.
.
#<virtual number>
$~
----------------------------------------------
On the skill fields:
Format:
--------------
S<skill number>
<learned> <affected by> <duration> <recognize>
--------------
On the virtual numbers:
This number may be considered the 'label' of the mobile, for use in eg. the
zonefile (see also the text about the roomfile format). When the mobile is to
be referenced from within the code itself, the function real_mobile
(real_object for objects) can be used to find indices to the file-index tables
(this is only of use when writing special routines). These functions are
automatically called from read_object/read_mobile, depending on their 'type'
parameter (see db.doc).

600
old-codebase/doc/OLD-DOCS/dbsup.doc Normal file
View File

@@ -0,0 +1,600 @@
/* ************************************************************************
* Copyright (C) 1990, 1991 - see 'license.doc' for complete information. *
************************************************************************* */
DATABASE SUPPLEMENTAL DOCUMENTATION
"dbsup.doc"
World File field description:
=============================
Main structure notes:
---------------------
#<virtual number> is:
A number for the given room. No two rooms may have the same number.
The <virtual number> must always increase when browsing down the
world file (but increments can be larger than one).
<name>~<NL>:
This name is the "title" of the room. This title is also used in special
procedures like:
"exits"
"brief mode"
<description>~<NL>:
This is the general description of the room.
<zone nr> is:
The number of the zone in which this room is located. This number is used
for resetting zones and monster zone movement. See the zone file.
<room_flags> are:
A bitvector consisting of the room conditions as:
DARK 1 Light must be used to see anything.
DEATH 2 A player 'dies' (no xp lost) when entering.
It is a good idea to:
*Have these rooms light, because then EXITS will show
the room title, for example "In Boiling Water".
*Make exits to all rooms from which one can enter the
death_room, then the "death cry" will be heard by
other members of the group considering following...
NO_MOB 4 No monsters may walk around in here
INDOORS 8 This is inside (a house,cave or dungeon for example)
LAWFULL 16 ???
NEUTRAL 32 ???
CHAOTIC 64 ???
NO_MAGIC 128 Not implemented.
TUNNEL 256 ???
PRIVATE 512 It is impossible to teleport to this room if it
already contains two characters. The 'teleport'
spell will never teleport a player into this room.
GODROOM 1024 Super-private room: Immortals can not 'goto' this room.
BFS_MARK 2048 RESERVED FOR INTERNAL USE -- do not use.
??? means that the flag isn't used yet (and you Shouldn't use it either!)
<sector_type> is:
This determines how many movement points are used when moving through
a location of the type - use one of the numbers 0..7 (they are NOT the
movement-points used - merely indexes to a lookup-table):
SECT_INSIDE 0 Uses as if walking indoors
SECT_CITY 1 Uses as if walking in a city
SECT_FIELD 2 Uses as if walking in a field
SECT_FOREST 3 Uses as if walking in a forest
SECT_HILLS 4 Uses as if walking in hills
SECT_MOUNTAIN 5 Uses as if climbing in mountains
SECT_WATER_SWIM 6 Uses as if swimming
SECT_WATER_NOSWIM 7 Impossible to swim water - requires a boat
Direction fields:
-----------------
<Exit number> is one of:
0 = North
1 = East
2 = South
3 = West
4 = Up
5 = Down
<general description><NL>~<NL>:
What a player will see if he types 'look <direction>'
<keyword list>~<NL>:
used for commands like 'open', 'close', etc. should be 'door' for ordinary
doors. Example: An exit from a given room leads through a cupboard. The
keyword list for this exit might look like this:
"cupboard door~"
<Door flag> [NL]:
If <Door Flag> is 1, the exit can be locked/unlocked/opened/closed/picked.
If it is 2, the exit can only be locked/unlocked/opened/closed.
If it is 0, these commands won't work. (The exit can still be closed at
reset, however; maybe to be opened by some special routine, like a concealed
handle).
The state of the doors after reset may be controlled by a command in the
reset-command table (see the zone file). The initial state of a door is
open.
<Key Number> [NL]:
The number of the object which can unlock/lock the door (in the direction
given). If a player carries/holds this object, he can lock/unlock.
<Key Number> == -1 means no keyhole. If <Door flag> is 0, the value of this
field is ignored.
<to_room> <NL>:
The virtual number of the room to which the exit leads. If this number is
-1 (NOWHERE), the exit doesn't lead anywhere. This might be useful for
adding an exit-description in a direction which doesn't actually lead
anywhere.
** Note about doors. You must make a door in both rooms that the door
is set between.
Extra descriptions:
-------------------
<blank separated keyword list>~<NL> is:
A list of the keywords that will allow the extra description to be
displayed. The keywords must must be seperated by blanks.
<description><NL>~<NL>:
The description that is show when a player types 'look at <keyword>'
and keyword matches one of the above.
Example of a room entry is the database:
----------------------------------------
#100
The Lego temple~
You stand in a tiny, red temple built entirely from Lego bricks. It is,
sadly, not a very interesting place, and perhaps you should leave through
the portal which leads south to a sunny garden.
~
1 12 0
D2
You see the grand portal of the Lego church. Beyond is an inviting garden.
~
portal grand~
1 2 107
E
portal~
The portal is high and arched, built out of lego bricks of the finest quality.
~
E
brick~
The bricks are all in bright different colours.
~
S
#101
.
.
.
Facts about this room is:
Room number 100
Zone number 1
Room Flags (8+4=12) INDOORS and NO_MOB
Sector Type Inside (movement loss calc only)
One exit (D2) to the south with 'look south' description
Door Flag 1
Key no. 2
Leads to room 107
Extra description for the portal and bricks.
-------------------------------------------------------------------------
Monster fields description:
===========================
#<virtual number><NL> is:
The monsters virtual number. Rules are same as for room virtual numbers.
<namelist><!NL>~<NL>
The space-separated name alias list.
<short description><!NL>~<NL>
This string will be displayed when the monster take action, for example
if it is "The Beastly Fido", and fido leaves south the message will be
"The Beastly Fido leaves south."
<long description><NL>~<NL>
This description is displayed when the monster is in it's "default"
position. When not in the default position, a message like:
"<short description> is sleeping here." could be displayed.
<description><NL>~<NL>
This will be displayed when a player looks at the monster.
<action flags>[NL]
This bitvector define how the monster behave. The bits mean:
ACT_SPEC 1 This means that there is a special programmed C
procedure connected to the monster. When this bit
is set the monster "function pointer" must be
assigned in the "spec_assign.c" file.
ACT_SENTINEL 2 When this bit is set the monster will NOT
move around in the world.
ACT_SCAVENGER 4 When this bit is set, monsters will pick up stuff
lying on the ground. It will pick up the most
expensive items first.
ACT_ISNPC 8 RESERVED FOR INTERNAL USE
ACT_NICE_THIEF 16 When this bit is set, a monster will not attack
a thief which has been caught in the act of
stealing from this monster.
ACT_AGGRESSIVE 32 When this bit is set, the monster will attack and
attempt to kill any player it can get it's claws on.
It will not attack players it can't see (for example
dark rooms or when player is invisible, unless the
monster can detect invisibility)
ACT_STAY_ZONE 64 When this bit is set, the monster will never move
into another zone of the world (this is good for
keeping your monsters in your own adventure).
ACT_WIMPY 128 When this bit is set, the monster will flee when it's
getting percentwise low on hitpoints.
If the monster is both aggressive and wimpy, then it
will only attack players that are NOT awake! (ie. also
suffering players).
ACT_AGGRESSIVE_EVIL
256 When this bit is set, the monster will attack players
with evil alignment.
ACT_AGGRESSIVE_GOOD
512 When this bit is set, the monster will attack players
with good alignment.
ACT_AGGRESSIVE_NEUTRAL
1024 When this bit is set, the monster will attack players
who are neutrally aligned.
ACT_MEMORY 2056 When this bit is set, the monster will remember
players who attack it, and attack the player back
if it sees him or her again.
<affection flags>[NL]
This is a bitvector that indicates what the monster is affected by.
Puff could for example be able to "detect invisible" or maybe
"sanctuary" (1/2 damage). A lot of these bits are meant for players
only (in a context with a spell), and should NOT be used when indicated.
The bits are:
AFF_BLIND 1 RESERVED PLAYERS
AFF_INVISIBLE 2 The monster is invisible
AFF_DETECT_EVIL 4 RESERVED PLAYERS
AFF_DETECT_INVISIBLE 8 The monster can see invisible players
(Especially good for aggressive npc's)
AFF_DETECT_MAGIC 16 RESERVED PLAYERS
AFF_SENCE_LIFE 32 RESERVED PLAYERS
AFF_HOLD 64 ??? DO NOT USE
AFF_SANCTUARY 128 The monster has sanctuary (1/2 damage)
AFF_GROUP 256 RESERVED PLAYERS
AFF_CURSE 1024 ??? DO NOT USE
AFF_FLAMING 2048 ??? DO NOT USE
AFF_POISON 4096 RESERVED PLAYERS
AFF_PROTECT_EVIL 8192 ??? DO NOT USE
AFF_PARALYSIS 16384 ??? DO NOT USE
AFF_MORDEN_SWORD 32768 ??? DO NOT USE
AFF_FLAMING_SWORD 65536 ??? DO NOT USE
AFF_SLEEP 131072 RESERVED PLAYERS
AFF_DODGE 262144 ??? DO NOT USE
AFF_SNEAK 524288 The message "The xxx leaves direction" will
not be displayed when the monster moves
out/in to a room.
AFF_HIDE 1048576 The monster will be hidden, and can only
be detected by a "sense life" spell
AFF_FEAR 2097152 ??? DO NOT USE
AFF_CHARM 4194304 The monster will act as charmed when a
"follow <player>" is entered. Note that
players can't force monsters to follow
them.
AFF_FOLLOW 8388608 RESERVED PLAYERS
AFF_WIMPY 16777216 RESERVED PLAYERS
AFF_INFRARED 33554432 Allows monsters to see in the dark.
<Alignment Flag>[NL]
This is the monsters alignment, read as:
+1000 .. +350 Good Alignment
+349 .. -349 Neutral Alignment
-350 ..-1000 Evil Alignment
<Detailed/Simple flag><NL>
This flag must be entered as a uppercase "S". S indicates that "Simple"
monster data follow. Anything but an S will be interpreted as if
"Detailed" monster data is to follow. We will NOT describe detailed
monsters as they are VERY detailed.
<Level>
This is the level of the monster. See "defs.doc" for guidelines when
setting the level.
<THAC0>
The monsters THAC0.
See the file "defs.doc" for an explanation of armour vs. THAC0, and
guidelines for THAC0.
THAC0 is an abbrevation for "To Hit Armour Class Zero".
<AC>
The monsters armour class. See "defs.doc" for guidelines regarding
armour.
<Hit Points (format is xdy+z)>
This defines the number of hitpoints a given monster has. If this is
entered into the file:
... ... 3d8+10 ...
the monster will have 10 hitpoints plus the result of rolling 3 dice
with 8 side, and adding their sum. All the numbers (even zero), the
plus sign, and the letter 'd' MUST be entered!!! Example:
..... 1d6+0 ....
<Damage (as HP)><NL>
This is the damage a monster will cause when it is using NO weapons
(the Bare hand damage). The format is exacly like the one described
for hit points. A thing to note about damage:
The number after the plus sign, is the "strength bonus". This bonus
will apply to any weapons used, and bare hands too. Example:
..... 1d4+10
This monster will damage between 11 and 14 hitpoints each round. If the
monster picks up and wields a tiny stick which give 1d2 damage, then the
monster will now damage by : 1d2 + 10 points.
<Gold>
The amout of gold carried by the monster.
<Exp><NL>
The experience this monster has. Follow guidelines in "defs.doc".
<position>
This defines the monster's position when loaded into the game.
A position is one of:
POSITION_DEAD 0 DO NOT USE
POSITION_MORTALLYW 1 DO NOT USE
POSITION_INCAP 2 DO NOT USE
POSITION_STUNNED 3 DO NOT USE
POSITION_SLEEPING 4 The monster is sleeping.
POSITION_RESTING 5 The monster is resting.
POSITION_SITTING 6 The monster is sitting.
POSITION_FIGHTING 7 DO NOT USE.
POSITION_STANDING 8 The monster is standing.
<default position>
This is the position into which the monster will return after
a fight. This position also defines when the <long description>
is displayed - see above.
<sex><NL>
This is the monsters sex, on of:
SEX_NEUTRAL 0
SEX_MALE 1
SEX_FEMALE 2
No further explanation is needed (hopefully).
Object fields description:
==========================
#<virtual number><NL>
See rules for rooms above.
<namelist>~<NL>:
Same as for monsters above.
<short description>~<NL>
This string will be displayed when the object is used. For example
if it is "a rubber raft", and a player drops it, then a message like:
"Monthy drops a rubber raft."
could be displayed.
<long description>~<NL>
This description is displayed when the object is lying on the ground.
For example, if it is "A furled umbrella lies here.~" then this message
is displayed when the umbrella is lying on the ground.
<action description>~<NL>
Do not use.
<type flag>[NL]
This defines what kind of item you are defining, it can be one of:
ITEM_LIGHT 1 Item is a light.
ITEM_SCROLL 2 Not yet implemented
ITEM_WAND 3 Not yet implemented
ITEM_STAFF 4 Not yet implemented
ITEM_WEAPON 5 Item is a weapon
ITEM_FIREWEAPON 6 Not yet implemented
ITEM_MISSILE 7 Not yet implemented
ITEM_TREASURE 8 Item is a treasure (not money)
ITEM_ARMOR 9 Item is armour.
ITEM_POTION 10 Not yet implemented
ITEM_WORN 11 ???
ITEM_OTHER 12 Item is other
ITEM_TRASH 13 Item is trash
ITEM_TRAP 14 Not yet implemented
ITEM_CONTAINER 15 Item is a container
ITEM_NOTE 16 Item is a note that can be written upon (with a pen)
ITEM_DRINKCON 17 Item is a drink container, for example a bottle or
a barrel or a wine-skin.
A drinkcontainer whit contents must *always* have
two names: 1. The name of the drink, 2. the name
of the container, example:
tea cup~
ITEM_KEY 18 Item is a key
ITEM_FOOD 19 Item is food.
ITEM_MONEY 20 Item is money.
ITEM_PEN 21 Item is a pen.
ITEM_BOAT 22 Item is a boat, which must be carried by a player if
the player wishes to enter NOSWIM room sector types.
ITEM_FOUNTAIN 23 Item is a fountain (characters can drink from it
without having it in inventory).
<extra flag>[NL]
This bitvector defines mostly special effects:
ITEM_GLOW 1 The item is glowing.
ITEM_HUM 2 The item is "humming"/"buzzing".
ITEM_DARK 4 ???
ITEM_LOCK 8 ???
ITEM_EVIL 16 ???
ITEM_INVISIBLE 32 Item is invisible.
ITEM_MAGIC 64 Item will show a magical aura when 'detect magic'
is used.
ITEM_NODROP 128 Item can not be dropped (cursed for example)
ITEM_BLESS 256 Item is blessed.
ITEM_ANTI_GOOD 512 Item not usable by good people
ITEM_ANTI_EVIL 1024 Item not usable by evil people
ITEM_ANTI_NEUTRAL 2048 Item not usable by neutral people
ITEM_NORENT 4096 Players can not rent item
ITEM_NODONATE 8192 Players can not donate item
ITEM_NOINVIS 16384 Player can not make item invisible
<wear flag><NL>
This bitvector defines if items can be taken, and if they can be worn:
ITEM_TAKE 1 Item is takeable.
ITEM_WEAR_FINGER 2 Can be worn on a finger (rings usually)
ITEM_WEAR_NECK 4 Can be worn around neck.
ITEM_WEAR_BODY 8 Can be worn on body.
ITEM_WEAR_HEAD 16 Can be worn on head.
ITEM_WEAR_LEGS 32 Can be worn on legs.
ITEM_WEAR_FEET 64 Can be worn on feet
ITEM_WEAR_HANDS 128 Can be worn on hands (gauntlets, etc)
ITEM_WEAR_ARMS 256 Can be worn on arms.
ITEM_WEAR_SHIELD 512 Can be used as a shield.
ITEM_WEAR_ABOUT 1024 ???
ITEM_WEAR_WAISTE 2048 Can be worn around the waiste (belt)
ITEM_WEAR_WRIST 4096 Can be worn on wrist (bracelets)
ITEM_WIELD 8192 Can be wielded and used as a weapon
ITEM_HOLD 16384 Item can be held in a hand.
ITEM_THROW 32768 Not yet implemented.
Item can be thrown.
<value 0> <value 1> <value 2> <value 3> <NL>
These values are very central. They define the ability of items based on
the items <Item Type>. These values are defined in "values.doc". Note that
if you define an item as being anything but a weapon, you shouldn't set
the 'wield' flag. Many similar obvious rules apply. Example of 4 values:
If the <Item Type> == ITEM_CONTAINER then the values are interpeted as:
Value[0]: Maximum weight the container can contain.
Value[1]: Container flags:
CLOSEABLE - 1
PICKPROOF - 2
CLOSED - 4
LOCKED - 8
Value[2]: The item-number of the object which can open the object.
-1 means no lockability.
Value[3]: Internal use for Corpses that must "rot".
<weight>[NL]
The weight of the item in pounds.
<value>[NL]
The value of the item if sold - see "defs.doc" for ideas on prices.
<cost/day><NL>
The cost to store the item in the reception overnight.
Several extra descriptions or none at all may appear. They follow the room
format exactly.
'E'<NL>
<keyword-list>~<NL>
Exactly as in rooms.
<extra description><NL>~<NL>
Exactly as in rooms.
Between zero and two "affect's" may be set on an item. The affects could
for example modify a characters strength, height etc. The affect only goes
into affect when the character wear, wield or hold the item. The affect
is removed when the character removes the items.
'A'<NL>
When items are worn using wear/wield/grab/hold commands, the 'A' will
allow the items to affect a characters various abilities. Currently
a maximum of 2 'A' are allowed.
<location>[NL]
<location> is one of the below numbers, indicating which ability
will be changed.
APPLY_NONE 0 DO NOT USE.
APPLY_STR 1
APPLY_DEX 2
APPLY_INT 3
APPLY_WIS 4
APPLY_CON 5
APPLY_SEX 6 DO NOT USE.
APPLY_CLASS 7 DO NOT USE.
APPLY_LEVEL 8 DO NOT USE.
APPLY_AGE 9
APPLY_CHAR_WEIGHT 10
APPLY_CHAR_HEIGHT 11
APPLY_MANA 12 DO NOT USE.
APPLY_HIT 13 The MAXIMUM number of hitpoints.
APPLY_MOVE 14 DO NOT USE.
APPLY_GOLD 15 DO NOT USE.
APPLY_EXP 16 DO NOT USE.
APPLY_AC 17
APPLY_ARMOR 17 Same as APPLY_AC
APPLY_HITROLL 18 The bonus/penalty to hit the opponent.
APPLY_DAMROLL 19 The bouns/penalty to damage the opponent.
APPLY_SAVING_PARA 20 These five are saving throws.
APPLY_SAVING_ROD 21
APPLY_SAVING_PETRI 22
APPLY_SAVING_BREATH 23
APPLY_SAVING_SPELL 24 This is the most used saving throw.
<modifier><NL>
The modifier is added to the APPLY_XXX ability of the character
when he uses an item, and is subtracted when he stops using it.
Take great care when using this. This is an example of an item of
improve strength and armour class. Example:
A
1 2
A
17 -2
This adds +2 to the strength, and adds -2 to the AC (thus improving it).
No more 'A'ffects is allowed at this time.
-------------------------------------------------------------------------
Abbrevations:
=============
<contents> indicates that the contents MUST be entered.
[contents] indicates that the contents can OPTIONALLY be entered.
<NL> is Newline (return)
! This indicates "NOT" - for example <!NL> means NO newline (i.e. it is
forbidden to use newline here).

373
old-codebase/doc/OLD-DOCS/defs.doc Normal file
View File

@@ -0,0 +1,373 @@
/* ************************************************************************
* Copyright (C) 1990, 1991 - see 'license.doc' for complete information. *
************************************************************************* */
DIKUMUD DEFINITIONS AND STANDARDS TO OBEY
"defs.doc"
PC's ~ Players
NPC's ~ Non Players (Monsters)
<name> is used for short names
[x..y] is used to indicate min and max
PC's level [0..20], level [21..24] is special, not useable in gameplay.
NPC's level [0..30]
All PC's and NPC's have following abilities <ABIL>:
Strength <STR>
<PC> [3..18/100]
<NPC> [0..25]
Dexterity <DEX>
<PC> [3..18]
<NPC> [0..25]
Intelligence <INT>
<PC> [3..18]
<NPC> [0..25]
Wisdom <WIS>
<PC> [3..18]
<NPC> [0..25]
Constitution <CON>
<PC> [3..18]
<NPC> [0..25]
All PC's must select one of four classes :
Magic User <MU>
Cleric <CL>
Thief <TH>
Warrior <WA>
Every PC class have a Primary ability (requisite) <PR> :
<MU> <INT>
<CL> <WIS>
<TH> <DEX>
<WA> <STR>
When creating a new <PC>, the <PC>'s <ABIL> are calculated as:
NOTE: This is when being raised from level 0 to level 1!
The size of the <ABIL> dice, is determined by rolling 4 1d6 dice,
and adding the sum of the three largest dice.
The <ABIL> is sorted and assigned a <PC> in descending order,
depending on the class.
<MU> == <INT> <WIS> <DEX> <STR> <CON>
<CL> == <WIS> <INT> <STR> <DEX> <CON>
<TH> == <DEX> <STR> <CON> <INT> <WIS>
<WA> == <STR> <DEX> <CON> <WIS> <INT>
<HP> base is set as 10
<MANA> is allways set to 100
Set level as 1
Set exp as 1
Set theives abilities as basic.
Call the "Advance Level" routines!
Hitpoints:
<HP> ~ Hitpoints
<PC>'s gain in the following range when advancing a level.
<WA> [10..15] Average (12.5)
<TH> [7..13] Average (10.0)
<CL> [5..10] Average (7.5)
<MA> [3..8] Average (5.5)
Advancing a level (<PC>'s only):
<HP> is gained as above
"Spells to learn" is increased by
MIN(1, WIS_APPLY) for <WA> & <TH>
else
MIN(2, WIS_APPLY) for <MU> & <CL>
<NPC> <ABIL> follow <PC>'s <ABIL> up to level 20, with the
exception that NPC may have 0 in abilities. Only unusual
<NPC>'s are assigned abilities.
<PR> may be in 18/00..100 for Warriors ONLY!
============================= MONSTER LOOKUP ==============================
This is general guidelines for creating monsters. This is when creating
"S"impel monsters. Detailed monsters require a great deal of care when
designing, and it is not really worth it.
The idea is that a X level fighter is equal to about a X level monster!
This implies that the <THAC0> ought to decrease by one every level
(starting at '20' on level 1 - minimum is '1' from level 20+). The damage
given by a monster is also important - average weapon damage is at the
moment 1d8.
Level AVERAGE AVERAGE SUGGESTED SUGGESTED SUGGESTED
<HP> <EXP> <THAC0> <AC> <DAM>
0 [001..010] [25] 20 10 1d4+0 (2.5)
1 [011..022] [100] 20 9 1d5+0 (3.0)
2 [023..035] [200] 19 8 1d6+0 (3.5)
3 [036..047] [350] 18 7 1d7+0 (4.0)
4 [048..060] [600] 17 6 1d8+0 (4.5)
5 [061..072] [900] 16 5 2d4+0 (5.0)
6 [073..085] [1500] 15 4 1d8+1 (5.5)
7 [086..097] [2250] 14 4 2d4+1 (6.0)
8 [098..110] [3750] 13 3 2d5+1 (7.0)
9 [111..122] [6000] 12 3 2d5+1 (7.0)
10 [123..135] [9000] 11 2 2d6+1 (8.0)
11 [136..147] [11000] 10 2 2d6+1 (8.0)
12 [148..160] [13000] 9 2 2d7+1 (9.0)
13 [161..172] [16000] 8 2 2d7+1 (9.0)
14 [173..185] [18000] 7 1 2d8+1 (10.0)
15 [186..197] [21000] 6 1 2d8+2 (11.0)
16 [198..210] [24000] 5 1 2d8+2 (11.0)
17 [211..222] [28000] 4 1 3d6+2 (12.5)
18 [223..235] [30000] 3 0 3d6+2 (12.5)
19 [236..247] [35000] 2 0 3d6+3 (13.5)
20 [248..260] [40000] 1 0 3d6+4 (14.5) /* Minor Demons */
Above level 20 is for NPC's only
21 [261..350] [50000] 0 -1 3d7+4 (16.0)
22 [351..400] [60000] 0 -1 3d8+4 (17.5)
23 [401..450] [80000] 0 -2 3d8+4 (17.5) /* Shopkeepers, Important Guards */
24 [451..500] [100000] 0 -3 3d8+4 (17.5) /* Guildmasters */
25 [501..550] [130000] 0 -4 4d6+4 (18.0)
26 [551..600] [155000] 0 -6 4d6+4 (18.0) /* Major Demons/ Devils */
27 [601..650] [200000] 0 -7 4d6+4 (18.0) /* Demi Gods */
28 [651..700] [310000] 0 -8 4d6+5 (19.0) /* Lesser Gods */
29 [701..900] [450000] 0 -9 4d7+5 (21.0) /* Demon Lords/Arch Devils */
30 [901..1000] [600000] 0 -10 4d8+5 (23.0)/* Greater Gods */
------------------------------ GUIDELINES ---------------------------------
MAGICAL ITEMS:
--------------
In DikuMud it is possible to create all kinds of Magic items - but to avoid
chaos (having 1st levels kill 20 level dragons) these rules for Magic must
be obeyed.
It is possible to create almost any item. Items can (example) change the
<STR>, <DEX>, <WIS>, <INT>, <CON>, <HP>, Age, Weight, Height, XP,
etc. None of these changes are directly permanent in effetct, but may be
so indirectly - example:
Iggy found a helmet of Increase Wisdom/Intelligence (some + modifier).
When Iggy wears this helmet - these abilities improve, when he removes
the helmet they return to their original state. Thus no direct change
has happened. BUT if Iggy practices spells (upon which INT and WIS
determines the rate & success) he will learn them much faster than
normal. This was an example of an indirect change.
Good ideas when making Magic Items:
NEVER use large modifiers, exceptional items should modify at most by +3.
This includes, swords, armours, ability changes.
Impose a penalty on the Item - for example make a helmet of wisdom may
at the same time reduce the constitution. Or maybe a ring of masochism -
when you wear it your MAX-HITPOINT increase by +200, when you remove it
they disappear again. The ring likes to remove itself from the finger.
============================================================================
MONSTER CLASSIFICATIONS:
------------------------
Major Demon == Balrog/etc.
Demon Lords == Orcus/etc.
Demi Gods == ??
Lesser Gods == Heimdal/Sif/etc.
Greater Gods == Thor/Odin/etc.
Arch Devil == Asmodeus/etc.
When creating monsters pay attention to the table above.
Example of Monsters:
--------------------
============================================================================
--------------------------------------------
CHARACTER & MONSTER ARMOR:
<AC> range from [10..-10] this is what it means :
AC 10 = Naked person
AC 0 = Very heavily armoured person (Full plate mail at *all* body parts)
AC -10 = Armored Tank (Hopefully impossible for players)
--------------------------------------------
Percentwise Coverage of Armour
and allowed AC range
Location Protects Range
-------- -------- -----
Body 30% [1..10]
Head 20% [1..10]
Legs 20% [1..10]
Feet 10% [1..10]
Arms 10% [1..10]
Hands 10% [1..10]
Shield 10% [1..10]
Magic 10% [1..10]
--------------------------------------------
PRICE GUIDELINES
AC BODY LEGS HEAD ARMS FEET ARMOUR
---- ---- ---- ---- ---- ---- ------
+1 100 50 50 25 25 Cloth (Heavy)
+2 200 100 100 50 50 Soft Leather
+3 500 150 150 75 75 Studded Leather
+4 1,000 500 500 250 250 Scale Mail
+5 2,500 1,250 1,250 625 625 Chain Mail
+6 7,000 3,500 3,500 1,750 1,750 Bronze Plate Mail
+7 18,000 9,000 9,000 4,500 4,500 Plate Mail
+8 35,000 17,500 17,500 8,750 8,750 Field Plate Mail
+9 50,000 25,000 25,000 12,500 12,500 Full Plate
+10 75,000 37,500 37,500 18,750 18,750 Anti Bomb ShieldPlate
*Hands and shields should be regarded as arms.
--------------------------------------------
IMPORTANT NOTICE
Rare items may only exist in minimal quantities!
Especially you should limit the occurence of
magical protection, since it is easy to carry.
============================================================================
Weapons & Carrying capacity
---------------------------
The weight of a weapon determines the strength needed to wield the weapon,
these values should be used:
STR Max. Weapon Weight Carrying capacity
--- ------------------ -----------------
0 0 0
1 1 3
2 2 3
3 3 10
4 4 25
5 5 55
6 6 80
7 7 90
8 8 100
9 9 100
10 10 115
11 11 115
12 12 140
13 13 140
14 14 170
15 15 170
16 16 195
17 18 220
18 20 255
18/01..50 22 280
18/51..75 24 305
18/76..90 26 330
18/91..99 28 380
18/100 30 480
Strength above 18/100 is only used by NPC's - not used by players.
No weapon may ever exceed 30 pounds in weight.
There are three kind of weapons :
(P)iercing
(S)lashing (Not useable by Clerics)
(B)ludgeoning
Backstabbing is only possible with piercing weapons.
No weapon may ever exceed 4d6 damage (as total of magic bouns too)!
(4d6 is 14 damage as average since 4*((1+6)/2)==14)
No weapon may ever exceed 30 pounds in weight.
No shop-produced weapon may exceed 2d8 in total damage or weigh more
than 20 pounds.
Read notes regarding Magic before making a monster-slayer +50 +70
with +800 to strength
PRIMARY BUYABLE WEAPONS <PBW>:
Name Damage Type Cost Weight Cost_pr_day
--------------- ----- ---- ---- ------ -----------
Dagger 1d4 P 10 1 Cost/3
Small sword 1d6 P 60 3 Cost/3
Long sword 1d8 S 600 8 Cost/3
Wooden Club 1d3 B 12 3 Cost/3
War hammer 1d5 B 50 6 Cost/3
===========================================================================
Notes:
<THAC0> this is the number needed to roll on a 20-sided dice to hit
opponent <AC> equivalent of zero. A 20 is always considered
a hit, a 1 is always a miss. Example:
Your <THAC0> is 14 (ei. level 7 fighter). You are fighting
an opponent with <AC> '3'. Thus to hit <AC> 0 you must
roll a 14 or greater. To hit <AC> 3 you must then roll
11 (14-3) or greater. If you had to hit <AC> '-3' you
would have to roll 17 (14-(-3)) or greater on a 20 sided
dice.

6
old-codebase/doc/OLD-DOCS/do_mail Executable file
View File

@@ -0,0 +1,6 @@
mail -s "CircleMUD World Builders' Documentation (1/5)" $1 < database.doc
mail -s "CircleMUD World Builders' Documentation (2/5)" $1 < dbsup.doc
mail -s "CircleMUD World Builders' Documentation (3/5)" $1 < defs.doc
mail -s "CircleMUD World Builders' Documentation (4/5)" $1 < shop.doc
mail -s "CircleMUD World Builders' Documentation (5/5)" $1 < values.doc

117
old-codebase/doc/OLD-DOCS/files.doc Normal file
View File

@@ -0,0 +1,117 @@
/**************************************************************************
* Copyright (C) 1993 - see 'license.doc' for complete information. *
**************************************************************************/
CircleMUD File Manifest
The main circle directory has the following subdirectories and files:
README - Information for the new CircleMudder
automaint - shell script to perform maintenance .. see running.doc
autorun - shell script to run the MUD .. see running.doc
bin/ - directory of all the compiled programs (binaries)
doc/ - documentation
lib/ - MUD data (playerfile, world files, etc.)
log/ - system logs
src/ - source code
syslog - the current system log
The bin/ directory contains only binaries: 'circle' (the main MUD) and
its utilities, which are described in utils.doc.
The doc/ directory has its own README file, describing the contents of
each of the documentation files.
The lib/ directory contains the following subdirectories:
etc - Files which the MUD uses internally (playerfile, mail, etc.)
misc - Misc. database files meant to be changed (i.e. socials)
plrobjs - Player object hierarchy and utility scripts
text - Text files such as MOTD, news, help, etc.
world - The world hierarchy
The lib/etc directory contains the following files (the MUD actively maintains
these files while it is running; they should not be modified unless the game
is down):
Board.* - Binary files with the contents of the bulletin boards
badsites - List of banned sites
hcontrol - Binary file with the state of the house control system
players - Binary file containing data on all players
plrmail - Binary file containing player mail
The lib/misc directory contains the following files:
bugs - Bugs reported by players with the 'bug' command
ideas - Ideas from players from 'idea' command
messages - Spell and skill damage messages
socials - Text file with text of the socials
typos - Typos reported by players with the 'typo' command
xnames - Text file of invalid names
The lib/plrobjs contains the following files and directories:
a-e \
f-j \
k-o \ Subdirectories where player objects files are stored
p-t /
u-z /
zzz/
purgedir - Script to purge an object dir (meant for use by purgeobjs)
purgeobjs - Script to purge player objects (see utils.doc)
searchfor - Script to search for objects in obj files (see utils.doc)
The lib/text directory contains the following files:
background - Background story (for option 3 from main menu)
credits - Text for 'credits' command
handbook - Text for Immortal Handbook ('handbook' command)
help - Text for 'help' command with no arguments
help_table - File of all help entries for 'help' command
immlist - Text for 'immlist' command
imotd - Immortal MOTD -- seen by immortals on login
info - Text for 'info' command
motd - MOTD -- seen by mortals on login
news - Text for 'news' command
policies - Text for 'policy' command
wizlist - Text for 'wizlist' command
The lib/world directory contains the following subdirectories:
mob - Contains *.mob files (mobile files)
obj - Contains *.obj files (object files)
shp - Contains *.shp files (shop files)
wld - Contains *.wld files (world files)
zon - Contains *.zon files (zone files)
Each of the 5 subdirectories in the lib/world directory also contains
two additional files -- one called 'index', which specifies which files
in that directory should be loaded when the MUD boots, and 'index.mini',
which specifies which files should be loaded if the MUD is booted with
the -m (mini-mud) option.
The log/ directory contains several files of the form syslog.n, where n
is a small number. These are the most recent CircleMUD syslogs.
In addition, it contains the following more permanent system logs:
badpws - Records of bad password attempts
delete - Players who have self-deleted
dts - Players who have hit death traps
errors - MUD system errors ("SYSERR" messages)
levels - Records of all levels gained by all players
newplayers - Records of the creation of new players
rentgone - Players who have lost their items in rent
restarts - List of times at which the MUD rebooted
rip - Player deaths
usage - Mud system usage (player load & memory usage info)
The src directory contains all of the C and header files for the MUD,
along with a Makefile. The src/util directory contains source for
CircleMUD's utility programs. See running.doc for more information
on how to compile the MUD. See utils.doc for more information on how
to use CircleMUD's utilities.

214
old-codebase/doc/OLD-DOCS/hacker.doc Normal file
View File

@@ -0,0 +1,214 @@
=============================================================================
The following documentation is excerpted from Merc 2.0's 'hacker.txt' file.
It was written by Furey of MERC Industries and is included here with his
permission. I've packaged it with Circle (very slightly changed in a couple
of places, i.e. specific filenames) because it offers good advice and insight
into the art and science of software engineering.
=============================================================================
=== 'I'm running a Mud so I can learn C programming!'
Yeah, right.
The purpose of this document is to record some of our knowledge, experience and
philosophy. No matter what your level, we hope that this document will help
you become a better software engineer.
Remember that engineering is work, and NO document will substitute for your
own thinking, learning and experimentation.
=== How to Learn in the First Place
(1) Play with something.
(2) Read the documentation on it.
(3) Play with it some more.
(4) Read documentation again.
(5) Play with it some more.
(6) Read documentation again.
(7) Play with it some more.
(8) Read documentation again.
(9) Get the idea?
The idea is that your mind can accept only so much 'new data' in a single
session. Playing with something doesn't introduce very much new data, but it
does transform data in your head from the 'new' category to the 'familiar'
category. Reading documentation doesn't make anything 'familiar', but it
refills your 'new' hopper.
Most people, if they even read documentation in the first place, never return
to it. They come to a certain minimum level of proficiency and then never
learn any more. But modern operating systems, languages, networks, and even
applications simply cannot be learned in a single session. You have to work
through the two-step learning cycle MANY times to master it.
=== Basic Unix Tools
'man' -- gives you online manual pages
'grep' -- stands for 'global regular expression print'
'vi'
'emacs'
'jove' -- use whatever editor floats your boat
but learn the hell out of it
you should know EVERY command in your editor
'ctags' -- makes 'tags' for your editor
allows you to goto functions by name in any source file
'>'
'>>'
'<'
'|' -- input and output redirection
get someone to show you, or dig it out of 'man csh'
These are the basic day-in day-out development tools. Developing without
knowing how to use ALL of these well is like driving a car without knowing how
to change gears.
=== Debugging: Theory
Debugging is a science. You formulate a hypothesis, make predictions based on
the hypothesis, run the program and provide it experimental input, observe its
behavior, and confirm or refute the hypothesis.
A good hypothesis is one which makes surprising predictions which then come
true; predictions that other hypotheses don't make.
The first step in debugging is not to write bugs in the first place. This
sounds obvious, but sadly, is all too often ignored.
If you build a program, and you get ANY errors or ANY warnings, you should fix
them before continuing. C was designed so that many buggy ways of writing code
are legal, but will draw warnings from a suitably smart compiler (such as 'gcc'
with the '-Wall' flag enabled). It takes only minutes to check your warnings
and to fix the code that generates them, but it takes hours to find bugs
otherwise.
'Desk checking' (proof reading) is almost a lost art in 1993. Too bad. You
should desk check your code before even compiling it, and desk-check it again
periodically to keep it fresh in mind and find new errors. If you have someone
in your group whose ONLY job it is to desk-check other people's code, that
person will find and fix more bugs than everyone else combined.
One can desk-check several hundred lines of code per hour. A top-flight
software engineer will write, roughly, 99% accurate code on the first pass,
which still means one bug per hundred lines. And you are not top flight.
So ... you will find several bugs per hour by desk checking. This is a very
rapid bug fixing technique. Compare that to all the hours you spend screwing
around with broken programs trying to find ONE bug at a time.
The next technique beyond desk-checking is the time-honored technique of
inserting 'print' statements into the code, and then watching the logged
values. Within Circle code, you can call 'printf' or 'fprintf' to dump
interesting values at interesting times. Where and when to dump these values
is an art, which you will learn only with practice.
If you don't already know how to redirect output in your operating system, now
is the time to learn. On Unix, type the command 'man csh', and read the part
about the '>' operator. You should also learn the difference between
'standard output' (e.g. output from 'printf') and 'error output' (e.g. output
from 'fprintf').
Ultimately, you cannot fix a program unless you understand how it's operating
in the first place. Powerful debugging tools will help you collect data, but
they can't interpret it, and they can't fix the underlying problems. Only you
can do that.
When you find a bug ... your first impulse will be to change the code, kill the
manifestation of the bug, and declare it fixed. Not so fast! The bug you
observe is often just the symptom of a deeper bug. You should keep pursuing
the bug, all the way down. You should grok the bug and cherish it in fullness
before causing its discorporation.
Also, when finding a bug, ask yourself two questions: 'what design and
programming habits led to the introduction of the bug in the first place?'
And: 'what habits would systematically prevent the introduction of bugs like
this?'
=== Debugging: Tools
When a Unix process accesses an invalid memory location, or (more rarely)
executes an illegal instruction, or (even more rarely) something else goes
wrong, the Unix operating system takes control. The process is incapable of
further execution and must be killed. Before killing the process, however, the
operating system does something for you: it opens a file named 'core' and
writes the entire data space of the process into it.
Thus, 'dumping core' is not a cause of problems, or even an effect of problems.
It's something the operating system does to help you find fatal problems which
have rendered your process unable to continue.
One reads a 'core' file with a debugger. The two most popular debuggers on
Unix are 'adb' and 'gdb', although occasionally one finds 'dbx'. Typically
one starts a debugger like this: 'adb bin/circle' or 'gdb bin/circle lib/core'.
The first thing, and often the only thing, you need to do inside the debugger
is take a stack trace. In 'adb', the command for this is '$c'. In gdb,
the command is 'backtrace'. In dbx, the command is 'where'. The stack trace
will tell you what function your program was in when it crashed, and what
functions were calling it. The debugger will also list the arguments to these
functions. Interpreting these arguments, and using more advanced debugger
features, requires a fair amount of knowledge about assembly language
programming.
If you have access to a program named 'Purify' ... learn how to use it.
=== Profiling
Here is how to profile a program:
(1) Remove all the .o files and the 'circle' executable:
rm src/*.o bin/circle
(2) Edit your makefile, and change the PROFILE= line:
PROFILE = -p
(3) Remake circle:
make
(4) Run circle as usual. Shutdown the game with shutdown when you have run long
enough to get a good profiling base. If you crash the game, or kill the
process externally, you won't get profiling information.
(5) Run the 'prof' command:
prof bin/circle > prof.out
(6) Read prof.out. Run 'man prof' to understand the format of the output.
For advanced profiling, you can use 'PROFILE = -pg' in step (2), and use the
'gprof' command in step 5. The 'gprof' form of profiling gives you a report
which lists exactly how many times any function calls any other function. This
information is valuable for debugging as well as performance analysis.
Availability of 'prof' and 'gprof' varies from system to system. Almost every
Unix system has 'prof'. Only some systems have 'gprof'.
=== Books for Serious Programmers
Out of all the thousands of books out there, three stand out:
Kernighan and Plaugher, _The Elements of Programming Style_.
Kernighan and Ritchie, _The C Programming Language_.
Brooks, _The Mythical Man Month_

79
old-codebase/doc/OLD-DOCS/handler.doc Normal file
View File

@@ -0,0 +1,79 @@
/* ************************************************************************
* Copyright (C) 1990, 1991 - see 'license.doc' for complete information. *
************************************************************************* */
Description of module 'handler.c'.
*** Note: All the routines that takes something away from something assumes
that something is actually in/carried by something!
void char_from_room(struct char_data *ch)
Removes ch from whatever room he's in.
void char_to_room(struct char_data *ch, int room)
Places ch in room.
void object_to_char(struct obj_data *object, struct char_data *ch)
Gives object to ch.
void object_from_char(struct obj_data *object)
Takes object away from The character who is carrying it.
struct obj_data *find_object_in_list(char *name, struct obj_data *list)
This procedure assumes that list points to the head of a content-list of
objects. It then tries to locate the object with a given name within that
list. If succesful, the function returns a pointer to that object; if not,
it returns a null pointer.
struct obj_data *find_obj(char *name)
This function searches the 'global' list of objects (pointed to by
'object_list') for an object with a given name. It then returns either
a null pointer or a pointer to that object (note that in this version,
it will always return the first occurence of an object with a given name).
struct char_data *get_char_room(char *name, int room)
Searches room for character with 'name'. Returns null or pointer to that
character.
struct char_data *get_char(char *name)
Searches the entire world for a character. Assumes that all characters are
in a list pointed to by character_list (This might need changing).
void object_to_room(struct obj_data *object, int room)
Puts an object in a room.
void object_from_room(struct obj_data *object)
void object_to_object(struct obj_data *obj, *obj_to)
void object_from_object(struct obj_data *obj, *obj_from)
void extract_char(struct char_data *ch)
Extracts a character completely from the world, and leaves his stuff in
the room (might be useful.. might not..).
**** Higher level versions of the 'find' routines.
These routines work like the above versions, with the exception that they are
supplied with a pointer to a character as well as a keyword to look for. they
then return nil if they fail to locate the object/character OR if the character
'using' the routine can't see the searched-for object/character.
struct char_data *get_char_room_vis(struct char_data *ch, char *name)
struct char_data *get_char_vis(struct char_data *ch, char *name)
struct obj_data *find_object_in_list_vis(struct char_data *ch, char *name,
struct obj_data *list)
/*search the entire world for an object, and return a pointer */
struct obj_data *find_obj_vis(struct char_data *ch, char *name)

13
old-codebase/doc/OLD-DOCS/header Normal file
View File

@@ -0,0 +1,13 @@
/**************************************************************************
* Copyright (C) 1993 - see 'license.doc' for complete information. *
**************************************************************************/
HOW TO CONVERT YOUR IDEAS INTO REALITY
A CircleMUD Coding Manual
Table of Contents
---------------------------------------------------------------------------
i. Introduction
1. Overview and Coding Basics

117
old-codebase/doc/OLD-DOCS/license.doc Normal file
View File

@@ -0,0 +1,117 @@
This file contains the original DikuMUD license. Since CircleMUD is based
on DikuMUD, the DikuMUD license applies to CircleMUD. Note well: the use
of CircleMUD in any capacity implies that you have read, understood, and
agreed to abide by the terms and conditions set down by this license.
Jeremy Elson
Department of Computer Science
Johns Hopkins University
Baltimore, MD 21218 USA
---------------------------------------------------------------------------
/* ************************************************************************
* Copyright (C) 1990, 1991 *
* All Rights Reserved *
************************************************************************* */
DikuMud License
Program & Concept created by
Sebastian Hammer
Prss. Maries Alle 15, 1
1908 Frb. C.
DENMARK
(email quinn@freja.diku.dk)
Michael Seifert
Nr. Soeg. 37C, 1, doer 3
1370 Copenhagen K.
DENMARK
(email seifert@freja.diku.dk)
Hans Henrik St{rfeldt
Langs} 19
3500 V{rl|se
DENMARK
(email bombman@freja.diku.dk)
Tom Madsen
R|de Mellemvej 94B, 64
2300 Copenhagen S.
DENMARK
(email noop@freja.diku.dk)
Katja Nyboe
Kildeg}rdsvej 2
2900 Hellerup
31 62 82 84
DENMARK
(email katz@freja.diku.dk)
This document contains the rules by which you can use, alter or publish
parts of DikuMud. DikuMud has been created by the above five listed persons
in their spare time, at DIKU (Computer Science Instutute at Copenhagen
University). You are legally bound to follow the rules described in this
document.
Rules:
!! DikuMud is NOT Public Domain, shareware, careware or the like !!
You may under no circumstances make profit on *ANY* part of DikuMud in
any possible way. You may under no circumstances charge money for
distributing any part of dikumud - this includes the usual $5 charge
for "sending the disk" or "just for the disk" etc.
By breaking these rules you violate the agreement between us and the
University, and hence will be sued.
You may not remove any copyright notices from any of the documents or
sources given to you.
This license must *always* be included "as is" if you copy or give
away any part of DikuMud (which is to be done as described in this
document).
If you publish *any* part of dikumud, we as creators must appear in the
article, and the article must be clearly copyrighted subject to this
license. Before publishing you must first send us a message, by
snail-mail or e-mail, and inform us what, where and when you are
publishing (remember to include your address, name etc.)
If you wish to setup a version of DikuMud on any computer system, you
must send us a message , by snail-mail or e-mail, and inform us where
and when you are running the game. (remember to include
your address, name etc.)
Any running version of DikuMud must include our names in the login
sequence. Furthermore the "credits" command shall always cointain
our name, addresses, and a notice which states we have created DikuMud.
You are allowed to alter DikuMud, source and documentation as long as
you do not violate any of the above stated rules.
Regards,
The DikuMud Group
Note:
We hope you will enjoy DikuMud, and encourage you to send us any reports
on bugs (when you find 'it'). Remember that we are all using our spare
time to write and improve DikuMud, bugs, etc. - and changes will take their
time. We have so far put extremely many programming hours into this project.
If you make any major improvements on DikuMud we would be happy to
hear from you. As you will naturally honor the above rules, you will receive
new updates and improvements made to the game.

298
old-codebase/doc/OLD-DOCS/release.doc Normal file
View File

@@ -0,0 +1,298 @@
CircleMUD Release History
-------------------------
This document is basically just a a compliation of all the README files
which accompanied each release of CircleMUD. At the end is the post
to rec.games.mud.diku which originally anounced CircleMUD as a publically
available MUD source code.
Version 2.20: November 17, 1993
Version 2.11: September 19, 1993
Version 2.10: September 1, 1993
Version 2.02: Early August
Version 2.01: July 20, 1993
Version 2.00: July 16, 1993
The latest version of Circle is 2.20, released on November 17, 1993.
Version 2.20 supercedes version 2.11, which was released on September 19, 1993.
Version 2.20 November 17, 1993
--------------------------------
New features:
o A completely new output buffering system which is far more network-efficient,
and somewhat more memory- and speed-efficient, than the original Diku system.
Definitely a major win for people with slow Net links. (Details available
by request, but this was discussed on rgmd recently.) Several other
functions (such as do_where() and do_who()) have been rewritten to take
advantage of the new system.
o Redesigned stat screens with better readability
o Command-line substitution via the "^" character (works identically to the
csh command)
o Code sent by Jeff Fink (thanks Jeff!): Help now handles ambiguous cases
correctly (i.e., "help color" will give you help for color and not
colorspray)
o vstat command to stat mobiles and object by virtual number
o updated documentation
And, bug fixes of varying degrees of severity:
o SunOS Bus errors on stealing
o +hit item bug
o Switched immort re-login bug
o Mob memory bug
o Poison/Stat bug (I think this one is native to Diku Gamma 0.0 -- the
function hit_gain was responsible for subtracting hits when a char is
poisoned, so you'd lose hits when someone statted you.)
o Stat room bug under Solaris and IRIX
o Ungroup bug
o "goto 3.guard" now works (takes you to the third guard instead of room 3)
o various other minor fixes
------------------------------------------------------------------------------
Version 2.11 September 19, 1993
----------------------------------
Changes in 2.11 (from 2.10):
Mostly bug fixes, including:
-- SET FILE bug
-- SIGBUS/unaligned data errors under SunOS and other OS's
-- Move limit modifier bug
-- wrist-wearing bug
-- Compilation problems with utility.c under some operating systems
The only notable change is that the hit_limit, move_limit, and mana_limit
functions have been removed (for many reasons). From the players' point of
view, this means that a character no longer gains movement points with age.
Hit, move, and mana gain speeds are still a function of age, however.
============================================================================
Version 2.10 was released on September 1, 1993.
Changes in 2.10 (from 2.01):
o Rewritten get/put/drop/junk/donate/give/wear/remove, so that "all" and
"all.x" work in a much wider variety of cases. Loosely based on code
sent in by Jeff Fink.
o "Track" function based on breadth-first search
o Configurable auto-save feature to automatically crash-save players
periodically
o More intense error-checking in object saving system to detect problems
with file permissions
o Many configuration options added to config.c
o Option to make death traps automatically have dump spec-proc assigned
o ASPELL and ACAST macros added to match the ACMD macros; spells1.c,
spells2.c, spell_parser.c, and magic.c changed to use the macros.
o SKILL macro split into GET_SKILL and SET_SKILL macros so that error
checking can be done
o Enhanced documentation -- a help entry now exists for every command
o Linux compatibility, and further steps to SVR4 compatibility which will
make it into Circle eventually. (Note: you must make a change in one
line of the Makefile for Linux compatibility.)
o All functions now prototyped before use
Jeremy Elson
August 31, 1993
=========================================================================
=========================================================================
Version 2.01 is basically the same as 2.00; most of the changes are for
making the MUD more portable, based on mail I've received after the
release of version 2.00.
-- Problems with OPEN_MAX and SEEK_x resolved
-- Some problems with the Makefile fixed
-- Compiles much more cleanly with the -Wall option
-- A couple of minor bugs fixed
-- A few small fixes to the documentation
July 20, 1993
--------------------------------------------------------------------------
CircleMUD was developed and tested under Ultrix 4.0; your mileage may vary.
If I have time, I'll try and port it to other machines. If you port it and
want to share your work with others, feel free to drop me a line.
The CircleMUD 'press release' is included below, in case you haven't seen
it and want to.
Good Luck!
Jeremy Elson aka Rasmussen (Ras)
July 16, 1993
---------------------------------------------------------------------------
Wake the kids and find the dog, because it's the FTP release of
C I R C L E M U D 2 . 0
That's right -- CircleMUD 2.0 is done and is now available for anonymous FTP
at ftp.cs.jhu.edu!
CircleMUD is highly developed from the programming side, but highly UNdeveloped
on the game-playing side. So, if you're looking for a huge MUD with billions
of spells, skills, classes, races, and areas, Circle will probably disappoint
you severely. Circle still has only the 4 original Diku classes, the original
spells, the original skills, and about a dozen areas.
On the other hand, if you're looking for a highly stable, well-developed,
well-organized "blank slate" MUD on which you can put your OWN ideas for
spells, skills, classes, and areas, then Circle might be just what you're
looking for.
Just take a gander at some of Circle's nifty features:
-- In-memory mobile and object prototypes and string sharing for
decreased memory usage and blazingly fast zone resets
-- All large realloc()s have been removed and replaced by boot-time
record counting and a single malloc() for superior memory efficiency
-- Split world/obj/mob/zon/shp files for easy addition of areas; plus,
all the world files are still in the original Diku format for
compatibility with existing areas
-- Boot-time and run-time error checking of most data files with
diagnostic messages a lot more helpful than "segmentation fault"!
-- Player mail system and bank
-- Rewritten board system: boards are now stable, robust, more
intelligent, and easily expandable -- adding a new board is
as easy as adding another line to an array
-- ANSI color codes with a fully documented programmers' interface
-- On-line system logs
-- Optional automatically regenerating wizlist -- a final end
to new immortals constantly asking you when they'll be added
to the immlist!
-- "config.c" file allows you to change aspects of the game such
as playerkilling/playerthieving legality, max number of objects
rentable, and nameserver usage -- WITHOUT recompiling the
entire MUD!
-- All text (help, mortal/immort MOTDs, etc.) is rebootable at
run-time with the "reboot" command
-- All players are given a unique serial number -- no more messy,
time consuming str_cmp()s when you're trying to identify people!
-- Fully integrated and robust rent/crash system -- allows normal
renting, cryo-renting, crash protection, and forced rent
(at an increased price) after an hour of idling
-- All the standard wizard stuff you're used to: level-sensitive
invisibility, settable poofin/poofouts, wizline
-- Advanced 'set' command which allows you to set dozens of aspects
of players -- even if they aren't logged in! "Stat" also allows
you to stat people who aren't logged in!
-- Intelligent 'autorun' script handles different types of reboots,
organizing your system logs, and more!
-- Circle comes with more than a dozen utilities, all fully
documented, to make maintenance a snap!
-- And much, much more!
Unfortunately, the original Circle had more than its fair share of Bad People
when it was alive, but it DID lead to an impressive list of security and
"asshole control" features:
-- 3 types of sitebanning available: 'all' to refuse all connections,
'new' to refuse new players, or 'select' to refuse new players and
all registered players who don't have a SITEOK flag.
-- 'wizlock' allows you to close the game to all new players or all
players below a certain level.
-- Handy 'mute' command squelches a player off of all public
communication channels
-- Handy 'freeze' command freezes a player in his tracks: the MUD
totally ignores all commands from that player until he's thawed.
-- Even handier DELETE flag allows you to delete players on the fly.
-- 'set' command (mentioned above) allows you to freeze/unfreeze/
delete/siteok/un-siteok players -- even if they aren't logged in!
-- Bad password attempts are written to the system log and saved;
if someone tries to hack your account, you see "4 LOGIN FAILURES
SINCE LAST SUCCESSFUL LOGIN" next time you log on.
-- Passwords don't echo to the screen; allows 3 bad PW attempts
before disconnecting you.
-- Players aren't allowed to choose their character's name as their
password -- you'd be surprised how many do!
-- "xnames" text file specifies a list of invalid name substrings
to prevent creation of characters with overly profane names.
Listen to all the rave reviews of CircleMUD 2.0!
"How long ago was that deadline you set for yourself?" -- My Friend
"NO ONE should be denied the power of computation." -- My Professor
"Multi-user WHAT?" -- My Mom
Give it a try -- what do you have to lose other than your GPA/job, friends,
and life?
---------------------------------------------------------------------------
Circle's complete source code and areas are available now for anonymous FTP
at ftp.cs.jhu.edu (128.220.13.50) in the directory pub/CircleMUD.
I welcome comments and constructive criticism about CircleMUD and would be
happy to discuss any design decisions I've made, but I'm not particularly
receptive to lunatics frothing at the mouth and thus will probably ignore
you if you flame me.
Also, remember the odds here: one person (me) against 29,000 lines of
code (Circle), so there are bound to be some mistakes in there somewhere.
Good luck, and happy Mudding,
Jeremy Elson aka Ras

402
old-codebase/doc/OLD-DOCS/running.doc Normal file
View File

@@ -0,0 +1,402 @@
/**************************************************************************
* Copyright (C) 1993 - see 'license.doc' for complete information. *
**************************************************************************/
----- Compiling, Running, and Maintaining CircleMUD -----
This manual is meant to be read by implementors just getting started with
CircleMUD. This should be the first document you should read after reading
the main README file.
It should be the first documentation you read (after the
README file in theIt describes how to get the MUD compiled, configured, and
running; use of command-line options and system logs; and required daily
maintenance.
This i
Table of Contents
---------------------------------------------------------------------------
1. Compiling Circle
1.1. Compatibility Issues
1.2. How-To
2. Configuring Circle
3. Running Circle
3.1. Execution and 'autorun'
3.2. Command-Line Options
4. System Logs
4.1. Player Information
4.2. Usage Information
4.3. Errors
1. Compiling Circle
-------------------
1.1. Compatibility Issues
Ultrix 4.0 was used as CircleMUD's development platform up through v2.00;
starting with 2.10, Linux 0.99.11 was used instead. If you have Ultrix,
Linux, or another BSD-compatible system, and the gcc compiler, you should
be able to compile right out of the electronix box. If you don't have gcc,
try using cc -- on some systems such as AIX, the cc compiler is ANSI
compliant.
The author has personally compiled CircleMUD under the following systems:
Ultrix 4.0
IRIX 4.0.1, 4.0.4, 4.0.5
SunOS 4.1.1, 4.1.3
AIX 3.2
Linux 0.99.11
ConvexOS V10.2
Others have reported successfully compiling Circle under many other
systems; if you have a BSD-compatible system, chances of getting Circle
to compile easily are pretty good. Non-BSD systems will probably have
trouble with certain functions; getting Circle to compile for the first time
on such systems may be difficult and time-consuming. SVR4 compatibility is
on the horizon; many functions have already been converted to be SVR4
compatible, but the code has not yet been fully ported.
The Makefile has options to compile the MUD under Linux, AIX, and IRIX.
It also has an option for SVR4 but, as mentioned above, it does not
yet completely work. The unmodified Makefile should work with many other
including those listed above.
If you port Circle to another operating system and wish to share your work
with others, feel free to mail me your changes so that they can be included
in future releases of CircleMUD (if any). You'll be given credit, of
course. :)
1.2. How-To
The /src directory contains the source code for the main MUD; /src/utils
has the source for a dozen or so MUD maintenance utilities. The makefile
is in the /src directory; type 'make' while in that directory to compile
only the Circle server, type 'make utils' to compile all the utilities, or
type 'make all' to compile everything. You can also make an individual
utility by typing 'make x', where x is the name of the utility you want to
compile. Complete documentation of the utility programs can be found in
utils.doc.
The Makefile directs all compiled programs to the /bin directory. Although
not necessary, you may want to put Circle's /bin directory in your $PATH.
2. Configuring Circle
---------------------
Your first instinct will probably be to put the game up as fast as possible
to see if it works. That's fine, but there are some files you should be
aware of before you put the game up 'for real'. This is just a partial
list -- see 'files.doc' for a complete description of all the files in the
Circle distribution.
First, you'll probably want to take a look at 'config.c' -- it has dozens
of variables you can set to configure various aspects of CircleMUD.
The place where most of your day-to-day changes will be is in the lib/text
directory; that's where the help files, MOTD (Message Of The Day), imotd
(MOTD for immortals), and other text files are all kept.
In particular, you should make sure to put something in your 'policy' file --
it's better to have definite rules from the beginning than to have problems
later on when people try to bend you as far as they can. Also, you should
put tips for new immortals in the 'handbook' file (i.e., "Don't help any
mortals", "Don't kill mobiles", "Don't run through puddles", "Don't bring
glassware into the pool area", etc.)
The area hierarchy is lib/world. lib/world has 5 subdirectories -- wld,
mob, obj, shp, and zon, which is where the world, mobile, object, shop,
and zone files go, respectively. Each directory has a set of world
files in it with the correct extension (i.e., the obj subdir will have
a bunch of files ending with ".obj", such as 30.obj, 31.obj, etc.) plus
two special files -- 'index' and 'index.mini'. You can control which files
are loaded by Circle simply by changing the list of files listed in 'index'.
'index.mini' controls which (smaller) set of world files should be loaded
in the debugging mode (Mini-Mud Mode, explained below.)
3. Running Circle
-----------------
3.1. Execution and 'autorun'
Circle should always be run from circle's "root" directory, not the /bin
directory. You can run it manually by typing 'bin/circle' (useful for
testing and debugging). For running the game "for real", it's better
to use the 'autorun' shell script provided in Circle's root directory.
Autorun lets Circle run itself for long periods of time. It continuously
runs the game as well as removing old system logs, moving newer system logs
to the /log directory, and saving certain log entries to permanent files.
Autorun can be controlled by creating files with certain names. You can
use the 'touch' command to create a file, and, of course, the 'rm' command
to remove a file. If a file called '.fastboot' exists, the Circle will reboot
immediately if it crashes or is shut down instead of waiting 40 seconds as
it normally does. A file called '.killscript' will cause the script to
terminate itself; i.e., if you want to bring the game down. If you want
to temporarily prevent the MUD from rebooting, create a file called 'pause';
the script will go into a wait loop until 'pause' is removed.
Although you can create these files manually, the SHUTDOWN command from
within the MUD has several command-line options which will create these
files for you. See the SHUTDOWN help entry in wizhelp.doc for more
information.
It's not uncommon for CircleMUD to run for a week without crashing. The
game can be rebooted manually with the SHUTDOWN command, or automatically.
Once a day, at a time specified by the REBOOT_AT macro in modify.c, the
game checks for the existence of the file "reboot" in the selected data
directory. If the file exists, the game is rebooted (it terminates nicely,
with a nonzero return value). If the size of the file is nonzero, its contents
are processed by "sh" (with a system() call). If the processing returns
with a nonzero status, the file is renamed to "reboot.FAILED", and the
rebooting is called off. If it returns zero, the file is moved to
"reboot.SUCCEEDED", and the game is rebooted.
The first character to log in to the MUD (i.e., when the playerfile is
empty) will be made the maximum level. You should fix your stats using
the RESTORE command when you first create the character. To make more
God characters, use the ADVANCE command.
3.2. Command-Line Options
There are a number of command-line options which Circle will recognize.
You can use these when running Circle manually, or put them in the FLAGS
variable in your autorun script to use them all the time.
The syntax is:
circle [-m] [-q] [-r] [-s] [-d <path>] [<port #>]
-m: "Mini-Mud Mode". Mini-mud will be one of your most powerful debugging
tools; it causes Circle to boot with an abridged world, cutting the
boot time down to several seconds. It is useful for testing features
which are not world-related (i.e, new commands or spells).
CircleMUD uses split world files (in the lib/world heirarchy); each
directory (i.e., wld, obj, mob, shp, and zon) has a file called 'index'
which specifies which files should be loaded at boot-time. The file
'index.mini' specifies which parts of the world should be loaded with
the -m option.
-q: Quick boot - prevents checking of timed out object files. Every time
Circle boots, it checks every object file to see if it has timed out;
if so, it is deleted. This is done primarily to save disk space. If
time is more important to you than space, use the -q option. -q is
automatically activated when you use -m.
-r: Restrict game to new players. Allows you to decide at run-time whether
the game is open to new players or not; -r is equivalent to typing
"wizlock 1" (see wizhelp.doc for more information).
-s: Disable special routines. This option prevents special procedures from
being assigned. It is still supported but obsolete because Circle checks
to make sure each mob exists before assigning a spec_proc to it.
-d: Select data directory. This is useful if you want to keep one or more
sets of game data in addition to the standard set. For example, you may
wish to make a copy of the entire world in a separate directory, so that
you can test additions to the code or worldfile without subjecting the
players to unnecessary hazards. The default data directory is 'lib'.
Any coredumps (may they never happen to you!) will take place in the
selected directory.
port : Select the port on which the game is to wait for connections.
Default port is 4000; you can change the default in config.c and
the PORT= line of the autorun script.
4. System Logs
--------------
CircleMUD writes a wide variety of information to its log file (called
"syslog"). During Circle's boot sequence, the syslog keeps a record of
everything the MUD is doing to initialize itself; this can be useful to
determine what the problem is if the MUD dies while it is booting. Once
the game is up and running, the syslog contains information about players
(i.e., when they connect, disconnect, rent, unrent, quit, die, hit death
traps, etc.) as well as status information about the game itself. The
game-related information falls generally into 2 categories: usage
information and errors.
4.1. Player Information
The player information recorded by Circle's system logs will serve you
very well as your players start to make wild claims about strange bugs
resulting in them losing equipment or points. Many mudders prey on the
insecurities of a new mud administrator who is terrified that his or her
MUD is riddled with bugs and will do anything to satisfy grumpy players --
don't let yourself fall into that trap! CircleMUD is bound to contain
bugs, but most of the core systems have been well tested, so you should
take claims such as "I magically lost all my stuff!" with a grain of salt
and check your system logs.
If a player ever asks you for reimbursement of equipment, money, gold,
experience points, or whatever, your gut reaction should always be to
check the logs first.
As a sidebar, let me point out that the value of system logs is twofold:
1) they actually provide you with valuable information, and 2) they make
your players paranoid. When I first started mudding and I heard about
this mysterious "system log", it made me incredibly paranoid. Now that
I've done a good deal of MUD administration, I've seen the same paranoia
in _many_ other players.
That paranoia is a very good thing. The system logs become an abstract
and shapeless but omnipresent force on the MUD. Players hear about "the
System Log" and then get paranoid that everything they do is being
recorded, so they tend to behave, lest the evil System Log betray their
wrongdoings to the Gods.
For this reason, when you go to check your logs, it's a good idea to
say something like "Hold on -- let me go check the system logs, OK?"
because it reinforces the syslog's presence in the collective psyche
of your players.
Back to the point. When someone claims that they've been wronged by the
evil system, always check the logs. The logs give you power to say things
like "What do you mean your items disappeared in rent -- it says right here
in the logs 'Rasmussen has quit the game.' -- you didn't rent at all, you
just QUIT!"
The logs also record when a player's items are dumped due to insufficient
funds (remember -- rent is calculated per day on a PER-SECOND basis! If you
rent at the rate of 100 coins per day and come back 36 hours later, you'll
be charged 150 coins!). Plus, when someone rents, it records in the logs how
much rent cost per day and how much the player had, to diffuse disputes such
as "But I had enough money!!"
In short: the system logs are your friends. Love them.
The autorun script saves 6 levels of raw system logs. In addition, it
greps the logs for certain pieces of extra-juicy information to save
indefinitely.
4.2. Usage Information
Every 5 minutes, the game counts how many people are playing and records
that information in the system log. Optionally, if you #define RUSAGE
in comm.c, it will also record system resource information such as CPU time
and memory used. The usage information currently logged by Circle is,
as you can see, somewhat sparse; local MUD admins are encouraged to add
to this code as is appropriate for their particular site.
Usage information isn't critical, but it is interesting to look at the
usage patterns to determine when your peak playing hours are. If you're
good at using 'cut' and other Unix utilities, you can even dazzle your
friends by graphing your MUD's system usage.
[ Note: friends not included with the CircleMUD distribution. ]
4.3. Errors
Just as your first gut instinct should be to look at the logs if a player
starts begging you for something, your first gut instinct in the event of
a crash or unexpected shutdown should also be to look at the system logs.
A Unix utility called 'tail' is used to look at the last few lines of a
text file; it's very useful for looking at the last entries in the system
log to see the last thing that happened before the shutdown. Often, Circle
will report an error in the logs just before it crashes. This method is
particularly useful if the MUD crashes during its boot sequence, because
the logging during boot is intensive.
If Circle shuts down unexpectedly and there is no core dump in the /lib
directory, the game probably detected an internal error and killed itself.
Such shutdowns are always preceeded by entries in the system log describing
the error.
If there's no error message at the end of the log, then there probably
IS a core dump, so you can use 'dbx', 'gdb', etc. to examine the core
dump and determine the reason for the crash. The file 'hacker.doc',
generously provided by Furey of MERC Industries, offers useful insight
into the art and science of debugging -- you'd be well advised to give it
a look-see.
Circle sometimes encouters a serious but non-fatal error; in this case,
the error will be written to the system log with the prefix SYSERR, but
the MUD will not shut itself down. You should always be aware of any
SYSERRs which occur -- they are often useful for forseeing imminent danger
or averting problems before they become critical. If a SYSERR does
occur, try to determine if a change you've made recently has caused it.
Ignoring SYSERRs is like ignoring compiler warnings: you can be tempted
to ignore them because the game keeps going even if they exist, but you
can easily get yourself into trouble by not listening. The autorun script
saves all SYSERRs to the file log/errors.
Day-To-Day MUD Administration
-----------------------------
Okay, so now you have your wonderful CircleMUD up and running and all is
right with the world. Right?
Well, technically, yes. Circle requires very little day-to-day attention
in order to keep the progam itself running smoothly. But the MUD itself
is just a series of instructions running on a computer, processing data.
Never lose sight of the fact that there will be dozens, hundreds, or maybe
even thousands of people connecting to your MUD -- and they are NOT
programs. They're people!
What I'm getting at is this: from the technical side, there are relatively
few things you have to do to keep the game running. But you can't just plop
a MUD on the Internet and then ignore it! Spend time on your MUD. Try to
keep up with the boards, and make an effort to respond to the complaints,
ideas, and suggestions posted there. Take a look at the 'bug', 'typo', and
'idea' files from time to time -- and maybe even respond to some of the ideas
using Mudmail. Try to respond to Mudmail you receive from players in a
timely manner. Make sure that your 'news', 'policy' and other text files
are up-to-date and suit the political climate on your MUD.
If you can't or just don't want to deal with the player politics, make sure
sure that you choose someone who can and will, and make them responsible for
dealing with it. If no one does it, your MUD will stagnate and die.
Maintaining CircleMUD
---------------------
CircleMUD requires little technical maintenance. You should look at the
log/errors file regularly to make sure there are no recurring problems.
Also, you probably will want to 'purge' the playerfile on a regular basis
(i.e., remove "deadweight" characters). You can decide how often to purge
the playerfile -- every day if disk space is tight, or every month if it
isn't. The purgeplay utility program (included) removes deadweight players.
You should run the 'purgeobjs' script (in the lib/plrobjs) directory after
you purge the playerfile -- it removes the object files of players who no
longer exist in the playerfile.
The 'automaint' script in the main circle directory will automatically purge
the playerfile and player objects for you. DO NOT RUN THIS SCRIPT WHILE
THE MUD IS RUNNING! Doing so will make your life (more) difficult.
Good luck with your MUD!
-- Jeremy Elson
jelson@cs.jhu.edu

243
old-codebase/doc/OLD-DOCS/shop.doc Normal file
View File

@@ -0,0 +1,243 @@
/* ************************************************************************
* Copyright (C) 1990, 1991 - see 'license.doc' for complete information. *
************************************************************************* */
NEW FORMAT:
CircleMUD v3.0 now has a new shop file format. Since the old format
is still compatible, I've kept the old documetation at the end of
this file. If you'd like to convert shop files in the old format to that
of the new format, compile and run the utility shopconv. When writing new
files, you need to tell CircleMUD that the shopfile is in the new format
by including the following line BEFORE any shops in the file:
CircleMUD v3.0 Shop File~
The rest of the file is formatted as follows:
#<num>~
Shop Number (Used only for display purposes)
<num 1>
<num 2>
<num 3>
.
.
.
<num n>
-1
These numbers refer to the objects the shop produces. The numbers are
virtual numbers. The list MUST end with a -1.
<Profit when selling>
The object value is multiplied by this value when sold. This is a
floating point value. Must be >= 1.0
<Profit when buying>
The object value is multiplied by this value when bought. This is a
floating point value. Must be <= 1.0
<type 1> [namelist 1]
<type 2> [namelist 2]
<type 3> [namelist 3]
.
.
.
<type n> [namelist n]
-1
These lines contain the types of items that the shop will buy. The first
argument, called "type" is the type of item (see dbsup.doc). Numerical,
or english forms are valid (5 or WEAPON, 9 or ARMOR, etc) In addition,
you can provide optional keywords to give specific keywords that must
be present on the item. For further details on these expressions, see the
notes following the new file format. This list must be terminated by a -1.
<Message When Item to buy is non existing>~
<Message When item trying to sell is non existing>~
<Message When shop does not buy offered item>~
<Message when shop can't afford item>~
<Message when player can't afford item>~
<Message when buying an item>~
Price is %d
<Message when selling an item>~
Price is %d
<Temper>
When player can't afford an item, the shopkeeper tells them they
can't afford the item and then:
0 - The shopkeeper pukes on the player.
1 - The shopkeeper smokes his joint.
other - No action besides message above.
<Bitvector>
Allows you to set certain values for the shop.
WILL_START_FIGHT 1 /* Players can attack shopkeeper */
WILL_BANK_MONEY 2 /* Shopkeeper puts money > 15000
into the bank */
A brief note: Shopkeepers should be hard (if even possible) to kill.
The benefits players can receive from killing them is enough to unbalance
most non monty-haul campaigns.
<Shop Keeper Mobile Number>
Virtual number of the shopkeeper.
<With Who>
Designate certain alignments or classes that the shop will not
trade with. To determine this value, choose all elements on
the list below that you do not want sold to, and add their values.
TRADE_NOGOOD 1
TRADE_NOEVIL 2
TRADE_NONEUTRAL 4
TRADE_NOMAGIC_USER 8
TRADE_NOCLERIC 16
TRADE_NOTHIEF 32
TRADE_NOWARRIOR 64
<Room 1>
<Room 2>
<Room 3>
.
.
.
<Room n>
-1
The virtual numbers the mobile must be in for the shop to be effective.
(So trans'ed shopkeepers can't sell in the desert). The list must be
terminated by a -1.
<Time when open start 1>
<Time when open end 1>
The hours between which the shop is open.
<Time when open start 2>
<Time when open end 2>
The hours between which the shop is open.
ITEM NAME LISTS:
Name lists are formed by boolean expressions. The following operators
are available:
',^ = Not *, & = And +, | = Or
The precedence is Parenthesis, Not, And, Or. For example, the following line:
WEAPON [sword & long|short | warhammer | ^golden & bow] & magic
This shop will buy the following items of type WEAPON:
1) sword long magic
2) short magic (the first & is done before the first | )
3) warhammer magic
4) ^golden bow magic
Note that the ^ in front of golden affects ONLY golden, and nothing else
in the listing. Basically, the above expression could be written in
english as:
[(sword and long) or short or warhammer or (not golden and bow)] and magic
If I wanted the shop to only buy "short magic" only if they were also swords,
I would have to change the expression to:
WEAPON [sword & (long|short) | warhammer | ^golden & bow] & magic
^-Changes--^
You can also include object extra flags (listed in dbsup.doc). The previous
example used "magic" as a keyword that had to be on the object. If we wanted
to make it so that the MAGIC flag had to be set on the item, we would change
"magic" to "MAGIC." Similar changes could be made to add other flags such as
"HUM" or "GLOW." It should be noted that these expressions are case sensitive
and that all keywords should appear in lower-case, while the flag names should
be in all caps.
OLD FORMAT:
Default DIKU shop files have the following format:
#<xx>~
Shop Number (Used only for display purposes)
<num1>
<num2>
<num3>
<num4>
<num5>
These numbers refer to the objects the shop produces.
The numbers are virtual numbers.
<Profit when selling>
The object value is multiplied by this value when sold. This is a
floating point value. Must be >= 1.0
<Profit when buying>
The object value is multiplied by this value when bought. This is a
floating point value. Must be <= 1.0
<num1>
<num2>
<num3>
<num4>
<num5>
These five numbers are the item-types traded with by the shop.
See dbsup.doc.
<Message When Item to buy is non existing>~
<Message When item trying to sell is non existing>~
<Message When wrong item-type sold>~
<Message when shop can't afford item>~
<Message when player can't afford item>~
<Message when buying an item>~
Price is %d
<Message when selling an item>~
Price is %d
<Temper>
When player can't afford an item, the shopkeeper tells them they
can't afford the item and then:
0 - The shopkeeper pukes on the player.
1 - The shopkeeper smokes his joint.
other - No action besides message above.
<Bitvector>
Allows you to set certain values for the shop:
WILL_START_FIGHT 1 /* Players can attack shopkeeper */
WILL_BANK_MONEY 2 /* Shopkeeper puts money > 15000
into the bank */
A brief note: Shopkeepers should be hard (if even possible) to kill.
The benefits players can receive from killing them is enough to unbalance
most non monty-haul campaigns.
<Shop Keeper Mobile Number>
Virtual number of the shopkeeper.
<With Who>
Designate certain alignments or classes that the shop will not
trade with. To determine this value, choose all elements on
the list below that you do not want sold to, and add their values.
TRADE_NOGOOD 1
TRADE_NOEVIL 2
TRADE_NONEUTRAL 4
TRADE_NOMAGIC_USER 8
TRADE_NOCLERIC 16
TRADE_NOTHIEF 32
TRADE_NOWARRIOR 64
<Shop Room Number>
The virtual number the mobile must be in for the shop to be effective.
(So trans'ed shopkeepers can't sell in the desert).
<Time when open start 1>
<Time when open end 1>
The hours between which the shop is open.
<Time when open start 2>
<Time when open end 2>
The hours between which the shop is open.

90
old-codebase/doc/OLD-DOCS/socials.doc Normal file
View File

@@ -0,0 +1,90 @@
/* ************************************************************************
* Copyright (C) 1990, 1991 - see 'license.doc' for complete information. *
************************************************************************* */
HANDLING 'SOCIALS' IN CIRCLEMUD
A general system exists to handle the 'social' commands -- those which
generally have no game-related purpose other than to convey emotions
between players. Socials are also useful for creating advanced DikuMUD
adventures and quests through the use of speical procedures; for example,
you could add a 'detonate' social which, within your quest, is handled by
a special procedure to cause something to explode.
Socials are all handled through the generalized command do_action. The
text file lib/text/socials contains information on the game's socials.
New socials can be added by 1) adding the name and level of the social
to the master command list in interpreter.c (giving do_action as the
function pointer), and 2) adding information for the new social to the
lib/text/socials file.
In Circle 3.0, socials in the file are specified by name (instead of by
command number, as was true of the original Diku and versions of Circle
before 3.0.). In the standard Circle distribution, the socials appear
in alphabetical order in the file, but they can appear in any order and
can be rearranged if necessary.
The file is formatted as follows:
--------------------------------------------
<command name> <hide-flag> <minimum position of victim>
<messg to character if no argument>
<messg to others if no argument>
<messg to char if victim found> <---If this field is empty,
<messg to others if victim found> <-
<messg to victim> | then these fields must be
<messg to char if victim not found> | skipped, and the action will
<messg to char if vict is char> | ignore arguments.
<messg to others if vict is char> <-
<command name> <hide-flag> <minimum position of victim>
.
.
.
.
.
$~
-------------------------------------------------
Each social must contain either 1) only the first two messages (if the social
ignores arguments), or 2) all eight messages (if the social takes an argument).
Each message must be contained in one line.
The command-name indicates which social is being specified. The hide-flag
can be either 0 or 1; if 1, the social is hidden from OTHERS if they cannot
see the character performing the social. The action is not hidden from the
VICTIM, even if s/he cannot see the character performing the social, although
in such cases the character's name will, of course, be replaced with "someone".
Where it makes sense to do so, text fields may be left empty. This is done by
putting a '#' in the first column on the line. Doing so is legal in the
following fields:
a: messg to others if no arg
b: messg to others if victim found
c: messg to others if vict is char
Note again that if the field _messg to char if victim found_ is empty, then
the following fields must be omitted entirely (not even the '~'), and the
action will ignore any arguments supplied.
The procedure sends the text strings through act(), and they may contain
control codes (see the documentation for the act() function for details.)
Note that not all of act()'s control codes may be used; for example, codes
which refer to objects such as $p.
For the sake of efficiency, no tests or sanity checks are made on the
consistency or logic of the act() codes found in the social messages.
Hence, grave disorder may result if, say, the code '$N' occurs in a text
field that doesn't refer to a victim; like _messg to others if no arg_.
In previous versions of Circle, such grave disorder often manifested itself
in the form of crashes. However, the act() function itself in Circle 3.0
and above does sanity checks to make sure it's not dereferencing null
pointers, hopefully with the result of avoiding crashes. Nevertheless,
great care should be taken in making sure that the $ codes of socials are
used consistently and correctly.

144
old-codebase/doc/OLD-DOCS/spell_info.doc Normal file
View File

@@ -0,0 +1,144 @@
/* ************************************************************************
* Copyright (C) 1990, 1991 - see 'license.doc' for complete information. *
************************************************************************* */
OFFENSIVE SPELL AVERAGE DAMAGE CHARTS
Upon learning a new spell, the manauser will always be able to cast
two of these spells. For each level, the manauser will be abel to cast
one additional spell of the type learned. The maximum abel to learn is
different between each spell, but for most offensive spells it is 7.
The number of spells that can be cast assume that everybody has got
100 mana points.
General Idea:
A M.U. Should be abel to kill a victim 3 levels below himself, by
using all his MANA points for offensive spells. This include
saving_throw calculations.
Saving throw has effect (level of victim = L, damage of spell = D)
Actual_Average_Damage = (L/20*(D/2))+(((20-L)/20)*D)
where L in [1..18] (Means saving never better than 2)
If you want to know how much dam, say E, a L level victim,
get from D dam, then:
Effective_Dam (E) = D/(1-(L/40))
---------------------------------------------------------------------------
TABLE:
LVL is level of victim.
HP is hit_points.
ERM is spell damage to effectively remove HPR
SAV is assumed saving throw
A.DIF. is Aprroximate adjusted difference.
LVL 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
SAV 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 2
HP 22 35 47 60 72 85 97 110 122 135 147 160 172 185 197 210 222 235 247 260
ERM 22 37 51 67 82 100 118 138 157 180 203 229 255 285 315 350 386 427 470 495
A.DIF 15 15 16 16 18 18 20 20 23 23 26 26 30 30 35 35 41 43 -
---------------------------------------------------------------------------
Table of WHEN a MU can kill a Level X opponent by using 100 MANA points only.
MU Level 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Opponent 0 0 0 1 2 3 5 6 7 8 9 10 12 13 14 15 16 17 18 20
---------------------------------------------------------------------------
Magic Users New Damage Table. The damage listed by each spell shows how
much damage can be given by using 100 mana points at the apropriate level.
To make it worth-while to learn new damaging spells, a spell which is
"overlapped" by a new spell will give less damage than the exact calculated
average.
Spell 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Mag Mis 6 10 16 18 32 45 " " " " " " " " " " " " " "
Chill* 16 22 34 47 76 93 " " " " " " " " " " " "
Burn Han 37 51 79 96 112 132 " " " " " " " " " "
Shock 82 100 115 135 151 174 " " " " " " " "
Lightb 118 138 154 177 225 251 " " " " " "
Spray 157 180 229 255 280 310 " " " "
Energy 11 17 22 28 33 39 39 39(11)
Fireb 285 315 350 386 427 495
*Chill Touch may reduce STR by -1 when failing saving throw.
Clerics
Spell 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Earthq *
Dispel Evil *
Call Lightn X
Harm X
Dispel Evil is special (0..100) (7 Max)
Earthquake is special (7 Max)
Call Lightning is special (7 Max)
Harm is fairly special (3 Max)
*** NEW *** Spell listing By Level and Class
LEVEL Magic User Cleric
(1) Magic Missile (1) Armor
(1) Ventriloquate (1) Cure Light
(2) Detect Magic (2) Create Water
(2) Detect Invisible (2) Detect Poison
(3) Chill Touch (3) Create Food
(3) - (3) Detect Magic
(4) Invisibility (4) Cure Blind
(4) - (4) Detect Evil
(5) Burning Hands (5) Bless
(5) Armor (5) Detect Invisible
(6) Locate Object (6) Blindness
(6) - (6) Protection from Evil
(7) Shocking Grasp (7) Earthquake
(7) Strength (7) Sense Life
(8) Blindness (8) Summon
(8) Teleport with Error (8) Poison
(9) Lightning Bolt (9) Cure Critic
(9) - (9) Remove Poison
(10) Control Weather (10) Locate Object
(10) - (10) Dispel Evil
(11) Color Spray (11) Word of Recall
(11) - (11) -
(12) Enchant Weapon (12) Call Lightning
(12) Curse (12) Remove Curse
(13) Energy Drain (13) Control Weather
(13) - (13) Sanctuary
(14) Sleep (14) Heal
(14) Charm Person (14) -
(15) Clone (15) Harm
(15) Fireball (15) -

85
old-codebase/doc/OLD-DOCS/spells.doc Normal file
View File

@@ -0,0 +1,85 @@
/* ************************************************************************
* Copyright (C) 1990, 1991 - see 'license.doc' for complete information. *
************************************************************************* */
OUT OF DATE I THINK (MS)
Description of affected_type structure:
struct affected_type
{
byte type; /* The type of spell that caused this */
byte duration; /* For how long its effects will last */
byte modifier; /* This is added to apropriate ability */
byte location; /* Tells which ability to change(APPLY_XXX)*/
long bitvector; /* Tells which bits to set (AFF_XXX) */
struct affected_type *next;
};
The type is set to the constants defined in spells.h. These are any of
SPELL_XXX, ei. SPELL_ARMOR.
Duration will be decreased at each time update.
Location is determined by the APPLY_XXX, ei. APPLY_STR to change strength.
Modifier will be added to the apropriate APPLY_XXX
Bitvector will set bits in the char_data->char_special_data.affected_by
---------------------------------
Description of handler.c routines:
void affect_location_apply ( struct char_data *ch,
struct affected_type *af, int type);
/* This procedure will (depending on type) Apply or Remove a characters */
/* special bonus to abilities, which have been gained by spells */
When Type is 1, Modifier will be added to an ability, and Bitvector will
set bits in the "char_data->char_special_data.affected_by" bitvector. When
Type == 0, Modifier is subtracted, and bits are removed.
void affect_to_char( struct char_data *ch, struct affected_type *af )
This procedure allocates new memory for an affected_type structure, and
inserts a copy of "*af" in the char_data->affected linked list. After
insertion, the "affect_location_apply" is called, with type == 1.
void affect_remove( struct char_data *ch, struct affected_type *af )
This procedure is the reverse of affect_to_char. Upon calling "af" MUST
point to the structure(element) in the linked list that is to be removed.
If not, the program will do an "exit()". Memory used is released, and
"affect_location_apply" is called, with type == 0.
BEWARE! Some spells may have several structures, since they must change
more than one attribute! Calling affect_from_char does not mean that you
have removed every occurence of a certain spell. But you can be sure that
bits are masked out! Use affect_from_char below.
---------------------------------
void affect_from_char( struct char_data *ch, byte skill )
This fixes the warning above, by calling affect_remove with every
structure that has same spelltype set as skill.
bool affected_by_spell( struct char_data *ch, byte skill )
This procedure will check if a character is affected by a spell (the
SPELL_XXX constants are used). Returns FALSE if not, otherwise TRUE.

12
old-codebase/doc/OLD-DOCS/time.doc Normal file
View File

@@ -0,0 +1,12 @@
/* ************************************************************************
* Copyright (C) 1990, 1991 - see 'license.doc' for complete information. *
************************************************************************* */
Time of DikuMud
DikuMud has 7 days per week
35 days per month
17 months per year
DikuMud time is 48 times faster than the real time. One hour of game
time passes every 75 seconds of real time.

219
old-codebase/doc/OLD-DOCS/utils.doc Normal file
View File

@@ -0,0 +1,219 @@
/**************************************************************************
* Copyright (C) 1993 - see 'license.doc' for complete information. *
* Jeremy Elson; 7/12/93 *
**************************************************************************/
CIRCLEMUD UTILITIES
"utils.doc"
There are currently 12 utilities and several shell scripts which come with
CircleMUD to help you run and maintain it. This file documents them.
Brief Synopsis
--------------
AUTOWIZ Automatically generate a wizlist and an immlist from the
playerfile.
DELOBJS Delete the object files (i.e. crash-save, rent, cryo-rent,
etc.) of players who no longer exist in the playerfile.
HASMAIL Return an exit status of 0 or 1, depending on if the
recipient specified has MUDmail waiting or not.
LISTRENT Show the contents of one of more object files.
MAILINDEX Generate a list of all mail contained in a mail file.
MUDPASSWD Change the password of a MUD character in a playerfile.
PURGEPLAY Create a new playerfile with deadweight characters removed.
READMAIL Print mail contained in a mail file.
SHOWPLAY List players contained in a playerfile.
SIGN Present a sign on a port (i.e. "MUD will be down today").
SPLIT Split a large file into several smaller files.
SYNTAX_CHECK Check the syntax of a set of world files.
Detailed Documentation
----------------------
AUTOWIZ
Autowiz is not really meant to be run by a person; the MUD automatically
executes it every time someone reaches immortality or is promoted to an
immort or higher level.
It must be compiled and in the circle/bin directory in order for the
automatic wizlist system to work, of course.
DELOBJS
delobjs <playerfile> <file1> <file2> <filen>
Delobjs generates an index of all players in the playerfile, then checks
each file listed on the command line to make sure that the object file
has a corresponding player in the player index. If the player does not
exist, the object file is deleted.
Although this program can be run manually, it is much easier simply to
use the "purgeobjs" script in the lib/plrobjs directory. That script
will automatically run delobjs on every file in each of the 5 object
directory, and save a list of the files deleted to a file called DELETED.
LISTRENT
listrent <file1> <file2> ... <filen>
Listrent will simply list the contents of an object save file. You can
list as many files as you like on the command line; the contents of each
file will be listed.
Included in the lib/plrobjs directory is a script called 'searchfor', which
you can use to see who in the game has certain items. For example, if you
wanted to see who had object #3001 rented, you would switch into the
lib/plrobjs directory and type "searchfor 3001".
HASMAIL
hasmail <mail-file> <recipient-name>
Hasmail has no output -- it just returns a 0 or 1, depending on if you
have mail waiting or not. It's useful for putting something like this
in your .login (assuming you use csh):
set NAME = ras
if ( { hasmail ~/circle/lib/misc/plrmail $NAME } ) then
echo "You have mud-mail waiting."
endif
MAILINDEX and READMAIL
CircleMUD's mail files are binary files -- they can't be read with 'cat',
'more', etc. The MAILINDEX and READMAIL commands allow you to see the
contents of a mail file.
Obviously, there are a lot of serious privacy issues which go along with
programs like this. For exactly that reason, I didn't even write these
utilities for months after I wrote the mail system. I eventually broke
down and wrote them because there is no way to save Mudmail after you've
read it from within the MUD, but READMAIL allows you to do just that --
read your mail without deleting it.
As a footnote, the MUDmail system was intentionally designed so that
one is not able to save mail after having read it. I have a tendency
to save all of my (real) email, as do many other people, and I didn't
want hundreds of mud players to start saving all their MUDmail at the
expense of my disk.
Now that I've loaded these utilities with excessive moral baggage, I'll
describe how they are used.
mailindex <mailfile>
readmail <mailfile> <recipient-name>
MAILINDEX will show you a list of all letters currently in the mail file,
in the following format:
Recipient 1
Sender 1
[...]
Sender n
Recipient 2
Sender 1
[...]
Sender n
[...]
Recipient m
Sender 1
[...]
Sender n
READMAIL will show you all mail addressed to the recipient you specify.
MUDPASSWD
mudpasswd <playerfile> <character> <new-password>
MUDPASSWD is used to change the password of a character in the playerfile.
It can be done while the game is running, but "set passwd" from within the
game is probably safer.
MUDPASSWD is useful for people who forget their passwords, etc. SET PASSWD
does the same thing.
PURGEPLAY
purgeplay <playerfile-name>
PURGEPLAY will read all the characters in the playerfile you specify, and
output a new playerfile called 'players.new', with "deadweight" characters
removed. The original playerfile will not be changed. Characters meeting
one or more of the following criteria will not be included in players.new:
- Buggy characters (i.e., non-alphabetic name or invalid level)
- Characters with a DELETED flag
- Level 0 characters (connected but never entered game)
- If a character is NOT cryo-rented, the following timeouts apply:
- Level 1 characters who have not played in 4 days
- Level 2-4 characters who have not played in 7 days
- Level 5-10 characters who have not played in 30 days
- Level 11-30 characters who have not played in 60 days
- Level 31 characters who have not played in 90 days
- If a character IS cryo-rented, the timout for levels 1-31 is 90 days.
- A CHARACTER WITH A NODELETE FLAG WILL NOT BE REMOVED, even if
the character meets one or more of the above criteria.
PURGEPLAY will generate a report of all characters which were not included
in players.new and the reason for their omission.
SIGN
sign <filename | '-'> <port #>
SIGN is used for putting a message on a port, i.e., "BazookaMUD is currently
down for repairs." The second argument can either be the name of a text
file or a dash; if it is a dash, SIGN will prompt you for the sign text.
Port # is, of course, the port on which you'd like the sign to be displayed.
SPLIT
Split reads text files from standard input and writes a series of files
to disk as output. Its intended usage it to take a large diku world
file and split it into several smaller, more managable files. You'll
probably only need to use it if you're porting a large world file from
some other MUD to Circle.
To use SPLIT, insert a line containing only "=filename" at each point
in the original file where you'd like SPLIT to start writing to a
new file. When SPLIT reaches a line starting with '=', it will begin
writing all subsequent lines to a file called 'filename' until the next
'=' or EOF is encountered. #99999 is appended to the end of each file.
A file called 'index' is created, containing a list of all files which
were created (see running.doc for more information about index files.)
SYNTAX_CHECK
syntax_check <zone number>
Syntax_check is a utility for checking that world files are formatted
correctly. It should be run from the main lib/world directory. If you
type 'syntax_check 30', it will check the files wld/30.wld, obj/30.obj,
mob/30.mob, and zon/30.zon.

312
old-codebase/doc/OLD-DOCS/values.doc Normal file
View File

@@ -0,0 +1,312 @@
/* ************************************************************************
* Copyright (C) 1990, 1991 - see 'license.doc' for complete information. *
************************************************************************* */
ITEM VALUE DOCUMENTATION
"values.doc"
These values are used, as illustrated below, with the different
item types. The various item types are shown in dbsup.doc.
ITEM_LIGHT (1)
Value[0]: Not Used
Value[1]: Not Used
Value[2]: Number of hours the light can be used for. Zero hours means that
the light has gone out. A negative number will create an eternal
light source.
Value[3]: Not Used
ITEM_SCROLL (2)
Value[0]: Level of the spell on the scroll.
Value[1]: Which spell (see list somewhere around the end of file)
Value[2]: Which spell
Value[3]: Which spell
The values(1-3) are three (or less) different spells, mixed 'on' the scroll.
Unused spells should be set to -1.
ITEM_WAND (3)
Value[0]: Level of spell in wand.
Value[1]: Max Charges (1..X)
Value[2]: Charges Left
Value[3]: Which spell in wand (see list somewhere around the end of file)
ITEM_STAFF (4)
Value[0]: Level of spell in staff.
Value[1]: Max Charges (1..X)
Value[2]: Charges Left
Value[3]: Which spell in staff (see list somewhere around the end of file)
ITEM_WEAPON (5)
Value[0]: Not Used
Value[1]: Number of dice to roll for damage
Value[2]: Size of dice to roll for damage
Value[3]: The weapon type. Type is one of:
NUMBER CATEGORY Message type
2 : Slash "whip/whips"
3 : Slash "slash/slashes"
6 : Bludgeon "crush/crushes"
7 : Bludgeon "pound/pounds"
11 : Pierce "pierce/pierces"
New types can be added as needed.
ITEM_FIREWEAPON (6)
Value[0]: -
Value[1]: -
Value[2]: -
Value[3]: -
ITEM_MISSILE (7)
Value[0]: -
Value[1]: -
Value[2]: -
Value[3]: -
ITEM_TREASURE (8)
Value[0]: -
Value[1]: -
Value[2]: -
Value[3]: -
ITEM_ARMOR (9)
Value[0]: The effective AC. >0 enhances the armour class. <0 reduces the
the armour class (cursed armour for example).
Value[1]: -
Value[2]: -
Value[3]: -
ITEM_POTION (10)
Value[0]: Level of the spell in the potion.
Value[1]: Which spell (Listed elsewhere in this file)
Value[2]: Which spell
Value[3]: Which spell
The values(1-3) are three (or less) different spells, mixed in the potion.
Unused spells should be set to -1.
Eg.
Value 0 : 30 (Level)
Value 1 : 27 (Harm)
Value 2 : 17 (Curse)
Value 3 : 4 (Blindness)
(* Don't drink this - It's bad for your health! *)
ITEM_WORN (11)
Value[0]: -
Value[1]: -
Value[2]: -
Value[3]: -
ITEM_OTHER (12)
Value[0]: -
Value[1]: -
Value[2]: -
Value[3]: -
ITEM_TRASH (13)
Value[0]: -
Value[1]: -
Value[2]: -
Value[3]: -
ITEM_TRAP (14)
Value[0]: -
Value[1]: -
Value[2]: -
Value[3]: -
ITEM_CONTAINER (15)
Value[0]: Maximum weight the container can contain.
Value[1]: Container flags:
CLOSEABLE 1
PICKPROOF 2
CLOSED 4
LOCKED 8
Value[2]: The item-number of the object which can open the object. -1 means
no lockability.
Value[3]: Internal use for Corpses that must "rot".
ITEM_NOTE (16)
Value[0]: Tounge (language of writing). Not yet used.
Value[1]: -
Value[2]: -
Value[3]: -
ITEM_DRINKCON (17)
Value[0]: Maximum drink-units the drink-container can contain.
Value[1]: Number of drink-units that are left in the container.
Value[2]: The type of liquid in the drink-container, one of:
Type nr. Effect
Drunkness Fullness Thirst
LIQ_WATER 0 0 1 10
LIQ_BEER 1 3 2 5
LIQ_WINE 2 5 2 5
LIQ_ALE 3 2 2 5
LIQ_DARKALE 4 1 2 5
LIQ_WHISKY 5 6 1 4
LIQ_LEMONADE 6 0 1 8
LIQ_FIREBRT 7 10 0 0
LIQ_LOCALSPC 8 3 3 3
LIQ_SLIME 9 0 4 -8
LIQ_MILK 10 0 3 6
LIQ_TEA 11 0 1 6
LIQ_COFFE 12 0 1 6
LIQ_BLOOD 13 0 2 -1
LIQ_SALTWATER 14 0 1 -2
LIQ_CLEARWATER 15 0 0 13
The above values for drunkness/fullness/thirst are used per
four "units" drunk. The values are expressed in HOURS!
Example:
Dragon empties a bottle (say 7 units) of saltwater.
His Drunkness is not changed ((7/4)*0)
His Fullness increases by ((7/4)*1) hours
His Thirst increases by ((7/4)*-2) hours, thus making
him More thirsty.
The hours above are numbers between 0 and 24. 24 hours is
maximum for drunkness/fullness/thirst. When hours are zero
for any drunkness/fullness/thirst the person will be
sober, hungry, or thirsty respectively.
Value[3]: if this value is non-zero, then the drink is poisoned.
ITEM_KEY (18)
Value[0]: The key-type. This value must match the lock-type the door
that the key can open.
Value[1]: -
Value[2]: -
Value[3]: -
ITEM_FOOD (19)
Value[0]: The number of hours, that this food will fill the stomach
Value[1]: -
Value[2]: -
Value[3]: If this value is non-zero, the food is poisoned.
ITEM_MONEY (20)
Value[0]: The number of gold coins "in the pile of coins".
Value[1]: -
Value[2]: -
Value[3]: -
ITEM_PEN (21)
Value[0]: -
Value[1]: -
Value[2]: -
Value[3]: -
ITEM_BOAT (22)
Value[0]: -
Value[1]: -
Value[2]: -
Value[3]: -
ITEM_FOUNTAIN (23)
Value[0]: Maximum drink-units the drink-container can contain.
Value[1]: Number of drink-units that are left in the container.
Value[2]: The type of liquid in the drink-container; definitions
are the same as for ITEM_DRINKCON.
Value[3]: Drink is posioned if non-zero.
-------------------------------------------------------------------------
IMPORTANT NOTICE!!
Since the level versus average damage calculations are performed as shown
in "spell_info.doc" all the offensive spells are individually much stronger
than higher level spells. For example:
1 fireball of level 15 gives more damage than one of level 16 which give
more damage than level 17 which give more damage than level 18 which
give more.... etc.
Thus please make all offensive potions/scrolls/etc. as the basic level
they are designed for. You can see the level below. You can see the spells
average damage, by looking at the spell versus the level of the spell,
divided by the number of spells learned at that particular level. Example:
Level 9 Lightning bolt give (102/2) average damage. Divided by 2, because
this is the level at which it is first learned (You can almost
always cast two spells are first learned level). At level 10 it
gives (120/3) average damage.
Looking at the table in "spell_info.doc", you should know that each spell
is designed so that it will kill a victim three levels below the mana user,
if the manauser ONLY cast his spell....
-------------------------------------------------------------------------
The Y/N rows below indicate which potions/scrolls/wands/staffs that are
possible to make. The MIN_LEV is the Minimum Level DEMANDED by the item
you are making. The game will crash if making level less than demanded.
-------------------------------------------------------------------------
POTION SCROLL WAND STAFF MIN_LEV
TYPE_UNDEFINED -1 Y Y Y Y -
SPELL_RESERVED_DBC 0 N N N N -
SPELL_ARMOR 1 Y Y Y N >0
SPELL_TELEPORT 2 Y Y Y Y >0
SPELL_BLESS 3 Y Y Y N ...
SPELL_BLINDNESS 4 Y Y Y Y
SPELL_BURNING_HANDS 5 N N N N == 5
SPELL_CALL_LIGHTNING 6 Y Y N Y >=12
SPELL_CHARM_PERSON 7 N Y N Y
SPELL_CHILL_TOUCH 8 N N N N == 3
SPELL_CLONE 9 Y Y Y N
SPELL_COLOUR_SPRAY 10 N Y Y N ==11
SPELL_CONTROL_WEATHER 11 N N N N
SPELL_CREATE_FOOD 12 N Y N N
SPELL_CREATE_WATER 13 N N N N
SPELL_CURE_BLIND 14 Y N N Y
SPELL_CURE_CRITIC 15 Y N N Y
SPELL_CURE_LIGHT 16 Y N N Y
SPELL_CURSE 17 Y Y N Y
SPELL_DETECT_EVIL 18 Y N N Y
SPELL_DETECT_INVISIBLE 19 Y N N Y
SPELL_DETECT_MAGIC 20 Y N N Y
SPELL_DETECT_POISON 21 Y Y N N
SPELL_DISPEL_EVIL 22 Y Y Y Y == 10
SPELL_EARTHQUAKE 23 N Y N Y == 7
SPELL_ENCHANT_WEAPON 24 N Y N N
SPELL_ENERGY_DRAIN 25 Y Y Y Y == 13
SPELL_FIREBALL 26 N Y Y N == 15
SPELL_HARM 27 Y N N Y == 15
SPELL_HEAL 28 Y N N Y
SPELL_INVISIBLE 29 Y Y Y Y
SPELL_LIGHTNING_BOLT 30 N Y Y N == 9
SPELL_LOCATE_OBJECT 31 N N N N
SPELL_MAGIC_MISSILE 32 N Y Y N == 1
SPELL_POISON 33 Y N N Y
SPELL_PROTECT_FROM_EVIL 34 Y Y Y Y
SPELL_REMOVE_CURSE 35 Y Y N Y
SPELL_SANCTUARY 36 Y Y N Y
SPELL_SHOCKING_GRASP 37 N N N N == 7
SPELL_SLEEP 38 Y Y Y Y
SPELL_STRENGTH 39 Y Y N Y
SPELL_SUMMON 40 N N N N
SPELL_VENTRILOQUATE 41 N N N N
SPELL_WORD_OF_RECALL 42 Y Y Y Y
SPELL_REMOVE_POISON 43 Y N N Y
SPELL_SENCE_LIFE 44 Y N N Y
SPELL_IDENTIFY *53* N Y N N