Open Dyonovan opened 2 years ago
I don't have a solution, but I think I understand what's going on here.
Internally (in 1.7.10-3.8.4) the calculator uses a kind of greedy backward chaining algorithm that can generate plans like this:
The plan is perfectly valid, but wastes the user's time a bit - it tells the user to craft a wire twice in two different steps. So as a post-processing step, any steps which craft the same item are merged downward. In this example, steps 2 and 4 are merged into step 4.
(This list is presented in reverse order to the user.)
All well and good. But consider if the user registered a recipe that makes 2 wires at a time instead of 1 wire at a time (e.g. because they are putting an ingot in a lathe). Then requesting a different item might look like this:
There is no step 6 for crafting a wire again, because the extra wire crafted in step 3 can be used in step 5.
Now in our post-processing step we are merging cables (steps 2 and 5 into step 5) instead of wires:
Which the user sees as the nonsensical instruction to make cables before making wires.
If we change the post-processing to merge upward instead of downward, we fix the second scenario but break the first scenario.
I'm not sure what a proper solution is, but I'd guess that Calculator.procedure
in CostList.java
needs some extra annotation to track dependencies between steps, and then maybe the post-processing step can do something resembling a toposort.
https://i.imgur.com/5S3OnSL.png
I have seen this a few times but this is a perfect example. Its asking me to craft 4x Gold Cables before it asks me to craft the gold wire required. If there is any more information I can give or something you need, just let me know.
Version: 1.7.10-3.8.4