lewark / inv.lua Goto Github PK

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?

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.

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.

Allow using turtle as a manual crafting table

May overlap with #6

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

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

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.

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

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

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

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

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

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

The client hangs after crafting operations for some reason.

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.

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

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 the turtle interface to define new recipes

May overlap with #7

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

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).

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

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.

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

There is some duplicate code that can be reduced

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.

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

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.

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

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

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.