Crafting Patterns able to specify (and check/verify) non-item requirements.

[TomeWyrm]

Things such as Essentia, Fluid, Vis, Lumen (ChromatiCraft), EMC... whatever alternate resource you can come up with.

Obviously via API hooks, not native support.

@Mordenkainen was the originator of the idea when discussing some issues with his Equivalent Energistics addon.

Post here: http://forum.feed-the-beast.com/threads/1-7-10-equivalent-energistics-autocrafting-with-emc.95847/page-3#post-1354697

[yueh]

The whole autocrafting system in AE2 is based around items and nothing else. This includes anything from terminals, the crafting cpus, the whole crafting calculation and many other parts. Patterns are just a very small part of it. Changing it simply not feasible without redesigning AE completely (literally designing AE3) and needs native support for any resource type.

AE2 still supports being the base provider for energy, items and basic communication between the gridnodes through the API. But the resource part needs to be build by the addon itself and this includes anything about specific terminals/guis, the whole crafting calculation/handling and other requirements when the provided solution based on items is not enough.
Then adding your own pattern for say EMC as well as storing EMC directly is mostly feasible. Comparable to EC2 and their own terminals/patterns/assemblers.

EC2 has of course as small advantage that fluid support is to some degree available at low level. But this is mostly to make it a bit easier for them and also fluids are part of Forge. Having some generic resource system (comparable to fluids/items) in Forge itself, would make supporting that in AE2 way more likely. But it really needs to cover anything like essentia, vis, lumen and whatever some mod can imagine.

[Mordenkainen]

While I can understand closing this issue, there may be some fairly simple ways to accomplish this.

One suggestion I could make is to add a method to ICraftingProvider to check for "extra" requirements, and call this method during simulation. Something like:
ArrayList<ItemStack> getMissingExtraIngredients(ICraftingPatternDetails pattern, int numItems)

Where "pattern" is the PatternDetails of the item requested, and "numItems" is the number (thus far) requested by the crafting tree.

During simulation the crafting subsystem could call this method and then it becomes the ICraftingProviders responsibility to check the extra stuff required for that pattern and return ItemStack representations of what is missing to the crafting subsystem. Null/Empty ArrayList means nothing is missing. In the case of multiple ICraftProviders for a single pattern, it may be workable to just call one, or call them all and use the one that returns the "smallest" list of missing items.

This way the subsystem needs no visibility into how to check for the extra requirements, but can still display something to the user if they are missing, and can prevent automated jobs from being kicked off and stalling.

It still remains the ICraftingMediums problem to pull those requirements from the network (or wherever). The crafting cluster doesn't need to pull or store the extras.

I think the downside of the "just use the grid and build all your own stuff" idea is that it means that what you build is likely to have issues integrating your custom autocrafting into the normal crafting chain. While not perfect, it would allow leveraging the existing crafting infrastructure for the majority of crafting tasks, even if they use non-item ingredients or other non standard rules.

I understand that changing the interface will cause some issues, but I'm not sure that many people outside of AE itself use it. This might also be worked around by creating a new interface that extends ICraftingProvider and adds this method.