So I had the brilliant idea of using this mod for a seablock run to produce all 6 base ores within a single facility (that would select which ore to make based on which ores are running low, and set the necessary recipes via this mod), and started running into a bit of a UPS issue when scaling up beyond 600 or so crafting combinators. Since I was hoping to use the same method for the late-game megabase, this is a bit of a downer...

Trying to figure out what was causing this (especially since I made sure to set the recipes only once every couple minutes), I noticed that the combinators tend to pull from their 'overflow' chest at every update (or every 60 ticks based on how often you set that update speed) which is rather nice if you wish to save on inserters and just rely on that pull to insert items into the assembly machines, but since it runs through lua script its quite inefficient. Looking into the cc.lua code I noticed that on every set_recipe update (that is called every 60 ticks or so per cc), you:

1 - check for recipe updates

2 - remove items, clear inserters, clear fluidboxes (only if recipe changed from valid to new valid / null)

3 - move modules & attempt to switch recipe (only if recipe changed to a different recipe, different from 2 since it happens for null current recipe as well).

4 - attempt to insert modules

5 - attempt to insert items

So... is there an option to make #4 and #5 happen only if the recipe has changed? It does mark a change in how the mod operates in that newly inserted modules / items into the chests will not be moved into the assembly machine unless the recipe changes (and only then), so the player would have to have a manual inserter going from the overflow item chest to the assembly machine if they are using the overflow chest as the 'ingredient storage' chest, but this change has huge impact on UPS for the periods of time when the recipe isnt changing - which is realistically most of the time. Maybe include a checkbox to allow for either option (constant insertion vs insertion only during recipe change)?

On a test map of 500 crafting combinators (set up to barrel water recipe) and 60 cc refresh rate I could get 600 ups with the base mod, but could get 1500 ups just by moving #4 and #5 into the #3 check (attempt to move items and modules ONLY when the recipe changes). Even if I set it up to switch between no-recipe to water barreling every second I had 450 ups with base mod vs 750-800 with the aforementioned changes.

And finally on the actual factory map (2.6k crafting combinators, and enough entities to actually factory) I have the UPS at 100 with frequent drops to 85 (averaging around 90ish) with the base mod, and a steady UPS of 110 with the aforementioned changes.

I don't think I intended the combinators to pull from the chest on every update like that... Thinking about it, there might be cases where the overflow items don't fit in the assembler's input slots - you'd want to try inserting again once it uses them up when that happens. I wouldn't feel too bad about that particular case being broken tho.

With that said, it should be quite simple to just add an option to toggle it on or off as you please, so i might look into that instead. There might also be ways to speed up the actual inserting process, which would certainly help too.

It's cool to see the mod used on such a large scale tho - i mostly considered it a fun toy to play around with on a couple assemblers :D

In my K2+SE I had mall automated using crafting combinators, also using around 300 units. It would've easily went to over 1000 combinators but i notices UPS drop (20% across all 120 mods I was using was used by CC) and had to limit how I use them. I eventually also forked CC locally and poked around for some bottlenecks, but my understanding of API was not sufficient enough.

Anyway, I am also UPS bound by how I could use this mod. I would use it everywhere if I could. For instance you can have a bunch of assembles inside Factorissimo factory all feeding from isolated logistics network, then I would break down an item into ingredients and feed those to request chests while setting recepie for all assemblers (easily 200-300 units per large factorissimo factory). Since you can pass signals from outside factories to inside, what you do is then copy@paste these factories, feed them ingredients from bus and set item as a signal from outside the factory. You get insta 300 assembler line that can produce anything out of any number of ingredients. If used this way, i would have as many CC as I have assemblers (tens of thousands). However I would only need one-time (or very infrequent) writing of recipe to be UPS efficient, the rest of functionality can be sacrificed.

Btw, now with teleporting chests supported natively, you can dump overflow from recipe changes into invisible teleporting chest which could be bound to a storage chest within logistics network.