Hello,
Looking at this I notice one small problem. If this is used while the
MUD is running and not just at bootup you could accidentally load an extra
one up. A simple scenario is this: A player kills the mob with the item
and recieves it. Saves his character. Now the item won't load up because
it's found in the pfile. Well, he's disarmed, and a mob picks up the
item. He has to log off and again saves his character. Now the item will load
because it's not in his pfile. Unfortunatly there would be two different
occurances of the item. A simple check to see if the item exists in the
world would make this work pretty perfectly.
A seperate idea would be to track the item seperatly in a file. This
way when the item loads it checks to see how many of the item there is.
The second part of this is to also use olc automatically to save it to a
mob if a mob picks it up, or save it to a room if it's dropped. What this
will do is keep the item static over crashes, reboots, or copyovers. So
in the same scenario as above, when the player is disarmed and the mob
gets the item it saves to a seperate area that has a reset that the mob
will get it.
David Roundhill
> if ( ( obj = get_obj_index(pReset->arg1) ) )
> {
> if ( obj->pIndexData->limit ) // if there's a limit at all
> {
> char buf[MAX_STRING_LENGTH];
> FILE *fp;
> bool loadobj = FALSE;
>
> sprintf(buf,"grep -h \"Vnum %d\" %s*",pReset->arg1,PLAYER_DIR);
> if ( ( fp = popen(buf,"r") ) )
> {
> int count = 0,vnum;
>
> do
> {
> fread_word(fp);
> vnum = fread_number(fp);
> if ( vnum == obj->pIndexData->vnum )
> count++;
> } while ( !feof(fp) || count >= obj->pIndexData->limit )
>
> if ( count < obj->pIndexData->limit )
> loadobj = TRUE;
> }
>
> pclose(fp);
> if ( !loadobj )
> continue;
> }
> }
>
> This little piece of code should plug right into the case 'O' section of the
> reset loop in void reset_room, and grep for and count the total number of
> objects of the vnum of the one in question... if it finds no entries in any
> pfile, it will keep going till it loads the object, or if it finds less than
> the amount set for "limit" it will go ahead and load, otherwise, it will
> 'continue' to the next element in the reset list and skip loading this
> item... i could have made it simply do fread_to_eol's to count the number of
> lines that were returned from the grep, but there would be a slight bug with
> that, if the vnum in question were say, 101, and it found a vnum for 1015 in
> someone's pfile, it would return that on the grep line as well, so i made it
> read the second piece of the line to compare to the item vnum and make sure
> it's a match... The only other thing that could interfere with it as it is,
> and it's an extremely rare case... would be if the person had a pet that had
> the same Vnum... but this could be easily fixed if you changed the wording
> for fwrite_pet and fread_pet to add a Vnump or something and read that from
> the pfile, instead of Vnum... anyway, this should be along the lines of what
> you're looking for :)
