Page 1 of 1

request for supports_bar() on entity prototypes

Posted: Tue Jul 13, 2021 3:52 am
by Honktown
There only seems to be at most one inventory per entity type which can support a bar, and it can only be known via the LuaInventory. I'm manipulating a chests bar, and I know 100% of the time the chests I'm manipulating will have the exact same behavior, but I can't cache them in advance. Containers might be the only type which can disable the bar in prototype, and as far as I see, no inventory supports enable/disable bar at runtime.

Re: request for supports_bar() on entity prototypes

Posted: Wed Jul 28, 2021 8:28 pm
by Rseding91
I'm not sure I understand what you're asking for. An entity can have any number of inventories of which any number could have bars. Currently there aren't any entities with more than 1 inventory with a bar but nothing prevents us from making one at some future point.

Re: request for supports_bar() on entity prototypes

Posted: Thu Jul 29, 2021 8:43 pm
by Honktown
Rseding91 wrote:
Wed Jul 28, 2021 8:28 pm
I'm not sure I understand what you're asking for. An entity can have any number of inventories of which any number could have bars. Currently there aren't any entities with more than 1 inventory with a bar but nothing prevents us from making one at some future point.
Bar support is exactly what I'm looking for, as it is a read-only property. A future-compatible solution would be to have inventory prototypes, or at least a table of the read-only properties. e.g. LuaEntityPrototype.get_inventory_prototype(defines.inventory.chest) -> nil or table of inventory properties. (an item-with-inventory also has an inventory, as a side-note)

Relevant to the implementation, it'd be up to the implementer to decide if a nil value from data gets translated to an explicit value or something in-between, like nil value -> implicit default and a value which is the same as default but explicit, is present. i.e. for a container prototypes enabled_inventory_bar, the omission is true and could be nil during control, but true or false show up as present and true or false.

Ironically related, one can argue that although an item-with-inventory is the only item with an inventory, there's no reason it couldn't have more than one, or other classes like item-with-entity-data couldn't have inventories in the future. Why should an item-with-inventory be special about it's inventory in a LuaItemPrototype! A common interface to get an inventory "prototype" might simplify a lot of this.