Re: [Adonthell-devel] inventory news

[Alexandre Courbot]

> Finally I did some improvements on the items/inventory system. Right 
> now, it looks as follows (view with fixed font):

Looks fine! How have you generated the diagram btw? Any special
software? Hand made?

Some comments:

>               |            ----------------------------------------- < |
>               |            |    item_base                          |   |
>               |            | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |   |
>               -------------|-character_base * owner                |   |

We can retrieve the owner by following the inventory link. I think we
should rather do that way, because otherwise we'd have many character
pointers to change if, say, an whole inventory is given to someone else
(and that's the kind of situation where we would FORGET to do it, and
hang ourselves one week long to find the bug! :))

>                            | equip (character_base * c)            |
>                            | combine (item_base * i)               |
>                            | use ()                                |
>                            | drop ()                               |
>                            | pickup (character_base * c)           |
>                            | enchant ()                            |
>                            | sell (character_base * c, u_int16 p)  |
>                            | eat ( character_base * c )            |

I wonder whether all these methods are necessary. Some, like enchant(),
are specific to a certain kind of objects only. The Python
representation of objects is so that each Python file correspond to a
kind of object, and have all the methods the object can perform (correct
me if I'm wrong, Kai). Maybe it'd be worth to propose a
perform_action(name_of_action, parameters) method to call any of the
python method. For example, perform_action("use", NULL) would be
identical to use(). Well, don't worry too much about it for now - it
looks already fine and you can safely go forth :)

Actually, our items representation via Python classes is just fine. Look
at this example that just popped out of my tormented mind:

Say you have a class for shields (generic enough to handle any kind of
shield):

class shield:
        def __init__ (self, name, protection_value)
                ....

        ....

And another class for cursed items:

class cursed:
        # Returns 1 of the object can be dropped, 0 otherwise
        def drop(self)
                # Can only be dropped if uncursed
                return get_value("uncursed")


How would you then make a cursed shield?

class cursed_shield(shield, cursed):
        pass

And voila! :)

Maybe there are some restrictions I haven't taken into account, but the
base idea is here. So, the base definition looks fine Thorsten, please
go ahead! :)

Alex.
-- 
http://www.gnurou.org