Object Stacking

From: George Greer (greerga@circlemud.org)
Date: 09/04/01


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