lewark / inv.lua

Inventory management and autocrafting system for CC:Tweaked/Restitched

inv.lua

This software provides a lightweight, configurable inventory management and autocrafting system for ComputerCraft:Tweaked / Restitched. Sequences of recipes can be automatically crafted using a crafting turtle alongside crafting machines such as furnaces. A client interface is also provided, allowing quick retrieval and crafting of items, and this interface was created using a custom GUI toolkit.

Installation

The client and server software can be downloaded from GitHub and installed onto turtles in-game using gitget.

pastebin get W5ZkVYSi gitget
gitget knector01 inv.lua master inv
cd inv

Usage

This system requires that CC:Tweaked generic peripherals be enabled. Recent versions enable this feature by default but for older ones you may need to change a setting in computercraft_server.toml.

To use this system, you must connect your chests to a ComputerCraft wired modem network. ComputerCraft offers full-block wired modems crafted by putting a small wired modem into the crafting table, and this type must be used when connecting peripherals like chests and turtles that aren't full blocks. Place wired modems on each chest, connect the modems together with modem cables, and right-click on each modem to connect the chest peripherals to the network.

Then connect a crafting turtle to the network in a similar fashion. This turtle will act as the central server for the inventory system. Install the inv.lua software on this turtle, and run run_server.lua to host the server. Optionally, you can also create a startup.lua script in the turtle's root directory that runs the server on boot:

shell.setDir("inv")
shell.run("run_server.lua")

Finally, place a separate Advanced Turtle connected to the same network. This one will be used as a client to retrieve items from the inventory system. Install the software as before, then run inv_client.lua SERVER_ID on the client turtle, replacing SERVER_ID with the numeric computer ID of the server. This ID can be found by running the id command on the server turtle. If desired, you can make a startup script for the client as well:

local SERVER_ID = 1 -- replace with your server's ID
shell.setDir("inv")
shell.run("run_client.lua", SERVER_ID)

You can then use the client turtle's GUI to request items from the storage network, and they will be placed in the turtle's inventory. The turtles and chests can be placed anywhere as long as they are connected to the network by cables and modems, and an arbitrary number of client turtles can be connected.

Troubleshooting

Make sure to use cd to enter the repository folder before running the client or server so that the configuration files can be read.

If the client or server crash when run, or you are unable to view the list of items in the network, then one of the turtles likely has not been connected to the server properly (check the cables). If the items show up in the list but cannot be pulled into to the client inventory then you may have forgotten to right-click the modem to connect the turtle fully to the network.

Configuration

Devices

Custom settings for connected devices such as chests, furnaces, or barrels can be specified within JSON files inside the config/devices directory. Each file can contain a single rule or a list of rules that affect device behavior. For example, this rule assigns a certain type of inventory a higher priority so that items are preferentially stored within inventories of that type:

{
    "type":"storagedrawers:controller",
    "priority":3
}

Alternatively, a specific inventory can be configured with its own unique settings. In this example, an individual chest is given filters so that only specific items can be stored within it:

{
    "name":"minecraft:chest_0",
    "filters":[
        {"name":"minecraft:cobblestone"},
        {"tags":["minecraft:planks"]}
    ],
    "priority":2
}

Inventories can also be designated as crafting machines instead of storage. The default configuration under devices/minecraft.json contains this rule to treat furnaces as a machine:

{
    "type":"minecraft:furnace",
    "purpose":"crafting"
}

Possible values for the purpose field are crafting and storage, the latter of which is the default for connected devices with an inventory.

Recipes

Custom crafting recipes must be specified in JSON files within the config/recipes directory. Like inventory filters, recipes can address input items by name or by Ore Dictionary tags. The "tags" field may consist of an array of tags, e.g. ["tag","tag2"], or a dictionary in the format {"tag":true,"tag2":true}. An item matches a tag specification if one or more of the tags in the "tags" list is present on the item.

[
    {
        "machine":"workbench",
        "input":{
            "1":{"name":"minecraft:oak_log"}
        },
        "output":{
            "10":{
                "name":"minecraft:oak_planks",
                "count":4,
                "tags":["minecraft:planks"]
            }
        }
    },
    {
        "machine":"workbench",
        "input":{
            "1":{"tags":["minecraft:planks"]},
            "4":{"tags":["minecraft:planks"]}
        },
        "output":{
            "10":{
                "name":"minecraft:stick",
                "count":4,
                "tags":["forge:rods/wooden"]
            }
        }
    },
    {
        "machine":"minecraft:furnace",
        "input":{
            "1":{"name":"minecraft:cobblestone","count":8},
            "2":{"name":"minecraft:charcoal"}
        },
        "output":{
            "3":{"name":"minecraft:stone","count":8}
        }
    }
]

inv.lua's Issues

Organization

Ideas to organize the code more clearly:

• InvManager could be split into InvManager and ItemManager
• CraftManager could be split into RecipeManager and MachineManager
• ItemInfo and ItemCriteria are similar but have slightly different properties. Maybe subclass ItemCriteria from ItemInfo, add a new superclass for both, or just merge them into one class. Both combined into Item class.

Add inventory filters

Allow using the system for sorting by restricting items that can go in particular inventories

Add task error states

If a task fails then it should be possible for the system to recover

Assertion failed when crafting

Sometimes the crafting routine fails because the items it thinks it has are actually missing. Will need to see if I can reproduce reliably.

Fluid support

CC:Tweaked also supports moving fluids around, and supporting this API could be useful for crafting machines that depend on fluids.

To avoid code duplication, the InvManager class would need a parent class, StorageManager, from which FluidManager would also be derived. Similarly, Storage could be the superclass of ItemStorage and FluidStorage. Alternatively, to allow storage of fluids and items in the same block, Storage could be changed from a subclass of Device to an optional component.

I am unsure how to properly handle movement of items and fluids in StorageManager, since the push and pull methods have different arguments (where pushItems takes a slot number, pushFluids takes a fluid name).

Task UI

Add an interface to the client to view or manage running tasks

Check for fallback recipes

Currently, the system does not fall back to secondary recipes for Ore Dictionary items. This is a problem for resources where only one of multiple types may be available, e.g. wood.

Use configuration folders

Scan the recipe folder and add all JSON files under it. Add a devices folder that behaves the same way.

Additional possible feature: JSON files could either contain a single entry or a list of entries.

Furnace state change causes disconnect

When furnaces light up or shut off, the block ID changes, causing the peripheral to disconnect and reconnect. This causes problems with the current DeviceManager implementation, including double-disconnects and sometimes the furnace disappearing from the network altogether.

Support multiple machines per recipe

To reduce duplication, the system could allow recipes to specify multiple supported machines, like allowing food recipes to use either a smoker or a furnace.

This could be handled by making the "machine" field in recipes an array, or by adding a "provides" field to machines that allows them to act as multiple. I'm currently leaning toward using the device-provides method, since it keeps recipe definitions from needing to repeat several machine names. The system already supports virtual slot mapping, which removes any concerns of inventory slots not lining up.

Since smokers are faster than furnaces, it should be possible to prioritize them over plain furnaces as well. A benefit of handling it on the recipe side would be that priority could be set based on the array order. Alternatively, a "priority" field could be added to machines like is already present for storage.

To resolve the same duplication problem for electric furnaces, fuel could be handled as part of the device specification instead of the recipe.

Machine crafting

Make current crafting table code generic so that it can work with machines like furnaces

README outdated

GitGet seems to be confused by this repository, so point people to a different method such as clone.lua. (update: seems to work now?)

Client/server scripts were renamed as well

Tag format in configs

Maybe make the tags JSON format either accept a {"key":true,"key2":true} format or a ["val","val2"] format, converting the latter to the former, instead of the current tag/tags system

Display error message when not connected

Add a more clear error message when the turtle is not connected properly to a modem.

How do I find out the server id?

Might be a silly question, but how do I find out the SERVER_ID I need for the client to connect?

Slow item searching

When autocrafting, the slow speed to look up items becomes apparent.

Client freezes

The client hangs after crafting operations for some reason.

Item location indexing

Index item types by where they're stored to speed up retrieval

Code distribution is large

Because the screenshot PNG is included with the code, the downloaded program is too big to fit on a CC floppy disk. Maybe move the image to a separate branch?

Job system

Operations such as retrieving and crafting items could be handled as jobs. If an item is not in storage but has a defined crafting recipe, then the system would add jobs for retrieving each of the item's components as well. If these components are missing, then the system could attempt to craft them, and this process would apply recursively. Separate job queues could be used for jobs that are active versus ones that are waiting on other jobs to complete.

Add item search

Adding a search box to the top of the item list would allow for much easier use of the inventory system. The matching algorithm could be simple, case-insensitive matching, or could be a more complex fuzzy search akin to that of artist.

Redundant crafting steps

Under the current implementation, crafting tasks sometimes queue up extra copies of dependencies that aren't actually needed

UI doesn't update

The UI should be refreshed when item counts change in the system

Autocrafting system rework

The current implementation of autocrafting can be improved. Currently, the following tickets are associated:

• #28
• #14
• #27
• #29

A partial rewrite of that component may be necessary to resolve them. Plus, there are these lingering issues:

• #10
• #11

Built-in crafting table

Allow using turtle as a manual crafting table

May overlap with #6

Allow selecting input/output inventory

If using the client from a device like a computer or pocket computer without a built-in inventory, then a selector should be shown that allows picking an input/output inventory to stash requested items to or pull items from.

Recipe definition interface

Use the turtle interface to define new recipes

May overlap with #7

Cleanup

There is some duplicate code that can be reduced

Multiblock inputs/outputs

Some machines have I/O split across multiple blocks.
Add support for this through a group interface that combines multiple Devices into one.

Save item database to a file

Currently, item names and tags are forgotten when the server restarts, hindering proper display and crafting of recipes. These details should be saved to a file so that they persist.