Let the Attuned Crafting Interface enable and disable individual recipes

[rubensworks]

Closes #162, Closes #219

The Attuned Crafting Interface exposes every recipe of its target machine, with no way to leave any of them out. Pointing one at a crafting table hands the network thousands of recipes, and a crafting job may pick one the player never wanted automated.

This gives the part a gui of its own that shows all recipes of its target as a grid of output icons, 9 × 6 = 54 at a time, with a green or red border per recipe. Clicking a cell toggles it; hovering shows the output's tooltip, the recipe id and the inputs it requires. Enable, Disable and Invert apply to whatever the search field currently matches, which is what makes a machine with thousands of recipes workable (search minecraft: → Disable). The settings gui, which used to be the part's main gui, moved behind a button. Nothing was added to the normal crafting interface, whose recipes are hand-picked already.

The grid

Modelled on how Integrated Terminals shows crafting options. Vanilla slot metrics (18px pitch, 16px content) mean the grid lines up with the player inventory below it, so the gui grows by only one row of height over the plain list it replaces. Per cell: the output icon with its count, a white highlight under the mouse, and a green or red state border inset by a pixel so the slot's own grey bevel stays visible around it. The border draws before the output, so it never cuts through the icon or its stack count. Disabled cells additionally get a grey overlay in front of the output, since covering it is the point of that one.

The name no longer fits beside the icon, so it moves into the tooltip. Search already matches name, mod id and recipe id, which is how you find a specific recipe.

The hover tooltip

Inputs are shown as a grid of ingredient icons rather than a list of lines. Inputs differing only in quantity are merged and their quantities summed — a recipe taking five planks is one slot showing five, not five slots showing one — and inputs accepting alternatives (tags) cycle through them. This mirrors IntegratedTerminals' crafting-option tooltip; its implementation sits behind an IT-only capability, so the two small classes are reimplemented here against ItemStacks directly. Inputs are resolved only for the recipe actually under the mouse, since doing it for every shown recipe every frame would be far too slow.

The bulk action buttons carry tooltips too. Their labels are one word because three buttons that fit "Disable all" comfortably need more than the 162px the grid is wide — "Disable all" measured 51px inside a 52px button — so what they act on is stated in the tooltip, where it can also be said accurately: they apply to whatever the search matches, not to literally everything.

How disabled recipes are stored

A blacklist of recipe keys on the part state: an interface with nothing disabled costs no extra NBT, a pack update that adds recipes does not silently disable them, and no migration is needed.

A RecipeKey is the recipe id where IRecipeDefinition#getRecipeId gives one, and the full structural serialization otherwise. Keys are never resolved back into recipes for storage, since RecipeDefinition#fromRecipeId throws once a recipe is gone — an unresolvable key has to stay opaque so a pack update cannot silently re-enable something the player disabled.

Keeping the network's recipe index honest

getRecipes() now returns the filtered list and getAllRecipes() the full one. Every toggle updates the filtered list and then tells the network about exactly the recipes that changed, through add/removeCraftingInterfaceRecipe.

This matters because CraftingNetwork#removeCraftingInterface unregisters an interface by iterating over getRecipes(). Had that set ever changed without the network being told, the disabled recipes would have leaked into the recipe index permanently. GameTestsAttunedRecipes#testAttunedDisabledRecipeDoesNotLeakOnUnregister covers that invariant by moving an interface with a disabled recipe to another crafting channel and asserting the channel-independent index matches what the interface exposes.

Client sync and toggling

Recipes reach the client through the gui data buffer at open time. Recipes backed by a built-in recipe are sent by id and resolved from the client's own recipe manager, so a crafting table costs tens of kilobytes rather than a full structural dump; only machine-specific recipes, of which there are tens rather than thousands, are transferred structurally.

Sorting by localized output name happens client-side so the order follows the client's language, tiebroken on the recipe id for a stable order across sessions. Because the client's order therefore does not match the server's, toggles are keyed by RecipeKey rather than by grid position — which also keeps the gui correct if the server re-reads its recipes while it is open. Bulk actions send the server-side indexes of the filtered recipes plus a version of the recipe list, and the server ignores them if it re-read its recipes in the meantime. Both payloads carry a sequence number, without which ContainerExtended#setValue would swallow a repeated identical toggle (disable X → enable all → disable X).

A CyclopsCore bug this ran into

ContainerScreenScrolling computes the scrollbar's total rows with filteredCount / columns — integer division. Measured on this grid with 985 recipes: that gives 109 rows instead of 110, and scrolling fully to the bottom leaves recipes 981–984 unreachable. Rounded up locally here until a CyclopsCore release carries the fix; upstream PR: CyclopsMC/CyclopsCore#236.

Dependency bump

CommonCapabilities 2.9.12 → 2.11.5. Recipe ids on IRecipeDefinition arrived in 2.11.4; without them every key would have to be a full structural dump, which neither fits in the part NBT nor in the gui data packet at this scale.

Testing

• ./gradlew test — unit tests for RecipeKey round-trips (id form, structural form, and the missing-recipe case) and for sort-comparator tiebreak stability.
• ./gradlew runGameTestServer — all 56 pass, including 7 new ones:
  • the index shrinks on disable and grows back on enable;
  • the job planner stops selecting a disabled recipe;
  • no recipe leaks into the index when the interface unregisters;
  • disabled keys persist across a state save/load, including keys of recipes that no longer exist;
  • a disabled recipe is not crafted while an enabled one still is;
  • every recipe survives the trip through the gui data buffer, with its disabled state, its searchable strings and its server index, and the grid fills every cell;
  • the gui's value-notifier payloads apply server-side — single toggles, all three bulk actions, a repeated identical toggle, and the two cases the server refuses (stale recipe-list version, out-of-range indexes).
• The gui was driven in a dev client with clientdevbridge-cli: opening it on a crafting table (985 recipes), toggling cells, the hover tooltips, searching, all three bulk actions scoped to the filter, scrolling to the last partial row (985 % 9 = 4 cells, all reachable), the settings round-trip, and re-opening to confirm each change reached the server.

The screen class stays untested, as every other screen in this repo is.

🤖 Generated with Claude Code

https://claude.ai/code/session_01T9xTc8kXNRDppvXktL24aR