Infrequent use, exact output, bot auto-mall help

[PrK]

While I was playing through Py I got the urge to make a setup (that will work for vanilla too ofc) that fulfils specific conditions to make items I don't want to have a constant supply of (mainly buildings, which for Py are many, usually needed in low quantities and need big amounts and number of items to be crafted).
These conditions are:

• Be able to set the desired items to be made easily, via a logistic group from my inventory.

• The assembler to make the exact number of requested items and not more, similarly the requester chest to request just the needed amount of items (mk01 bots are so slow..)

• The inserter to input the exact amount of required items, not buffering anything so no time is wasted and no items would have to be emptied when the recipe changes.

• The ability to make any required intermediate items missing from logistical storage (in my case that's mainly other buildings, which so far don't seem to need any fluid, so that’s off scope atm).

After experimenting and combing through many threads here for information, I was able to make a sorta kinda functioning setup, detailed below. However, my circuit knowledge is lacking to say the least and would appreciate any help in figuring out how to improve or fix it in case of unforeseen complications. (For example the signal contamination due to the assemblers was a big problem that I could only solve by placing an additional dummy one).

The basic setup:

f1.jpg (129.86 KiB) Viewed 301 times

Beginning with a constant combinator with the logistic group I use to set the required items.

f2.jpg (74.52 KiB) Viewed 301 times

Then the signal has to be split because of complications setting the recipe in the case of multiple requested items so I put it through a number of different selector combinators with increasing indexes, corresponding to each chain of assemblers.

f3.jpg (84.98 KiB) Viewed 301 times

Now that each assembler has only one signal to be assigned to it, that signal first gets compared via a decider combinator with the amount of items in the output chest, as well as the logistic network, so the recipe clears when the desired amount is crafted.

f4.jpg (117.32 KiB) Viewed 301 times

Two different combinators are needed to set the recipe to both the producing and the dummy assembler. Since you can't multiply each*each when they are different signals, I found out I have to first convert the signal to another virtual one, so an arithmetic combinator does that to get the number of requested items,

f5.jpg (102.57 KiB) Viewed 301 times

and then to set the number of items for the requester chest a decider is multiplying the ingredients – which it gets from the dummy assembler – with that number.

f6.jpg (155.7 KiB) Viewed 301 times

Independently, an arithmetic combinator subtracts the number of items in the crafting assembler (set to read contents+in crafting) from the required ingredients (which it gets from the dummy assembler)

f7.jpg (99.07 KiB) Viewed 301 times

and sends it to a selector combinator that passes along just one of those signals both to the input inserter to set the filters

f8.jpg (124.12 KiB) Viewed 301 times

and to an arithmetic combinator that converts that signal to the virtual S that the inserter needs to set the stack size.

f9.jpg (77.48 KiB) Viewed 301 times

Another decider checks for missing intermediates, outputting to another selector followed by another setup like the previous one, repeated x times.

f10.jpg (106.53 KiB) Viewed 301 times

Blueprint for a single, main part (I changed the inserter already, only the roboport should need to be replaced for vanilla):

0eNrtWktv4zYQ/iuCji0VmJTkRw697KHoucfFQqAl2iaiV0kqqRv4v3dI6mWHcixvs9uiCwQJRc0MZ4bfDGeovPrbvGG14KXyH199nlal9B8/v/qS70ua67mSFsx/9KmUrNjmvNwHBU0PvGQB8U/I52XG/vQf8Qm5mARXh4IpngZpVWx5SVUlRlzEyZWxlGdMuFlCJ4tkOUuB0M0Tnb4gn5WKK86seebhmJRNsWUCtEfXBCG/riTwVqVeEeQFeIn8I7A9xLBIxgWwmLcR8sGDSlR5smUH+syBG1iqmglqKdoFQKYdJAUFgUo0rNU20VugqN4P8I5f5/TIRJIxmQpetzJCkXmdosjjssqpYtKrSuZZzzz42ksXRpLeyG6J60aGi4fYmBkaM12GSWs4+LRs8nxK3U/ASXkpPXVgXl7tuQRAeHtRNbVT0bBXtGAZb4rAmCoARHWVM4emZD3S1CEwmisQb64LjOfiZWWkkY/FC57aAFLeg5flYGRB8zzIaVFfc37k9tVqpq+I9VX8sb5aTPkKS3WHr9boSvJy2BjOsrGVqdXPeBtwr/74CVLajgupkiEzqmOt9XnmQjUwM+yCoQgYJHGdIiGEQc58vvFyScnUSyWejFqCZZ3T94IxsGpHc8kul3rLY8h6Ji3hpPN21ai6UZen0o1a3rbIaTJzHVj6JD2+M6lLsD8aJhXLPK5YIT0qmFdwKeFM9HaiKs7zW7s08loDPFV57SHKhH6QTLViU14zJ6w2t4Vgn64mQhAvBnhyqS0Nalqy3Bl9rajlZNKvqQBZigm7Jz0M9buZIKTlUUEpsfftUl1s6odCL6Oj59H/xRzlqV3hZomwrcin+Qs9ykQeqpd2tx3ewXcF7/JH8P4I3mvBi4eCy10HO6C1bKNvcw6ttRtag9gLdH0jOFlLA/2k2cdH8U9+t/n/VnROweZXpmSPGNgCAEwJjBmH7ZUDVLKmKI4DJpBXNLnidQ4dhrc9GhLrHq/aXYLvDFbdO+GlB/jrhlI4H0oWSOvLLKVR+Q2xdJbVxwD5+Q6AnOHtdKXdeGai3UTL6Ukdvtrb+zZuJ/fG7f+hg6iPgai2VV0JFRRPC+w6jqOHsfPbBZIdz+2hOe6bIC/2HfQX59kdz+6GuiMcLybKgRsre9xV9hhPCFrNbqzW7+k2VNLOG4crOROTK32qSmym7vKHYDRLRoHdZQWHRpvZGoV3a6RJB3XaSUsH+Cm5PAwp8GL69jBK9cFoAujtHcFQKfZ5KTB5yWVnd0GAp28IUi7ShkMrVmUsqXbJKAVA2dW97TNOwkoK6TQbMrsjepSg8pCUlfZgG7uDT1pqSNPJttntDMvU1pKh8ttRqQJeSkgczJlO8bmt79d9nW16p3vlrZbjV5Ad0yfYu79YV6D6jWTnHC7Vh+LCmnnDLpF3d2lyH1wahHc4j7w9jlyioxuvHvpMF7uzCfmK5DnRS5HZyXNKt69InlO6re+vOPHy9N8tDH6fWQ7sKmEeO8x2FT0HssB7BpM1+mFootPT0em+Ut3MvdyK3nP3P32f9dvbG6yhGuq6GJtt3rjFfTu7mA8y3Nr8nYvR2XzjzQj+sx3NJ5qnjQWB7WsKCjUD9L0lY9llf9NC4KzZ1bcxOVPMYCgVdOfuUsLZFyldMNzW7v64Sfm+NykaG92VCYc6VehzS8MKOdFAZp+9XZlAJvqNMJybbuNOYngTwj7iw8vYU3d8WQije48YQj7S5qsfUL7W5vj2++qwt/Z/c2Ed3vplDo994xI0+9tcVy2S6COxdfXD9yxsQeJ8AS31xn/GiKAYkS/oM4FRaEbwG0X9aNWOYpiLYRT1HPCM8MpMruDl2kzqEV6Y4RphhOGnG67aIdGzlgBoLZumQ9C/YTsOEQ67MdBsLA3RUtZ2XqsLNJEdg1KLjiZCoRWPo2FVHA/KmjF0QWa80uu2NCs939JojaGqM/Mb7Rornxg91yjsxxs71nJCa6wWgSDTazlEmws0Wk/4Y2Rq+lDbFbZe1m4+G7c+jzSN9jXsmL6H031t/58pyM/pFsIfKs5GVYHGPMxBVS8NLOIl2USbTbwihEQLfDr9Dccy53k=

Copy blueprint
A full setup capable of handling 5 simultaneous requests each with 5 simultaneous intermediates (that are shared among themselves) would probably look something like this:

f11.jpg (399.48 KiB) Viewed 301 times

Issues that I would like to amend:

• Distribution of signals to assemblers, is there a better way than the selector combinators, accounting for the fact that requested items could be added to the group before the previous ones are completed (and I’ve found that sometimes changes the order the selector picks the signals, resulting in flushed crafts)?

• Adding on to that, it is even more problematic for the next, missing intermediate stage, the signals sometimes flicker frequently, especially if the requested item and its missing intermediate share a missing ingredient, making some crafts impossible to complete. It's probably contamination from an assembler but can't figure out a fix. That's the most pressing issue atm.

• When more than one of each item is requested, what would be a good way to reduce the requested ingredients as items are crafted so as to save pointless bot back and forths? How would that look like in the intermediate stage as well, considering the finished items would immediately be transferred to the requester chest of the main item?

• The input inserter so far in testing is working great, but are there any unforeseen cases that could make it get stuck holding an item?

• On the other hand the inserter atm is assigned one filter at a time, changing only when it has inserted the full amount of an ingredient, that however wastes time (very apparent if the bots bring the items the current filter has last). Putting the preceding combinator in random input mode technically works but has some weird behaviour with constant changing filters, the stack sizes set seem to always be low. What could a fix look like?

• Currently I have the logistic group in my inventory disabled, and pick up the items when they are completed while removing them from the group. Would it be too much of a hassle to make it so I can have it on so bots deliver them to me or make ghosts so that they can place them themselves, without the auto-mall making more because they are no longer in the chest/logistic network?

• Not that important because it would fundamentally change the setup too much, but any reason/way to reduce the overall number of assemblers/the footprint in general? Note that it is actually positive that separate assemblers make the requested item and the missing intermediates, since bots get time to transfer the required items to the chest.

Thanks for reading!

[Tertius]

About your 1st issue (selector combinators, unintended change of item order): The selector combinator is the best approach to pick the Nth item from a list of items. The challenge is to keep item order stable while crafting. For the selector combinator, it first sorts by amount. For items with the same amount, it sorts by internal item precedence. Look into the item picker. The more to the left, the more to the top, the higher the precedence. Items on different tabs more to the left have higher precedence.

So if you add items to a list with all items same amount, it's not being appended to the list. Instead it's being inserted somewhere in the middle according to the internal item precedence.

So one approach can be to prepare the list of items to make, then lock that list by putting it into some memory cell, then start producing.

Another approach is what I did: I added one item at a time with amount 1 and producing started immediately. However, each tick I increased the amount of existing items by 1, so when the next item is added, it is added with amount 1 and existing items have amounts > 1. This way the next added item is always added to the end of the list and the list order as a whole stays stable. The amounts themselves have no meaning except to tell how long they've been on the list. They cannot be used to tell how many items still need to be crafted - that has to be handled elsewhere.

About just inserting the proper amount of items for one craft and nothing more: this severely reduces manufacturing speed for items with a crafting time of 2 seconds and below. Because of this, I didn't limit the insertion for my mall. I even doubled the amount to request and insert - to keep the assembling machines continuously working even for fast recipes. Flushing after recipe change is ugly but inevitable. I use 2 bulk inserters into 2 active provider chests to keep flushing time low.

In case you're interested in how I did it, see: viewtopic.php?t=122384
I improved the logic since then a little bit, but the concept is still the same and I still use that mall for my maps. In addition to the forum post, also look into the description of the combinators.

[PrK]

Thanks for the fast reply (again)!
I had actually checked your thread and the blueprint ingame (plus this thread), but couldn't figure out how the list was stable and incremented and assumed it was tied to the resetting every minute, which I don't want to have (sometimes a specific ingredient that the regular mall is making is in shortage as I haven't scaled up that chain yet and I don't mind waiting, plus resetting the recipe trashes the items in the requester chests which are frequently in the thousands). I was also confused by the custom D index and the default value of 1. Long story short, I couldn't make heads or tails of it.. The closest I can get to replicating this functionality is a decider with a looping wire incrementing every signal ad infinitum (or until the items get crafted and I clear the logistic group..) after the constant combinator and before the selectors, so every new item I add to the list goes last by virtue of not having a value in the thousands. And then another decider after each selector to get back the original, desired value. Am I close? Or is that actually the memory cell approach that you mentioned?
About the input inserter besides everything I just find it cool that it fills each craft perfectly. But yeah, for a proper auto-mall it doesn't make sense. One thing that could potentially be beneficial for my case would be a way for the selector to be in random input mode but output say every 5 seconds instead of every tick. Any way to easily do this?