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

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:

1. user requests A, which requires a wire and a cable
2. craft a wire for the sake of A
3. craft a cable for the sake of A, but that requires another wire
4. craft a wire for the sake of the cable

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.

1. make 1 A
2. -- deleted --
3. make 1 cable
4. make 2 wires

(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:

1. user requests B, which requires a cable and some item C
2. craft a cable for the sake of B
3. craft 2 wires - one for the cable, and the other kept "in stock"
4. craft C for the sake of B, which requires another cable
5. craft a cable for the sake of C

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:

1. make 1 B
2. -- deleted --
3. make 2 wires
4. make 1 C
5. make 2 cables

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.