[Adonthell-devel] More on items ...

[Kai Sterker]

Slowly I am getting closer to a sensible solution:

As it makes inventories much easier if we work with (semi-)global item
instances, that'll be the way to go. It has more advantages too: 

* uses less memory, as only one instance of each item will exist.
* faster loading/saving, as no complete items are saved only a unique 
  id of the item. Enough to retrieve it from the item storage when
  loading. (The item storage needs to be saved/loaded too, however)
* faster inventory operations. No cloning needed when moving items
  around.

That will only work for immutable items though. For mutable items, it
seems better to use individual instances right from the beginning. This
has the following advantages:

* no cloning required. as mutable items will always have a refcount of
  one, they can be changed without problems. Also, they can be moved
  around inventories just like immutable items.
* no hash required, as we won't stack mutable items via refcounts.


Now more on stacking mutable items: as Alex said, stacking torches for
example may not make sense, but I would at least like to have the option
to stack mutable items. However, it is important to have consistent
ointerface for inventory/slot operations, no matter whether dealing with
mutable or immutable items. I.e, to move (a stack of) items from one
inventory to the other, you'd have the following method:

    bool inventory::add_item (item_base *item, int & count)

But what if you move a stack of mutable items, which are different
instances without refcount? If we'd store mutable item stacks as linked
list (that means, the item_base class also has a 'item_base *next'
member) we could move them just like immutable items, by passing the
topmost and a count. No need to move arrays of items or somesuch.
Copying part of such stack to another inventory isn't costly either. If
we know the total size of the stack, we can easily copy the last n items
to the new inventory. The first of those n items will be the topmost of
the stack in the new inventory. And the last item of the old stack will
have its 'next' member set to NULL.


I think this is a quite elegant solution, as mutable and immutable items
are treated much the same, although they are completely different. It'll
also fit very well to the inventory spec I'm working on (which has some
very neat features that I wouldn't want to drop).


For performance reason, the 'mutable' flag would be a member of C++
item_base, not of the Python item class. As it's mainly needed on C++
side, it would be pointless to store it on Python side.


What do you say?

Kai


P.S. Inventory spec will follow soon, I think :).