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: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html | | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html | +---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/11/01 PDT