RE: [Adonthell-devel] equipping items

[Mike Avery]

I've been thinking about this stuff too Kai, but I didn't want to just go
and start ripping your code apart!

We need to come up with a plan so we can divide and conquer without breaking
each-other's stuff.


> Currently, an item's equip method does both check whether the item can
> be equipped and apply the item effects when it is equipped. 
> But since we
> decided to not apply item effects to the character at all, this has to
> be changed.

Right, I believe most of this code should be seaparated from the character
iteself.  I have some ideas below that I'd like you to comment on.

 
> So, first of all we'll need a method like can_equip that gets a
> character and returns true or false. If an item does not implement the
> method, we would assume false.

This would need to check requirements for equipping, like STR, DEX, race etc
obviously, but you know this already :)
 
> Another task is finding out into which slot an item fits. 
> This would be
> taken care of by the item manager, as discussed. The neccessary
> information could be take from the item's categories. The 
> manager could
> have a mapping from categories to slots, since 1 category 
> could fit into
> several slots. That mapping shouldn't be hard-coded, but read from a
> data file, so that it remains flexible.

OK.  I was wondering about an enum for this.


//enum for equipable slots of a given item
enum {
        HEAD = 0x1,
        NECK = 0x2,
        NAPE = 0x3
        ARMS = 0x4,
        LEFT_FINGER = 0x5,
        RIGHT_FINGER = 0x6,
        LEFT_HAND = 0x7,
        RIGHT_HAND = 0x8,
        ARMS = 0x9,
        TORSO = 0x10,
        BACK = 0x11,
        LEGS = 0x12,
        FEET = 0x13
};

Some Pseudo (C) for equipping a helment on the head:

if ( char.inv.item.equipable_slots &HEAD ) {
        char.equip (character, char. helmet, slot);
        ...
}


What are your thoughts on this?  Seems easier than parsing categories and
keeps things easy for people to edit and understand.


> * bool equip (item_base*, slot*)
>   Actually equips the given item in the given slot. Returns true on
>   success, false on failure. If an item is already equipped, the
>   two items should be swapped. NULL should be allowed as item, which
>   would just unequip the equipped item (and place it in the 
> character's
>   inventory).

I would think that this method should do ONLY the placing of an item into a
slot, and that's it.  Return a bool for success/failure.  The existing
methods on the character would be good for this and are already in place. I
think the handling of swapping items etc might be better handled at a higher
level.

Here is how I have been envisioning the logic.  Let me know if you think I'm
out of whack.  Some of the pseudocode below doesn't reflect the current
methods, but I think you'll understand where I'm coming from.

Here's a rough idea:

In the manager class.....

def equip ( item, char, slot ): 
        
        //Is the slot empty?
        if  not char.equip.slot.accepts( item ):
                
                // Swap items
                swapped_item = char.inv.get_slot( slot )
                if char.unequip.remove( slot, item.count ) == 0:
                        if char.equip.add ( slot, item.count) == 0:
                                return *swapped_item

                // something has failed, return the original item to the
caller
                return item


        //No swapping necessary
        if char.equip.add ( slot, item ) == 0: return 0 
        
        //Something has failed, return the original item to the caller
        return item

The way I see it, the equip methods on the character could still be useful.
If the methods that are actually doing the equiping/unequiping of items do
nothing but return a bool for equip/unequip success, or a bool for
*something* being in the slot, that leaves us the opportunity to have the
mamanger handle all scenarios without weighting the character down with the
clutter.

The example above is rough, but something similar implemented in the manager
would be flexible, while handling all of the logic centrally.



> A second alternative would be to exchange newly and currently equipped
> item. But unequipping an item without equipping a new one would be
> handled by an unequip method that would indeed return the 
> item, so that
> the caller can decide what to do. In that case, passing NULL as item
> wouldn't be valid.

See above.  A failure would be result in the return of the items passed.  If
we do have a failure equipping for some reason, we won't lose items. Also it
would lend itself to good default behaviour, for screen updates (items in
hand, drag/drop items in the iventory etc).  The correct item would be shown
if a faulire ocurred, and the GUI would be correct.  This could also be used
for situations where the character doesn't meet requirements for equipping
an item.  Just return the item passed, and it doesn't appear on the
character, gets back to where it came from, etc.


> Remains the question whether we still need the (optional) equip and
> unequip method of items. We don't have to apply or remove item effects
> to characters, so they wouldn't be needed for that. The question is
> whether they might be of any use for setting/unsetting plot-related
> flags. However, at present I couldn't think of a situation that would
> absolutely require this. Whether a character wears an item or 
> not can be
> detected otherwise, adjustments to character attributes are handled by
> the manager. OTOH, it wouldn't hurt to keep these two methods around,
> just in case equipping/removing an item will have to trigger 
> a dialogue
> or cutscene or some other event.
 
Doesnt hurt.  personally, I think the methods for equip/remove/slot_empty
could be just about anywhere.  We should decide which spot makes most sense
though. Character, Manager, Inventory, Item.  Which makes the most sense to
you?
 

> So much for that. If you think that above is okay, I could start with
> the implementation. Shouldn't be too difficult, as a lot of 
> the required
> functionality is already in place.

Yep!  Just need to make the manager really!

I'd like to know your thoughts on the stuff above.  Are we on the same page
more or less?

Mike