I did try searching open/closed issues to see if this is a dupe but I couldn't find it. Apologies if this is a dupe.

Description

2 sets of 8 interfaces in line with each other with 4 molecular assemblers each, one on each available side.
(total of 16 interfaces, and 64 molecular assemblers)
Made all the patterns for making a 16384K storage component, 8 patterns, all on same tower, in separate interfaces of tower.
crafting cpu's have 4x64k crafting storage, 4xcrafting co-procs and a crafting monitor.
I made one additional one that has 16 coprocs and 10 64k's to test this and used it in following test.

decided making the 1k storage components were the holdout that took the longest to make so added 3 duplicate patterns for making the 1k in the other tower not in use already

set to auto craft the 16meg storage component and used the crafting cpu that had 16 coproc but it never touched the three patterns in the other tower, but instead made them using the first recipe in the other tower.

Expected it to find the other three patterns and use 4 interface/assemblers to craft the 1k's during the autocrafting process.

Environment

SSP
AE2 stuff and extracells also in pack.
ae2stuff-0.7.0.4-mc1.12.2
ExtraCells-1.12.2-2.5.11a48

• Minecraft Version: 1.12.2
• AE2 Version: appliedenergistics2-rv5-stable-8
• Forge Version: 14.23.2.2618

Ye, you cannot have multiple recipes for one item, it just don't work like that. It would be nice to have something like that tho :)

so I guess you're limited then by how many multiples of an item you can craft at once then since you have only so many faces to an interface. or multiple systems I guess, storage bus'ing to making just those items and some slave systems that only make that one item, etc...
will have to think about that then. but yeah, assumed this would work, can't say I ever tried this before and I'm somewhat consistent everytime I make an AE room. always the same size/proportions/general layout.

As long as the patterns are exact duplicates, it will use them to distribute the crafting tasks across multiple interfaces. Except for the case that they are faster than the tasks are pushed, in that case it will simply start with the first one again.

setting blocking mode on the interfaces may be helping to parallel as much as possible, even with small number but with the lag of inserting items after finishing the product

@yueh call me idiot on this if i understand it wrong, but even with multiple interfaces and exact same recipes, the crafting will start pumping into the inputbuffer of only one machine first and then trying to use other interfaces/machines after the first one is stuffed?

maybe some sort of round robin fashion in distributing the single craft requests over the interfaces may be an option or maybe as a button while creating the pattern?!

or upgrade card

Round robin is simply not feasible. Crafting is not done in a single tick, so machines/patterns/etc can change during a whole job. Simply too many variables, which can break at any point.

Your best option is a better blocking mode. But for that you have to talk to lex about adding something like TileEntity#isWorking() to forge or a similar cap (maybe with some more information). So we do not have to support every mod out there with a custom solution.

Round robin is simply not feasible

this you'd have to explain a bit more clearly to me, i mean, when you start a production step, your algorithm needs to find all available interfaces that contain the recipe in question and feed it with items
(transition from queued to crafting in the autocrafting monitor)

I bet it is currently done as a search for the first available interface that contains the recipe that is then stuffed with one item and another seaerchign round starts?!

wouldn't it reduce overhead to search for all recipe-interfaces first and keep them in a cache list that needs proper updating when one of the interfaces/recipes goes offline and THEN only round robin over those recipes to feed em?

nah but this also means you were not able to see newly attached recipes

Mostly correct. But the list is also sorted by priorities. And regardless of round robin or not, an interface with a higher priority should always be prefered over anything else, if the attached machines are not busy. So it would be some strange pattern like using the highest set first, filling them in roundrobin and then switch to the next set, but only after checking if the previous set is not already finished. Or distribute it 50% to the ridiculuous slow machines and the other 50% to the fast ones, which are 10 times faster.

Round robin and priorities simply to not work together that easily.
A better blocking mode is simply way better than anything else. It would automatically distribute it nearly perfect. E.g. by design prefer the faster machines, still respect priorities and so on.
But simply not possible as long as forge does not want it.

higher priority should always be prefered over anything else ... So it would be some strange pattern like using the highest set first

okay i see it, but i may have an idea on how to solve it, but this would mean a bit more list in list stuff

make a dictionary of lists, where the keys are all prio levels and every key has a list of interfaces witht he same prio level sorted after RR-enabled and also EVERY KEY has an index-attribute showing to the last successfully served entry in it's list (needs to be adjusted accordingly to attached and removed interfaces/recipes)

so for every item to push i decend from high to low prio, trying to access the RR enabled interfaces first by accessing the "last successfully served" and checking if it is RR-enabled and returning to the top of the list if not (either no RR-enabled present on this prio or all busy)

if the interface IS RR-enabled, i check if the next one is RR-enabled and try to push if it is enabled or return to the top of the list and try to push there (we reached the end of our RR list, begin from top)

if i don't find ANY RR-enabled that i can push into, i try the next RR-disabled until i find none of them either and drop to a lower priority

or you could simply ignore priority if there is two or more duplicate patterns for one recipe of requested item, and then apply RR

And then it also has to be synchronised across all crafting CPUs and what not. It is simply not worth the trouble to consider round robin at any point. It does not solve the underlying issue at all, e.g. it can still not reliably distribute it over all interfaces. It introduces all sorts of sync issues, like distributing a single task/pattern across multiple machines and completely stalling it.

Basically roundrobin is a poor man's solution for an already existing solution, which is better and less error prone. But Forge is reluctant to add it. Which would not even benefit AE2, but also other mods like BC robots or anything else trying to detect, if a machine is doing something.

when I ran my test (and I did it again with 2 crafts queued) the second tower stayed dormant completely and I recreated the 4 patterns just to ensure they were identical.

But as you are saying, if tasks are pushed out fast enough, I can see why that was the case. all assemblers are maxxed with acceleration cards and it is going pretty damn fast. I was just trying to really push it with the no-wait scenario hehe

the only other pet peeve I've ever had with ae is things across my network with a crafting card and they always somehow grab my biggest sized crafting cpu to make a group of things lol. but yeah, I couldn't live w/o this mod. Thanks for all the ocd :)

your best bet is to use same sized CPUs all over the place to have a predictable behaviour, either you get your job done in the size you wnat or not because there is no free CPU at all

i always hate it when i have to cut my orders in slices because the biggest CPUs are used up by some autocrafting stuff ... i also started to subnetwork production lines with their own dedicated crafting environment and only stockpile the intermediate products as much as possible (except those needed in big quantities)

well yeah generally you are right ... no need for another level ...
i was concerned that one might setup machines in a fashion where 3 machines run iron only, where another machine runs iron + copper because he rarely uses copper at all ... and then the copper production might get jammed, but then he could utilize priority levels

3 machines to 100, the copper + iron one on 99 and so on ... and to be honest, i have never seens ANYBODY using prioritys on interfaces yet so far in my minecraft life, so this would really be an oppertunity