Advice Request: Correct area of code to add a "blacklist categories" and "required categories" set of flags?

[Polatrite]

I am working on a project that utilizes many different inventory grids with different purposes - a normal inventory, as well as individual slots for equipment, a furnace grid for smelting, a workbench grid for milling, a combining grid for synthesizing, etc.

TL;DR: I'm wondering where I should integrate these new constraints to Gloot to support this functionality for all inventory types in the cleanest way possible. This could also be a feature request, but I'm keen on having it somewhat quickly so I can just add it myself and submit a PR!

---

Each grid is allowed to accept certain categories of items, but not accept others. I plan to implement this with a blacklist and a required list.

Items will contain a "flags" property which is an array of all the categories they belong to.

A sword might be [item, equippable, weapon, sword]. A piece of raw meat might be [item, food, raw], whereas cooked meat might be [item, food, cooked, consumable].

Blacklist: Array[Enum.ITEM_CATEGORIES]
A list of item categories that cannot be inserted into this inventory. If an item contains any of the blacklisted categories, the item transfer will fail.

Required list: Array[Enum.ITEM_CATEGORIES]
A list of item categories that are required to be inserted into this inventory. If an item does not contain all of the required categories, the item transfer will fail.

Examples of how this is used:

• The main player inventory might have a required list of ['item'].
• A cooking station might have a required list of ['food'] but a blacklist of ['cooked'].
• A smelting furnace might have a required list of ['smeltable'].
• A helmet equipment slot on a paperdoll might have a required list of ['equipment', 'helmet'] but a blacklist of ['broken']

The goal here being to encode lots of gameplay rules into the required/blacklist system and drastically cut down on bespoke validation logic all over the place - let the inventory system manage all of this for us.

---

I was looking through the codebase (which I am admittedly not super familiar with) and originally implemented a hacky version of this at the control level. However after digging a bit more, it seems like the ConstraintManager and specifically adding a new constraint (or two) for the required vs. blacklist logic might seem like the best course of action. Do you have any advice on how to tackle this problem?

Thanks for reading.

[peter-kish]

Hi,

The idea makes a lot of sense and ItemSlot already has something similar implemented in the form of an overridable can_hold_item method. It almost always returns true, but the idea is to inherit ItemSlot and override can_hold_item it with custom checks.

Speaking off the top of my head, this is the approach I would take to implement something like that:

1. Implement a can_hold_item(item: InventoryItem) for the Inventory class that would always return true. Again, the idea is to inherit from the Inventory class (or one of it's derivatives) and override this method.
2. Modify the Inventory._can_add_item method, so that always returns false when can_hold_item fails. This will make Inventory.add_item and Inventory.transfer fail if the inventory can't hold the given item.
3. Once Inventory.can_hold_item is properly implemented you can override it in your derived inventory class with custom checks, where you would check the item categories and blacklist/required list of the inventory.
4. There's two ways you can implement categories that I can think of:
   1. Via item properties in the protoset: Unfortunately, protosets don't support arrays, but it's still doable as a single string that contains space-separated list of categories (would have to be parsed though)
   2. Via node properties: Inherit from InventoryItem, add an array of strings as a member and export it to be editable from the inspector (this one may be easier to implement at first but you may miss out on some useful features of the protosets)

Anyways, right now, I would suggest against taking the constraints approach for a few reasons:

1. Inventory constraints have been recently added and the code is not very polished/modification friendly :(
2. While my idea for constraints was a component based approach: allowing the user to come up with new constraints to modify inventory behavior (same as you described), they are still not on that level. The constraints are not totally independent and the ConstraintManager is aware of their potential presence. Adding new constraints will definitely mess up some of the logic. Ideally, we will be able to just inherit from InventoryConstraint, add some custom logic and add that constraint to the inventory with no additional changes, but we're not quite there yet.

Hope this helped.

[peter-kish]

I opened a separate issue for adding Inventory.can_hold_item. Will move this over to discussions.