As discussed/dictated elsewhere, my current vision is to have an Inventory class that derives from Object. An Entity would have a pointer to an Inventory that is created by scripts if/when an inventory is needed. An Inventory would be a positional array of Item, with its size decided at creation time. (In order to allow more efficient allocation. There will probably be some kind of create-and-transfer function to ease resizing.) The meaning of the positions is determined by scripts. For example, equipment slots would just be dedicated Inventory positions.
Item would be an ItemType*, ItemData*, and count. ItemType and ItemData are derived from Object. ItemType describes the intrinsic properties of the item. ItemData is used for dynamic properties of the item. And count is just a number for scripts to use. Particularly for items that don't need a full ItemData instance. Since both ItemType and ItemData are created and modified by scripts, the exact logic of when to use which for what is up to the user. For example, modified weapons could store mods in an ItemData or create a new ItemType each time.
Setting up this issue as both a reminder to myself to do all of that and to collect ideas for what sorts of builtin members to have for ItemType and ItemData. Given how usable Extension Members have already proven, and the highly script-centric nature of item semantics, I am unsure what is actually needed as a baseline.
As discussed/dictated elsewhere, my current vision is to have an
Inventoryclass that derives fromObject. AnEntitywould have a pointer to anInventorythat is created by scripts if/when an inventory is needed. AnInventorywould be a positional array ofItem, with its size decided at creation time. (In order to allow more efficient allocation. There will probably be some kind of create-and-transfer function to ease resizing.) The meaning of the positions is determined by scripts. For example, equipment slots would just be dedicatedInventorypositions.Itemwould be anItemType*,ItemData*, and count.ItemTypeandItemDataare derived fromObject.ItemTypedescribes the intrinsic properties of the item.ItemDatais used for dynamic properties of the item. And count is just a number for scripts to use. Particularly for items that don't need a fullItemDatainstance. Since bothItemTypeandItemDataare created and modified by scripts, the exact logic of when to use which for what is up to the user. For example, modified weapons could store mods in anItemDataor create a newItemTypeeach time.Setting up this issue as both a reminder to myself to do all of that and to collect ideas for what sorts of builtin members to have for
ItemTypeandItemData. Given how usable Extension Members have already proven, and the highly script-centric nature of item semantics, I am unsure what is actually needed as a baseline.