>We have implemented this on Death's Domain. >What we do is we update the objfile first before assigning >the objects to mobs. That is obvious. >What you is read in the objects, and then read in the zone file. >If the object is at max or above max, it will not load, due to >the constraints in the zone file. >You shouldn't have to add another field, referring to the >proposed 0 and 1 flag you had for ownership. >We don't use any flags of any sort to show if an item is limited. >Once again, it reads the objectfile first, like it is loading >the players' eq into the game, and it then goes to the zone file. I don't think this will quite work, because as far as I can tell Circlemud doesn't read in any individual player's rent file until they log in to the game. So the unique objects prototype will be loaded by db.c (obviously) and then the game will create at least one copy of it if its in the zone file. And I think the zone file only checks that zone, so if a player gets the unique obj, then leaves the zone, on next reset it might put in another (not positive about this, but I'm pretty sure if the only copy exists in a rent file then the game won't know about it until the guy logs in.) Of course, this could be completely wrong... I like the idea someone had earlier about giving a unique long int idnum to every copy of an object that is loaded, and purging the rent file of duplicates on each reboot... very clever, but I'm havin a bit of a prob trying to implement it! Steve
This archive was generated by hypermail 2b30 : 12/07/00 PST