Chemistry Set: match recipe ingredients by count - #148
Conversation
Recipes with duplicate ingredients required each copy to sit in its own slot, and vanilla shift-click always merges into an existing stack instead, so the layout for web, fractured bones or the lengthening catalyst could not be produced by shift-clicking or by any kind of item pipe. Ingredients are now counted across the input slots, so a single stack of five string works just as well as five slots holding one each. Matching also accepted any superset of a recipe, leaving unrelated items in the slots unconsumed and making the outcome depend on the registration order. Every non-empty slot now has to be part of the recipe. Consumption used its own comparison rules that had drifted from the matching ones and could decrement a different slot than the one that was matched. Both now come from a single pass that returns the per-slot amounts.
koolkrafter5
added
the
Enhancement
|
I'm not sure how much I like this. Needing to put items in each slot is part of the design of the block (at least I believe so). The Ballad of Alchemy already exists for automation and is native to BM, and there are other options such as crafting full stacks at a time, renaming items, or enabling the "Insert to Empty Slots Only" mode when using AE2. It not working instantly with shift-clicking is also fine imo because it either promotes crafting a large batch (you can always shift in a stack of each ingredient) or using some method of automation. After testing it, it also just doesn't seem to work for some recipes with empty slots, such as weak binding agent: Requiring empty slots to be empty will also cause problems for most types of pipe as they will try to fill as many slots as possible. I understand wanting to prevent conflicts, but that seems to go against the point of your changes. |
|
This also doesn't really solve the issue of recipe conflicts. Consider the following two recipes: Which output would you expect with the following input? |
|
You are right on all three counts, thanks for testing it properly. The empty slot failure is a bug in my assignment pass. Ingredients are assigned greedily to the first slot that still has items left, so both catalysts come out of the first slot and the later slot holding the rest is never touched, which then fails the "every non-empty slot must be part of the recipe" check. Getting that right needs a real assignment search rather than a single greedy pass. The pipe argument settles the coverage rule for me. Any pipe or AE2 in its default mode fills every slot, and the rule turns that into a permanent stall, which is worse than the conflicts it was meant to prevent. Counting also does not resolve conflicts, it adds a new class of them: [A, A, B] and [A, B] become indistinguishable for an input of two A and one B, and the winner is whichever was registered first. Slot positions used to separate those. Given that, and that the per-slot layout is intended design with Ballad of Alchemy and the AE2 insertion mode covering automation, I am closing this. One part of the diff does not touch matching rules at all, so I will open it separately as a performance PR. updateEntity currently walks the whole recipe list several times per tick, since isRecipeValid, getAmountNeeded and the output merging branch each call the lookup again, and every comparison allocates a padded copy of the recipe. Looking the recipe up once per tick and normalising the recipe array in the constructor keeps behaviour identical. |
2 participants
Summary
Recipes with duplicate ingredients required each copy to sit in its own slot, and vanilla shift-click always merges into an existing stack instead, so the layout for web, fractured bones or the lengthening catalyst could not be produced by shift-clicking or by any kind of item pipe. Ingredients are now counted across the input slots, so a single stack of five string works just as well as five slots holding one each.
Matching also accepted any superset of a recipe, leaving unrelated items in the slots unconsumed and making the outcome depend on the registration order. Every non-empty slot now has to be part of the recipe.
Consumption used its own comparison rules that had drifted from the matching ones and could decrement a different slot than the one that was matched. Both now come from a single pass that returns the per-slot amounts, which also fixes a stack of two container items collapsing into one empty container.
The one-item-per-slot layout keeps working, so existing setups stay valid.
Checklist