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 lists all recipes of its target, with the output icon and name of each. Clicking a row toggles it; Enable all, Disable all and Invert apply to whatever the search field currently matches, which is what makes a machine with thousands of recipes workable (search minecraft: → disable all). 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.

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

Search matches the output name, the mod id and the recipe id, against lowercase strings precomputed once at gui open.

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;
  • 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 itself was driven in a dev client with clientdevbridge-cli: opening it on a crafting table, toggling rows, searching, all three bulk actions scoped to the filter, scrolling, 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