Re: [Adonthell-devel] Equipment test

[ksterker]

Von: Mike Avery <address@hidden>

> > This has another advantage: we can now ensure that manager::equip 
> > does> not accept slots that aren't meant for equipment.
> 
> Great idea.

Later on we might even change this to a more generic flag that could ensure 
that an 
inventory only takes ITEMS, SPELLS, FEATS, etc. (or any combination of these).


> I think it should be reported yeah.  For our purposes though, what 
> about a slight change to work around this?
> 
> Can we work around this by using a count of 0 as the "null count" 
> instead of NULL?  They're identical for our uses unless there's something 
> that 
> I have overlooked?

That would work for equip, yeah. Where there are problems would be unequip. If 
that is 
called on an empty slot, there's no item to return. What we could do, however, 
would be 
defining a 'null' item or somesuch.

But I'll also send a mail to the SWIG people. If the rather odd behaviour 
wasn't created on 
purpose, they might probably change it. As far as I see, a fix would consist of 
deleting 3 
or 4 lines :-).


> You mean coins or whatever I assume, yeah.

For example. Practically any item that does not change state would be 
immutable, 
meaning only on instance of such an item exists, which is shared between all 
owners of 
such item. That means, such items cannot store a pointer to the slot they're 
kept in. 
However, when retrieving them via slot::get_item(), the slot they come from is 
(temporarily) assigned.

The problem I ran into was with the Arrows in the test script. When printing 
the 
inventories, I use get_item to retrieve the items (of course). And when I then 
try to add 
more Arrows to the Quiver, slot::add() fails, as it does not allow addition of 
items from 
the same slot. Now that I write this, I believe that this restriction could be 
limited to 
_mutable_ elements, which would also work around this problem. 


> Should the un/equip methods examine the in/out items and make effect
> adjustments themselves, or should all un/equip transactions call
> un/equipped() upon success and we can handle applying/removing effects
> there?

I would think that un/equip handles those (or at least makes a call to the 
right manager 
method).
 
> This raises the question then of whether un/equipped() should be 
> moved from the item to the manager class.

Well, I assume that the manager had the methods below for exactly that purpose. 
However, for the purpose of triggering plot related events, item will need 
those methods  
too. After all, applying/removing effects would be something generic (thus the 
manager 
can and shall handle it), while the plot triggers are something very item 
specific (thus 
item should take care of it).


> If we want un/equip() to apply effects, then manager::un/equipped() 
> doesn'tneed to exist, and item::un/equipped() is good for plot 
> hooks, but I don't see much use for it beyond that.

See above. (Actually, the choice is yours, though).


> Igh.  I hope this didn't drive you too nuts :)

Not as much as a few other things I haven't even mentioned ;).

 
> I'm going to start work on the manager class character data 
> structures.

Cool.

Kai