Malte Langkabel
488d706bd3
Their buffers were unioned over every recipe of their type, so a single smelter accepted all four ores at once, held three kinds of ingot, and ran whichever recipe happened to be satisfiable. Four recipes coexisted in one building. They now hold exactly one recipe, sized and cleared like any other building's, with one addition: while none is set, the first material offered at an input port that one of their recipes consumes selects it. That hook sits at both intake paths -- the belt pull and the direct coupling -- because a building that accepts nothing would otherwise leave a coupled producer stuck at its port for good. Ports are walked in order and config order breaks a tie, so the choice is deterministic. Once set the recipe never changes on its own, so a material belonging to another of its recipes is simply refused. Changing it is the player's, through the ordinary dialog, which clears the buffers and thereby also frees a building left holding part of a cycle nothing feeds any more; the dialog's clearing option reads (Auto) there, since it returns the building to selecting its own. Falling out of this: gatherCandidateRecipes collapses to getSelectedRecipe, so tickProduction loses its candidate loop; initAutoBuffers and its union are gone; these buildings can now be grey; and AutoProductionContent is deleted, its two reasons for existing (the buffer-chip union and the "recipe it ran last" fallback) having been artefacts of holding no recipe. Also makes them configurable for blueprint purposes -- they carry a recipe now, so a blueprint of one has something to transfer. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ne3mejABZoLWKLh8fgpM3x