Saving mudmail, [Was: Mud balancing (Was OasisOLC 2.0 and Circleblp15)]

From: Peter Ajamian (
Date: 11/21/00

Shane Lee wrote:
> I'm not wanting corpses, or unique items to save, I just want mail
> to save, and xapobjs seemed to be the way to go.

Well, I got mudmail to save, but in quite a different way.  What I did
ended up being very complex and I could not for the life of me come up
with a patch or snippet to be able to do it again, but here's the
general gist of how I did it...

Unfortunately, the rent files do not store object descriptions (they are
reloaded from the object's prototype when the player unrents), this
means that it would seem that you would have to come up with another
means to store the descriptions (text) of postcards.  Fortunately, there
is already a system that stores that text, I'm referring to the mudmail
system itself as it stores the text of new mudmails until they are
deleivered.  With a little tweaking it can be made to store the text of
mudmails which have been read as well.

The mudmail file stores the mail in blocks of 100 bytes (this is easily
changed by changing a single #define).  There are two main types of
blocks, a header block and a data block, you can see all the structures
for this in the file mail.h, it works like this...

Header block:
/ (long) -1 / header data / data /

Data block:
/ (long) offset to next data block / data /

Both types share a single long as the first value, this is either the
offset of the next data block in the file, or a specific negative value
which is one of the following...

#define HEADER_BLOCK  -1
#define LAST_BLOCK    -2
#define DELETED_BLOCK -3

If the long is -1 then this is a header block, if it's -2 then this is
the last data block of the mudmail, if it's -3 then this block used to
be part of a mudmail which has since been deleted (see my showmail.c
utility available on the circlemud FTP site to see how it can recover up
to the first two blocks of a deleted mudmail), if the value is positive
then it is a data block and the value is used as an offset to the next
block of data for this mudmail.

The header data itself also contains the offest of the next data block.
This is necessary because the value normally used to find the next block
is being used to indicate that this is a header block instead.  Valid
values for this are -2 (for the last block) or a positive value
indicating the offset of the next block of data.  The header block also
contains data on the time the mail was written and the player ID# of the
sender and recipient of the mudmail.

At this point it should be fairly clear how the mudmail system stores
the mudmails, if you want some decent code to display mudmails from the
file I will again refer you to my showmail.c utility.

Now, what we want to do is add the capability to be able to store the
text of mudmails and be able to load them up from the mudmail file.  For
this I did some tweaking on both the mudmail and the rent systems.
First off I needed a way to tell the rent system that this is a mudmail
so that it will deal with it differently when it unrents the mail, this
is done by setting the vnum of the object to -2 (currently -1 is used to
define a non-existant VNUM).  Note that the mudmail system will also
require some tweaking in order for it to save an object with a negative
VNUM (it normally discards these).  When the mail is unrented the -2
tells the rent system to load the mail from the mudmail system instead
of trying to copy the (non-existant) prototype.  In order to be able to
determine which file block to load the mudmail the block number (offset
/ block size, normally 100) is stored in one of the objects values
(which are saved in the rent file).

Okay, now, on the mudmail side of things, we need to do some tweaking so
that the mail will not be deleted right away, simply not changing the
next-block offset to -3 will not work because the mudmail system will
keep trying to deliver the mudmail to the recipient after he already has
it until such a time when the mail is actually deleted.  The solution is
relatively simple and requires adding an additional valut to indicate
that the mail has been retrieved, but not deleted, -4 should do fine.
-4 would indicate that this is a header block of a mudmail which has
been retrieved, but not deleted.  You will have to tweak the mudmail
system so it knows how to handle this properly.

The last thing to do is to delete the mudmail when the object is
deleted, either by way of junking the object, dropping it in a dump,
being consumed by maggots (decomposing with a dead body), etc., but not
from renting and exiting, or from giving the object to another player,
or mob, or dropping it in a non-dump room.  This will allow the mail to
be passed off to a different player and then that player can rent with
it and unrent with it properly as if it were his object (well it really
IS his object at this point).

The only downfall to the system is the possibility of having the mudmail
file get cluttered up with mudmails that were dropped right before the
game crashed or rebooted (or copyover, etc.), and from mudmails that wre
owned by players who delete.  I have been running this system for quite
some time now and the mudmail file has not grown excessivlely large from
these "orphaned" mudmails, should they ever get to that point I will
either (1) simply delete (or rename) the file, or (2) write a utility to
go through and purge out all the orphaned entries during maintenance
(note that this would require an extensive amount of searching through
the rent files to find mudmail objects in order to know which ones to
save and which ones to purge).

REgards, Peter

   | FAQ: |
   | Archives: |

This archive was generated by hypermail 2b30 : 04/11/01 PDT