How do I build a make-anything-machine?

[i-make-robots]

05-08-2025, 18-37-37.png (319.69 KiB) Viewed 566 times

The Nth Py assembler chooses the N'th item from the the list of network requests (green wire). When a sophisticated multi-step recipe is introduced, some Nth item will reshape the list of demands, causing the assigned builds to fluctuate and the system ping-pongs every frame instead of building the items. Maybe there's a latch that would help here?

What I want is a sushi chef:
requester <- assembler 0 makes first unfulfilled item <- requester for A0 <- assembler 1 makes first unfulfilled item <- requester for A1....
to some depth.

The problem I'm really trying to solve: the sushi belt for my make-everything-machine is getting enormous and the travel time for goods is awful.
I'd like to build a small number of make anything machines and have them run in parallel to make whatever I need on demand. It would also free up all the resources in the waiting-to-be-picked-up red boxes all over the sushi mall.

[eugenekay]

Not specific to Pyanodon's in any way.....

You are trying to solve the Recursion problem in Factorio; which takes more than a couple of Combinators.

Try using the "Random Input" mode of the Selector Combinator to choose the Recipe, instead of the Select Input mode, for a couple of the Assemblers. Make sure to use a slightly different Interval for each Selector, or they will all change-recipes at the same time. This will make the system try "something else" if it is stuck trying to produce a certain step of an Intermediate chain for too long.

Good Luck!

[mmmPI]

Maybe there's a latch that would help here?

Yes ! one that would hold a signal to assign a receipe and be reset when the assembly finished the receipe using the "read receipe finished" control signal can be helpful particularly when the machine needs to craft intermediate product => finished product using those and again and again, because that's often when the problems occur without latches, the machines feeds itself on intermediate for a finished product, drops under the threshold for said intermediate, recognize it's more important to make the intermediate than the finished product => switch receipe back from the finished product to intermediate => output the buffered intermediate => goes above threshold for that intermediate => switch receipe to make the transformed product => feeds itself on intermediate for that finished product and the cycle continues forever.

The problem I'm really trying to solve: the sushi belt for my make-everything-machine is getting enormous and the travel time for goods is awful.
I'd like to build a small number of make anything machines and have them run in parallel to make whatever I need on demand. It would also free up all the resources in the waiting-to-be-picked-up red boxes all over the sushi mall.

Do you plan/have a strict requirement that all machine be able to switch to every recipe potentially = be similar units ? or would it be ok to have "sets" of machines with different modules that would have their own "subset group" of receipe to select ? That could influence the design choice if you have some machines with productivity modules, others with speed and others with quality and drives the consideration when designing/attempting to help.

Do you plan to have "only" "smart" machines to solve Pyanodon's/your needs ?, as that would raise the complexity bar compared to having plans/usage for a mix of "smart machines" and a few dedicateds machines on which you could discard the most annoying cases.

You want/need to use belts and not robots for the logistic ? It makes things easier if you can use robots.

I haven't explored using randomness here, i'm also not familiar with the recent Pyanodon's receipe and i don't claim to have the perfect make-anything-machine. I understand how changing receipe randomly makes sure the system won't jam on a unforeseen problem for too long. I'm more used to relying on a simpler less fancy priority system with 2 or more groups of machines which can jam and would prompt me to change things, i'm usually not going for the perfect design that i would have prepared in advance but for a new one each game, one that i can improve upon during the course of the game.

Here is an example of what i mean taken from vulcanus :

crafter.jpg (101.8 KiB) Viewed 428 times

0eNrtWmuO2zYQvkrAn4UUWC8/FmguslgItER7iZVIhaKcuAsfoAfpxXqSDklbkm3KMrWbtEkT5AdNkx+H8/hmON5XtC4aUgnKJHp4RTmpM0ErSTlDD4h8zaTAmST5h43g5YddU2SYNTXyEM04q9HD4yuq6ZbhQm1muCSwS/A1r7iQ6ADLWE6+oofg4FkW4rom5bqgbOuXOHumjPgRQH9ucEHlHhY0LONlCaJ0SOHhyUOESSopMefrD/uUNeWaCDjKO8FXtCK+5P5W8IblAFzxmpqbvSKA8pP5x8RDcJAfLj8mcEZOBcnMiqWS+AI6PIO+DbgAQAtENAoRj0HEoxDJGEQyChGNQcxbiFpygbegacxebFDLFiq2Qy1aqOyZlDTDhV8VGPzx5tUSbbGSCsEBQ4qGWD3HQ2BSdckHVDRrAega2Eym3QbGRQnOCX4mSWkci+Y9X60EzxvwjR0s90sYF8QPtV+a9bCcpZTt4G5c7M3+7hPYrJY4e0EPM6UA6zfB4Dfg8wf4f625pYPmwl+a62lu1WpOkM8NqSURPuiwlrc9ONSqO25JN7SAffoKteGN4/WPpOehdsXZ7PFkUsAm0KtP2FZxX8OoPKO/VrNgkQoLLJW90O96olF8nczgck+2mApm7THrpnjxKauJAFFs11tcXK/HgkFoww4ceDCyx3wQOrDYEIYLmQ5hjLNpOIrhQqdDGHOHtBWcod1hsI5ha3Cowi9wWd129EADQ46XghfpmjzjHVXe94oyKrKGypQwvC5IfiKQ0zRsyVvQDRUQJl3el3tNJzsqZKMd+ySVXuGTHRF7CXXAFpnDIYqVm8+uIkB/XXCRAp8QFebHz+oQoTdsdaSt9RgrirDppePPHFgtVxzAyzVl+pybkRJcVAt2XR1RO6Voruh/enRXElRK5v49jfz9519IFUa8kVUjL+uyuxAVj9h01DHlQLl2I3CHvagmMj2lF+NAguAc0sBWkJyCDLWZPwykpoFcU1eE5N8/yQx9Ew2ln3DmrNXwl1ZHtdolpvYNcq3J+czoMVg5pHJ7lg3DqQSiD//elAE3A5w3Us0n5J2dnzIiv3DxouUUXUIAlyNw8Q0uanJ59vUevazdpH30jXymxK72qa6UUvV6BUcFrPaoe8Qe4MQwur+4mncWv+uJGbsUph34cjRfq0yZ8k3KKwKmNMWCJW13ef1kuftDxENS4Po5ZVzRkJE+75joCKNMsW42G41lLG3RQ6+mAoakO+LDO2JnQmxIHfGZOmyo8/sNl1wYzl7KjxfrSi1NTTr1GQK+lm1xv2zxu8j26X7Zli5emVx45bs4kNWcK0f6jc7o99+t3/5nZPwGuo0c3rKhG91GgYtjh/81unXj1CicwKnBGKdGDskwOLOODSx2jOjlEW9+/RD+aZ9kUZcbT2/ku8vOxY23Q9aqY0o3C0IHl75sBMhB3NpYwfF9YBr8Xq9xuBW4LFWA+PAGwS/aq6YC97pFjW5/TAXql2gVpsKv1LPEEa8PeEetM1XW6zb9WxEXNxhzKuay1/wiIlNvYd38quFJvMV/ODtUfKbe1ft2XDvgXpMVC0mLgoi9igBB3qKMXntV4Bw7unx4BhUO/UozWbguirKCbjY++VoVXPls7SrnGWyP92ldFXgPQcVI4WicPmLSsw2VzyWRYPczmpys1fntJDUZdzHC61NVsRzM0JM9v4upDa7le0D2W2Lq16J3JMFem0bw7IVIv6YFdwTs40WWuP+Ct7qH5mSkp6EUP3dN8fF3SPE432GWkdw/lrGu1lb/rJlekA3QMeBylgF5kinAA6ne/CDjlpov0OK+LSbId0QcyPjgkQSSPqQ892x0knXQjRaO5fR8qJyOf5wH8g/6HrYeYrfqcjS1DRp2cadhO+AL277NmN1veqp26r2N0W/opFBXcLuOnFtDjgr6CVpDFo8bDQVr1+Yb9ukHQiCeuYdAMGThoVbBjxUDYIUvcCdlg0eoJEMParTwyXuE6i/0wuA0jj2ohrrxcc3KC9Q4OI0hcXTj5WkcqvkYxlCrBR7YIDBjmF+Z+UCNY40Jx8DexKwJ4SzYq+djgxmp8UrNGxmiwGCqeSh/AjUfPD2Z3xpV6dr+maKHCryGtwHYvpE8E3hjKs8dFC5akck8XMWrVTJPZkEyiw+HfwCrcLXi

Copy blueprint

One should probably remove the request for 1 silo to be able to use it, otherwise it could cause problem when the left machines request 10 times the intermediates needed for a silo, as 10K concrete wouldn't fit the blue chest, this is situationnal, taken from a game, not the perfect setup that works every time ever where from a blueprint book. ( disclaimer )

Apart from that, the logic is that the left machine reads from the robotport the items in the logistic network and compare it to the list of finished product stored in the constant combinator. It tries to build the items on the list to make sure the logistic network contain the desired products.

The machines on its right is the intermediate product assembly, it also read the items in the logistic network, to avoid making intermediate items that are already present in quantity, it also has a constant combinator with some items and very large number associated which excludes them from the list of possible items ,as if there was already a huge amount of them in the network, this is the case for concrete pipes blue and red circuits, because those are made in foundries and EM plant.

There are no latches used on this one, because "supposedly" none of the 2 machine can make a finished product and the intermediate needed to make it, it's either the left machine or the right machine that will do it.

But in practice, no, the case when the left machine has to do a lot of "bulk inserter" can cause a jam, because then the right machine will try to make "fast" inserter and if there are no "inserter" ( yellow) in the network, it get stuck. ( only 2 machines, what happens when one need a 3rd level of depth ?)

This can be "fixed" by adding "inserter" in the combinator that hold the list of desired finished products for the left machine. In such case the left machine will try to do "inserter" in priority over "fast inserter" or "bulk", and the right machine will try to do "green circuit" and the other intermediate. Some like green circuit can be excluded alongside red and blue circuits.

It will turn to a situation where when the left machine tries to do "bulk inserter" again in the future, it will no longer jam, because it will potentially trigger the right machine to do "fast inserter", and if when doing so it deplete the buffer of "inserter" ( or if it happens that a human removes them all from the network at this exact moment) , it will turn again the left machine to try and do "inserter". ( since no latches ). ( 3rd level of depth, 'accounted for when encountered' ).

It's not a "perfect system" that has all the theory built-in already so as to function no matter what, it's something that can be expanded organically; since it read on the logistic network, it's easy to duplicate such setup, they would work in parrallel, or you can have one that is more "military oriented" and one that has a preset list of item made to expand outpost, and maybe they only have a few item in comon in the list and they would both make "walls" when the threshold is low because there is no additionnal logic needed if they have both "wall" on their list.

I have this game with 3 of those in Nauvis, plus a couple dedicated machines for the intermediates that are deemed "too slow" or that i can make in better assembly, they are all entangled to make use of beacons and some have access to water because here they make the concrete , but no lube because engines are "too slow" they have a dedicated assembly machines :

nauvisdeplooyment.jpg (286.35 KiB) Viewed 428 times

Without robots i think i would try to emulate the logistic network with the "read all belt content" functionnality and wiring a few buffer chest that can store/remove item from a mixed item belt loop, where the machine for intermediate would output, and that the machine for finished product would use as input. Plus maybe an inserter with a dynamic filter to remove any finished product that would end up on that belt loop. It would make things more complicated and bulky. It's unclear to me what you mean by "sushi" when the picture attached has requester chest

Does that help ?

[Tertius]

I'd like to build a small number of make anything machines and have them run in parallel to make whatever I need on demand. It would also free up all the resources in the waiting-to-be-picked-up red boxes all over the sushi mall.

I made a universal mall with this approach:

• item delivery and removal with logistic robots. No belts. Delivery with requester chests requesting the current ingredients and active provider chests to give back outgoing material to the logistic network.
• the list of of wanted items is defined in a constant combinator
• a circuit goes through the list of wanted items one by one
• the current wanted item is added to the list of items to craft (initially the list is empty)
• each item on the list of items to craft has a fixed position. The 1st added item is always the 1st item in the list, the 2nd added item is always the 2nd item and so on. This is accomplished by adding a new item with value 1 and incrementing each tick each value by 1. This way the next items have always a lower value than the previously added item.
• there is a number of assembling machines. Each one has a position from 1..max. Each machine has a selector combinator that picks the nth item from the list of items to craft. Since the position on this list is stable, each machine gets the same item every time.
• the picked item is set as recipe in the associated assembling machine
• ingredients for the current recipe are read from the assembling machine
• the ingredients are added to the items to craft if not already present and if their amount in the logistic network is 0 or below some individual threshold. A threshold for example given in the above constant combinator with wanted items or some other constant combinator.

This way one assembler gets assigned an item to craft. Then the next assemblers are assigned its ingredients to craft. Since the latter assemblers are also inspected for their ingredients, any nested ingredients are also added to the list of items to craft and getting an assembler assignment, if there are not enough of them in the logistic network.
This way I'm unwrapping the dependency tree of ingredients. As long as there are as many assemblers as the deepest ingredient dependency tree, any item can be produced and dynamically their ingredients as well. I use 12 assemblers in this row, but this many is mainly for speed.
They will also craft in parallel. However, if it takes much more time to craft the ingredients than to craft the item itself, the assembler for the item is idle waiting. I added a second row of assemblers that pick "long running" recipes the same way, so long running recipes are assigned to more machines, so the idle time is reduced.
If the requested number of items are reached, the requester chests for supply are being disabled and also the inserters feeding items to the assembling machines, so there isn't any more supply. However the assembling machine will continue to produce until their input slots are empty. This cannot be avoided by disabling the assembling machine, because a disabled machine cannot change its recipe, so the recipe would stick.

The whole list and recipe assignment is reset every 2 minutes to get rid of fulfilled requests, then started again. This is required, because you cannot easily replace an obsolete recipe with a new one and keep all the positions.

There's more to it, for example how to individually request the ingredients for each assembling machine. Or how to handle items that require fluids as ingredients, or how to exclude items that cannot or should not be made with assembling machines. This is just the general approach.

I documented the mall here: viewtopic.php?t=122384 if you want to see how it looks. The blueprint in that post is slightly outdated, I improved that mall since. The general approach is the same, and a screenshot of my current mall would probably look the same, but in detail there were many small improvements.

The speed of this mall is not significantly lower than the speed of a full mall with dedicated assembling machines for every item. It may be even higher due to the 2nd line of additional assemblers for slow recipes.

On Nauvis, the whole thing with additional module production to the left and belt production on the right looks like this. I also built the central part on Vulcanus and Gleba, and the belt extension including green belts on Vulcanus, however that's overkill I found out.

05-09-2025, 14-23-29.png (5.72 MiB) Viewed 389 times

[NineNine]

Wow, there are a lot of serious programmers who play Factorio! You guys have made some crazy stuff.