http://www.circlemud.org/~greerga/OBJstack.patch DO NOT apply this to your production MUD. I know I do not handle all of the cases yet that need to be fixed. (Think: 'drop all', obj_to_obj, etc.) It also might crash (lots of pointer twiddling) or cause you to not be able to pick up anything ever after dropping everything (I think I took care of that one but haven't checked). Anyway, here's a little log of what you'd likely see: > i You are carrying: a lantern > get lantern You get a lantern. > get lantern You get a lantern. > i You are carrying: (3*)a lantern > drop lantern You drop a lantern. > i You are carrying: (2*)a lantern > drop lantern You drop a lantern. > i You are carrying: a lantern > drop lantern You drop a lantern. > i You are carrying: Nothing. Debugging output for the same would be: George retrieving crash-saved items and entering game. Adding 3031 ( 1) to ( -1/ 1204) George George (level 34) has 1 object (max 30). Removing 3031 ( 1) from ( -1/ 1204) George Adding 3031 ( 1) to ( -1/ 1204) George Adding 5231 ( 1) to ( 5201/ 5205) the lamia Adding 4052 ( 1) to ( 4055/ 4071) the hobgoblin Adding 4052 ( 1) to ( 4051/ 4070) the warrior Merging 3031 ( 2) to ( -1/ 1204) George Merging 3031 ( 3) to ( -1/ 1204) George Adding 3031 ( 2) to ( -1/ 1204) George Cloning 3031 ( 3) from ( -1/ 1204) George Adding 5241 ( 1) to ( 5201/ 5238) the lamia Adding 3031 ( 1) to ( -1/ 1204) George Cloning 3031 ( 2) from ( -1/ 1204) George Adding 5236 ( 1) to ( 5201/ 5220) the lamia Removing 3031 ( 1) from ( -1/ 1204) George Some mobiles just happened to be active in there. The information is: object vnum (count) to/from (mob vnum, mob inroom vnum) mob name NOTE: I have not done obj_(from|to)_(obj|room) yet. They're going to be exactly like obj_(to|from)_char. I should probably write functions named obj_(from|to)_list so the 6 functions can share the list adding/removing code. Also, ignore the warning in shop.c. The space used in the obj_data structure is currently 2-byte padding anyway on a 32-bit architecture so it shouldn't use any extra memory. I made it signed because I was toying around with the idea of a -1 count item being infinitely copyable. I'm not sure it's a very practical but no one should be stacking 32,767 objects anyway so making the limit 65,535 is a little silly. Perhaps I'd make it unsigned if I was making gold an object and using the stacking code for that, but that would have other implications and need more than counts of 65,535 anyway. Mostly I'm interested in if anyone can see a hole in my method of trying to make sure existing obj_(from|to)_(char|obj|room) code works. A function keeping a pointer to every single object in someone's inventory and the object they're adding would break, but I mean something non-contrived. BTW, the decision on whether or not it becomes stock code will be done when I see how well it cleans up the shop code in comparison to what it causes elsewhere. If not, it will probably end up on the FTP site contrib section. -- George Greer greerga@circlemud.org -- +---------------------------------------------------------------+ | 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 : 12/06/01 PST