Extend inventory actor functionality

[petterarvidsson]

To accommodate more advanced use cases such as machines extend the inventory actor with new functionality.

As a first step, add three different types of inventories that can be associated with a UUID (block):

• STORAGE, generic multi purpose storage
• INPUT, inventory designated for input
• OUTPUT, inventory designated for output

Then add (or rework existing) messages:

• GetInventories(uuid) -> [uuid, storage, input, output]
• AddToInventory(uuid, inventoryType, stack) -> [uuid, inventoryType, stack]
• RemoveFromInventory(uuid, inventoryType, blockTypeId, amount) -> [uuid, inventoryType, stack]
• ReplaceInventorySlot(uuid, inventoryType, slot, stack) -> [uuid, inventoryType, slot, stack]
• TryToReplaceInventorySlot(uuid, inventoryType, slot, stack) -> [uuid, inventoryType, slot, stack]
• TransferBetweenInventories(fromUuid. fromInventoryType, toUuid, toInvenotryType, blockTypeId, amount) -> [?]
• RegisterForInventoriesEvents(uuid)
• DeregisterForInventoriesEvents(uuid)
• InventoryEvent(uuid)

[petterarvidsson]

@nsg I will implement this for release 10 with the more generic solution where the inventory type is a proper type (my idea of syntax was name/space/INVENTORY_TYPE_NAME, e.g. org/konstructs/STORAGE). So every block with an id (UUID) can have any number of storages each with a namespaced id. What do you think?

[petterarvidsson]

I will initially leave out the inventory events in relation to the pull discussion we had. Let's see if we need that when we start implementing some machines.

[nsg]

Sounds good :+1:

[petterarvidsson]

Api messages are being added in konstructs/server-api#27

[nsg]

Looking good