MeduSalem wrote:My other concern is that without being able to specify an inserter stacksize via circuit signal as well it probably would be very much of a problem to switch recipes because of the residuals.
The "residual" problem needs to be solved comprehensively, or else a lot of solutions will always be very convoluted. Maybe the inserters should be able to put leftovers back, that would always work unless the item source is filling too quickly (that would be rather easily avoided).
If the filter signal would also set the stack size (i.e. the precise count of items that are picked up), that should be sufficient for feeding programmable assemblers. But there are still scenarios where it would simply be a lot better if the inserters could return the "residuals" to the item source.
I think we are probably needing both... Filter Signal setting the Stacksize for Inserters... and if it's only to deal better with smart train loading. Because a stuck inserter is really bad for that setup and not being able to top off the slots is also inefficient.
... and a way to deal with the residuals, though an automatic way would be preferable.
I had a lot of time to think about the residual item problem ever since the idea of setting recipes with a circuit signal first came up and I actually think that removing the residuals with an inserter is ... urgh. It would make things rather a complicated mess... and quite inefficient because you have to move items more than once (in and back out and back in).
I mean I probably could live with having to remove the residuals first, but it would be highly inefficient because it would take a lot of time to remove all the crap from the assembler/furnace and then restock with the correct ones. So that's why I'm saying that once an item is inside the assembler/furnace it should be left inside to reduce uneccessary overhead.
I think the best approach would be to have some limited buffer slots (like 6-10 slots, and each of the 6-10 slots can be filled with another resource) within the assembler which the assembler can work with. If you set a recipe with a signal the assembler checks if the required resources are inside the buffer and if so starts crafting, if not it will wait until the buffer has the items. That wouldn't require you to remove any residuals from the assembler - they would stay in the buffer until you resume the other recipe again.
While the Assembler is working on a particular recipe you get even time to refill the buffer slots with resources (even ones the current recipe doesn't need) so that when you switch recipes the inserters don't have to start filling from scratch and instead the Assembler/Furnace can start to work immediately.
The amount of buffer slots would be obviously up for balancing and could be increased with research. The current items in the buffer slots could be an output signal from the assembler to the circuit network so you get feedback on what's currently in the buffer and adjust accordingly, though I imagine that being difficult to implement because that probably results in a feedback loop where the assembler can't differentiate between it's own buffer slot signal and the signal that sets the recipe.
With that approach one could build a smart assembler/furnace without having to worry about removing residuals first...
... and it would also satisfy Dave a little bit because then there's recipe switching but it can't be used to switch recipes universally... since you only have limited buffer slots the assembler can work with, so the recipes would have to have pretty similar resource requirements.