Forge Version: forge-1.10.2-12.18.2.2110
AE Version: 30a978b

Seems like Ore-Dict is not taken into account when using pattern auto-crafting while having it toggled on in the pattern terminal on creation, Images describe this better:

I tried both, with and without ore-dict substitution on.

EDIT: This is on processing mode, not crafting mode, haven't tested actual ""crafting"" with oredict yet, however Ore-Dict sub. should work in processing too, I assume and hope

I am not sure that it'd actually mix/match for one crafting job. Have you tried this without any "normal" sand being in the system to see what it says? If it comes back as available: 0, then it's probably a bug. If it comes back with the same result, it used the red sand.

Yes, currently not possible as using ore dict for processing patterns is really problematic. We can validate that crafting pattern are still valid and produce the correct item. Which on the other hand is not possible for processing. While your case is one of the working ones, there can already be issues with using something like a saw mill and getting spruce planks as return when actually needing oak planks.

For now we should disable the button to avoid confusion, as well as remove it from the tooltips.
As no as the autocrafting does not support ore dict entries as output, there is no reliable way to allow it. However adding ore dict support will be a massive performance issue or ridiculuously complex (most likely both)

You are never supposed to use ore-dict for output.
But Ore-Dict ingredients yes.
I can't see an issue with selecting Ore-dict matching processsing ingredient to export into the destination interface.
Now the way current patterns are encoded is a problem.
It stores ITEM numeric ID and Damage.
Ore-Dictionary enabled patterns should store the Ore-Dictionary name instead.
When an Item has multiple ore-dictionary entries, the pattern encoder shall allow selection of a specific ore-dictionary entry rather than the first encountered one.

Changing the way they store items does not fix anything. All it does is breaking existing behaviour and no longer allow you to place them back into the terminal, let it populate the grid and easily update them. Like switching to subsitutions or not.

@leagris You are never supposed to use ore-dict for output.
But Ore-Dict ingredients yes.

I used it as Ingredient. (Unless you talked to someone else)

@shartte I am not sure that it'd actually mix/match for one crafting job. Have you tried this without any "normal" sand being in the system to see what it says?

I'll try that

@yueh there can already be issues with using something like a saw mill and getting spruce planks

But wouldn't it be a orePlank (or similar) then and can be ore-dict substituted again ? But there is probably no check for that and that are you meaning by "a massive performance issue" when adding it right?

@yueh Yeah but now I am confused, if the processing recipe is usable with ore-dicted input (only the player knows), shouldn't we allow it?
This is about ore-dict selection on the input side btw., not output. As in, he has a recipe for sand->glass, oredict enabled, and expects the system to utilize any sand items that satisfy the oredict for sand. I think this should work at least for full jobs.

@shartte I am not sure that it'd actually mix/match for one crafting job. Have you tried this without any "normal" sand being in the system to see what it says?

I tried that now, doesn't use the Red Sand as Ingredient when I removed all the normal sand.

EDIT: obv same commit as originally, since he removed the button later on.

@shartte Yes, this is one of the few cases where different item -> identical items works. But say you have a sawmill pattern for oak logs -> oak planks and set it to allow oredict entries. Absolutely no machine will then turn spruce logs into oak planks. But oak planks are the requirement that the network can detect them being crafted. So to solve it, we have to add full ore dict support for the output to consider spruce planks being a replacement for oak planks. Until the next recipe in the chain still only works with oak planks and we now have a nice deadlock.

As said, we can validate normal crafting patterns to be a valid recipe and return the required output. But that is simply not the case for processing patterns at all. There are currently already some issues with machines returning a different itemstack then defined. But that is way less common compared to once we enable ore dict support for processing patterns. Absolutely noone will understand why spruce planks suddenly no longer work.