These resets do not take place inside the game. They only reset once. When the mud is booted OR copyoverd. Once loaded, if they are destroyed or lost to a mob they will not re-load until the next reboot or copyover. So that scenario is not an issue. The function is only called inside of boot_db.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marquoz Sent: Saturday, April 24, 2004 11:05 PM To: Richard Lindsey Cc: Rainer Roomet; [email protected] Subject: RE: question about limiting items 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 :) -- ROM mailing list [email protected] http://www.rom.org/cgi-bin/mailman/listinfo/rom
