Add a list-based crafting interface

[rubensworks]

Closes #10.

Adds a List-Based Crafting Interface part: a single variable slot that accepts a ValueTypeList of ValueRecipe, and exposes every recipe in that list to the crafting network. This lets a whole recipe set be derived with logic (Machine Reader, recipesbyinput/recipesbyoutput, filtered lists) instead of being placed card by card, which is the limitation raised in the issue: nine slots per interface is not enough in large packs, and the attuned interface offers no control over which of the target's recipes are used.

Approach

The variable machinery that lived in PartTypeInterfaceCrafting moves into a new core/part/PartTypeInterfaceCraftingVariableBase, shared by both variants:

• currentRecipes becomes one list of recipes per slot instead of a single recipe, with a cached flattened view for getRecipes() (it is called on every addCraftingInterface).
• Value extraction moves behind extractRecipes(int slot, IValue value). The base keeps the type check, the EvaluationException to slot-message path, and the isValid loop honouring validateRecipesCraftingInterface / disableCraftingCheck.
• NBT keys (variables, recipeSlotMessages, recipeSlotValidated, disableCraftingCheck) are unchanged, so existing worlds load as before.
• PartVariableDrivenVariableContentsUpdatedEvent no longer hardcodes PartTypes.INTERFACE_CRAFTING as its part type.

PartTypeInterfaceCrafting reduces to a 9-slot part whose extractRecipes returns zero or one recipe. PartTypeInterfaceCraftingList is a 1-slot part over ValueTypes.LIST.

The container and screen are reused for both: the inventory size already travels in the GUI packet, the slot filter now comes from getPartType().getSlotValueType(), and the background texture is derived from the part name. No new menu type, GuiConfig or RegistryEntries holder. The settings GUI's two instanceof PartTypeInterfaceCrafting.State guards are widened to the shared base, so the list variant also gets the crafting-check checkbox.

Guards on list reading

Recipe lists are not necessarily cheap or finite, so extractRecipes follows the guard order used upstream in Operators and TunnelAspectWriteBuilders:

• infinite lists (isInfinite()) are rejected with a slot message;
• the element type must correspond to OBJECT_RECIPE, with a per-element check as well, since CATEGORY_ANY passes the list-level check;
• elements are read with an explicit indexed loop rather than for-each, because ListFactoryIterator swallows per-element EvaluationException and substitutes defaults, which would hide errors instead of surfacing them in the slot;
• the list is materialized once per reload, capped at maxCraftingInterfaceListRecipes (default 256). A Machine Reader's ValueTypeListProxyPositionedRecipes is an uncached positioned view, where each get(i) is a capability lookup plus an Iterables.get;
• duplicates are removed. CraftingNetwork drops a recipe from its index as soon as one removal is requested for it, so the same recipe must never be registered twice from one interface. Not reachable with one recipe per slot; very reachable with a list.

Two related changes to how reloads reach the network:

• update now patches only what actually changed between the old and new recipes of a slot, instead of removing all and re-adding all.
• Reader-backed variables are invalidated on every reader tick (AspectReadBase.update → LazyAspectVariable.invalidate), and each invalidation triggers a reload. With a list that means re-materializing up to 256 recipes several times a second. Reloads of a list slot are therefore throttled to craftingInterfaceListMinReloadInterval (default 20 ticks). This only bounds how often invalidations are acted on; it adds no polling, and the regular interface is unaffected.

Config

Option	Default
interfaceCraftingListBaseConsumption	10	energy per processing job, same as the attuned interface
maxCraftingInterfaceListRecipes	256	0 disables the cap
craftingInterfaceListMinReloadInterval	20	0 reloads on every invalidation

Recipe

Mirrors the attuned interface, with c:gems/diamond in place of the emeralds: two crafting interfaces and a crystalized chorus block in the middle row, diamonds above and below.

Tests

GameTestsItemsCraftList covers crafting the first and the last recipe of a list, re-indexing after the variable card is replaced, duplicate removal, rejection of a non-recipe list, and a Machine Reader-backed lazy list. The last one also covers the invalidation path specifically: it removes the reader's target block and asserts the interface drops its recipes, which can only happen through the variable's invalidation listener. GameTestsAdvancements gets positive and negative tests for the new advancement.

./gradlew build and ./gradlew runGameTestServer both pass (62 game tests). Also verified in a dev client with clientdevbridge-cli: the part renders on a cable, the new one-slot GUI lines up, the existing nine-slot GUI is unchanged, the settings GUI opens with the crafting-check checkbox, and the recipe and advancement resolve in game.

Notes for review

• The two PNGs are placeholder art. part/interface_crafting_list.png is the base interface texture hue-rotated to cyan, and gui/part_interface_crafting_list.png is the existing background with the eight extra slot frames painted out. They are correctly sized and render fine, but they deserve real art before release.
• No CHANGELOG entry: those blocks are generated per release by the ReleaseHelpers scripts, so writing one by hand would need an invented version and timestamp.
• The new entry in root.json's rewards.recipes follows the existing sibling entries, which use integratedcrafting:part_interface_crafting… rather than the recipe ids (integratedcrafting:crafting/…). That looks like a pre-existing mismatch for all three interfaces; I kept the file uniform rather than fixing only the new line.
• A stale recipe set is still possible where a variable never invalidates, for example a Machine Reader whose target gains recipes without the proxy's identity changing. Not addressed here.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Bn8brBLvFiJsfnBHpwf8ZN

---

Generated by Claude Code