Incorrect crafting results from Vanilla recipes when using FastWorkBench
alcatrazEscapee opened this issue ยท 4 comments
Observe the following setup (Crafting firework stars, with two gunpowder, two dye, and one diamond placed in the crafting grid):
In vanilla, if you were to take these items out one by one, you receive one "Firework Star - Small Ball, Blue" and one "Firework Star - Small Ball, Blue, Trail". Alternatively if you shift+click these items out, you get the same result: two different items. See below:
However with FastWorkBench installed, if you shift click this, you get a different result: Two "Firework Star - Small Ball, Blue, Trail"s. You've effectively used one diamond for two recipes.
Mods
- Fast Workbench 1.19.2-7.0.0
- Placebo 1.19.2-7.0.0
Why
Fast Workbench makes the incorrect assumption that a recipe's results are independent of the crafting grid. As such, it never updates the result item and just blindly trusts the last result. This is incorrect, as seen here in vanilla, at least for recipes that have isSpecial()
marked.
I encountered this in a conflict with one of my mods in 1.18.2, where we have a recipe that has a similar property - adjusting the count of the output based on the crafting inputs. Which then led to a duplication glitch.
FastWorkbench does not make that assumption and has explicit code for updating special recipes here https://github.com/Shadows-of-Fire/FastWorkbench/blob/1.18/src/main/java/shadows/fastbench/util/FastBenchUtil.java#L49
The question is then "why isnt it working", because this code was introduced to fix this exact issue, which it did fix at the time of implementation
From the looks of it, you never call it during the operative loop while creating outputs. craftMatrix.checkChanges = false;
is set at the beginning of the loop, which presumably prevents any calls during said loop, and it's only invoked once at the end of the while loop.
FastWorkbench/src/main/java/shadows/fastbench/util/FastBenchUtil.java
Lines 85 to 104 in 0db4666
That does appear to be the case. Fix should be a simple insertion of the earlier logic into this loop. I'm wondering how nobody has run into this yet.