Describe the bug

I have two crafting recipes for gunpowder. One uses UU-matter, the other uses Catalyzing Glands. The ME system always seems to prefer to Catalyzing Glands over UU-matter, even when in the same or different interfaces of the same priority. If I am out of Glands the UU-matter recipie is not used.

If I setup a similar set of recipes for other items, alternative recipes are not used when the items for the priority recipe are not available. If I set an interface with a higher priority, and put a recipe in there that's missing prerequisites, the item cannot be crafted as alternative recipes (that have the prerequisites) are not used.

To Reproduce

Setup an ME system, and have two crafting recipes that produce the same item. Whichever recipe is preferred, remove the prerequisites for it from the ME system and ensure there are items to craft the second recipe.

Expected behavior

The autocrafting system would choose the alternative recipe that has items available for crafting.

Additional context

Environment

• Minecraft Version: 1.12.2
• AE2 Version: rv5-stable-11
• Forge Version: 14.23.4.2715

@yueh

Thanks for replying!

I'm a dev as well, though not with Java. At least to me,this sounds like a relatively self-contained problem that could be solved in several ways. I'd like to help work through a couple scenarios if you will read and consider. Please let me know if any of the scenarios or ideas presented sound feasible.

Note: I don't know how AE selects it's recipes, so I'm going into this with some ignorance.

Preface:

It already looks like some recipes get prioritized over others, so I'll start with that assumption. I will also use sticks as the crafting example. And 2 recipes, one from planks, and one from an imaginary item called wood essence, referred to as essence. For these scenarios, lets say planks are the priority recipe, and lets assume we have no way to make planks or essence.

It takes 2 planks to make 4 sticks.
It takes 3 essence to make 3 sticks.

Scenario 1

We have 0 planks, and 1000 essence. This could be logically and automatically solved by falling back to the essence recipe as there is no way to complete the request with the planks recipe, even partially. The 1000 essence is reserved for crafting, and it crafts as expected.

*Scenario 2

We have 100 planks and 1000 essence. The recipe could either be crafted entirely with essence, or partially with planks, or partially with both. Lets avoid crafting partial recipes as that's probably very unsupported. In any scenario where the user is requesting the crafting and it could be completed with more than one material, the user could be prompted to chose a recipe. If the user is not requesting it (ie, export bus with crafting...etc), it would use the recipe with the materials available, and not try and mix and match. If no materials are available it can't craft like normal.

No need to check every craft as the items are reserved for crafting when the crafting starts?

Alternative Idea

Have additional priority logic for recipes. This already exists with recipes through the interfaces priority. Would it be possible to so a simple fallback to a lower priority recipe if the higher priority one cannot be crafted? Ie. there are not enough planks, so we try and use ONLY essence, not try and mix the two and make a cascade of thousands of unnecessary decisions. It would take an extra decision to switch to the other recipe, yes, but that is an expense that only occurs when a second recipe exists.

Please let me know if this is feasible when looking at it from these points. If not, I wouldn't mind a technical reason to mull over. At the very least I would like to participate in a conversation over it.

That is intentional, as it is simply to complex to solve automatically. E.g. in case two items have alternatives should it use UU for the first or the second? Or the other way. And then scale it up to everything having multiple recipes. It would literally have to ask which pattern to choose for every single operation. E.g. crafting 1000 items in total could also require 1000 decisions about which one and then the last one could fail due to materials already being used for earlier ones and no longer available and the user has to start again.

You can't just look at the trivial example, but have to design it for the complex process using a few dozen steps.

In that case you can easily run into the issue that it will detect in the penultimate step, that it's missing a certain material or has already used it somewhere else without any alternative. At that point it has to start backtracking or restart with a certain material and amount being locked. At which point it might run into other missing materials as these are now locked or cannot lock because there could be still other ways being used, so it also needs to keep track about already tried paths. And restart/backtrace constantly.
Which can easily rerun a single job a few hundred times, probably extending each calculation to a few seconds or more. Until it realises in the last step, that it's impossible as there aren't enough materials in any case.

The next point would also be something like considering oredict items. Which will further explode the complexity. E.g. some oredict entries hold a few thousand entries of already complex items, also using other oredict entries like glass. Therefore easily explode into a few million possible permutation, which all have to be evaluated.

There are certainly some approach available to solve it. But that immediately puts it into the space of CSP, SAT or similar. And suddenly each player has to assign a priority for every itemstack/pattern combination as well as other attributes like how fast that pattern would be, do they want to use as few steps as possible, or should it optimize for speed and so on. And these constraints would be different for every player. Some might be fine to use all their silverwood to craft sticks, while others might completely avoid it, and some others would be fine when 1 or 2 logs can be used to craft 4000 items instead of failing.
As well as having jobs easily run for a minute or more to evaluate millions of possible permutations. And every tick during the computation, it might have to restart the whole job, because someone removed a cell with some items or a pattern (or added it).