EnvyMud release 1.0
Thursday, 30th June 1994

Kahn		michael@uclink.berkeley.edu
Thelonius	dave@mechatro2.berkeley.edu
Kith		kith@marble.bu.edu
Hatchet		hatchet@uclink.berkeley.edu



=== Player File Format

Player files are ASCII files.

A player file contains a player section followed by one or more object
sections.  Each section contains several lines.  Each line contains a
keyword followed by a value.

An old Internet dictum says 'be conservative in what you send and liberal
in what you accept'.  Thus Envy writes player files in a fixed order, but
accepts flexible ordering, partial files, et cetera.

There are two section types: #PLAYER and #OBJECT.  The #PLAYER section
defines player values.  Each #OBJECT section defines one object.  A third
section type, #MOB, is partially implemented and may be implemented in a
future release.

Envy writes one #PLAYER section per file, but will read multiple sections.
If the same value is specified twice the later value generally overrides
earlier values; some lines, such as the 'Affect line', just append more
affects.  If a value is not specified, some default value is used.

Players are saved with their equipment on.  Thus, the values in the #PLAYER
section reflect current equipment applies, including 'Hitroll', 'Damroll',
'Armor', and 'AttrMod', as well as hit points, mana, move, and others.
Thus, great care is needed when adding or deleting objects which a player
is currently wearing.

A #OBJECT section contains all the object values, including the object's
current wear location.  Objects which have been 'oset' retain all of their
values.  Again, editing an object which is currently being worn requires
care; the corresponding #PLAYER state must also be changed to match.

Each #OBJECT has a nesting level.  Objects in inventory or equipment list have
nesting level 0.  Objects inside a container in inventory or equipment list
have nesting level 1.  Objects inside a level-1 object are level 2, et cetera.
Objects deeper than nesting level 100 are quietly discarded.  This nesting
level is used to reconstruct container contents when loading objects.  Thus,
if you delete a container from a file, its objects are likely to be loaded
inside the previous object; and if that's not a container, the player will be
unable to get them out of the object.  To avoid this problem, reset the
nesting level of each contained object to 0.

Objects are stored in the file in reverse inventory-order list.  This is not
pretty, but it allows the use of standard 'obj_to_obj' and 'obj_to_char' calls
to construct the object lists.

You may add new fields to players and objects.  Because of the line-oriented
ASCII format, changing a structure size in 'merc.h' will never invalidate a
player file.   Naturally, you must ensure that when an old file which does
not contain a line for a new field is read in, the new field is set to some
reasonable default value.  E.g., if you add a 'home town' name for players,
then initialize it to 'Midgaard' before reading in the player file, so that
old players get the 'Midgaard' value, and new players get whatever value is
on that line of their file.

Similarly if you delete a field from the player or object structure, you
must leave the parsing line for it in 'fread_char' or 'fread_obj'; simply
assign it into a dummy variable.  This allows your old player files to
continue loading.



=== How to Add a New Char Field

(1) Add the field to the appropriate structure in 'merc.h'.

(2) Initialize the field in 'create_char' or 'clear_char' in 'db.c'.

(3) Initialize the field in 'load_char_obj' in 'save.c' if needed.
    Make sure that old players which do not have the field are
    initialized to a reasonable value.

(4) Add lines to write out the field in 'fwrite_char' in 'save.c'.

(5) Add lines to read in the field in 'fread_char' in 'save.c'.



=== How to Add a New Object Field

(1) Add the field to the appropriate structure in 'merc.h'.

(2) Initialize the field in 'create_object' in 'db.c'.

(3) Initialize the field in 'fread_obj' in 'save.c' if needed.
    Make sure that objects which do not have the field are
    initialized to a reasonable value.

(4) Add lines to write out the field in 'fwrite_obj' in 'save.c'.

(5) Add lines to read in the field in 'fread_obj' in 'save.c'.



=== Immortal commands

Immortal commands in Envy 1.0 are considered Skills.  Each command is
stored as a player skill trained at 100%.  Each immortal must have the
level and the skill at 100% in order to use that particular imm command.
This allows for customized immortals with customized skills.

To give an immortal a particular imm skill, edit the playerfile with your
favorite text editor and add in the #PLAYER section:

Skll	100 '<name:phrase>'

As an example:
#PLAYER
Nm	Kahn~
Skll	100 'advance'
Skll	100 'reboot'
End

#END