Hey folks,
I posted this a while ago on the forum, but i didnt get any feedback viewtopic.php?t=130089
Is this useful? Is it overengineered? Does it work?! I dont have a university degree in engineering or computer science so I had no idea what I am doing there... but it somehow worked out? Have been using it for a long time now and fixed all the issues that I could spot. Would be cool if I could get some feedback from an engineer/computer scientist on this thing, if they have time for that..
Anyhow, thanks for the time!
Can I get some feedback on this contraption?
-
inefficient
- Inserter
- Posts: 32
- Joined: Fri Jul 11, 2025 2:49 pm
- Contact:
Re: Can I get some feedback on this contraption?
I've seen it, I know what it's about (built a big auto-mall myself), I know about all the challenges this includes, and I congratulate you for achieving a working solution.
However I didn't comment, because I didn't want to discourage you. I respect your work. But from my point of view, you used way too many combinators. The space they all occupy is probably enough to build a classic mall with dedicated machines, each with its hardcoded recipe. So this mall fails to achieve goal I have with such a thing: it has to be smaller than a classic mall and at the same time universal.
Your build contains more than 500 combinators.
That many combinators are not manageable. In their entirety it's not simple enough. You used some of the contraptions I published in my combinator cookbook and plugged them together, but I encourage you to find your own specialized solutions for the problems at hand. It appears a third of the combinators are just present to delay one tick. That's wasted space and manageability. Find direct solutions not dependent on long synchronized signal pipelines. You might have to simplify your goals and throw away desired features to achieve that. With the mall I made, I threw away many possible and nice to have features for simplicity. I still understand every combinator I built, one year later.
The core specification of such an auto-mall is: give it a list of items to craft and give it an inventory of existing items. The mall must build all the missing items so the amount of existing items is equal to or greater than the amount of desired items. This is a quite simple specification that opens up many approaches. Everything else is optional. Nothing beyond is granted and a "must have".
The solution I built needs 3 combinators per assembler and additionally 18 global ones. It doesn't need dummy machines just for reading recipes. I also added an optional foundry based universal mall for all belts (yellow to green, all 3 pieces) with 5 foundries and 17 combinators. There's also an optional component for modules. It's able to craft items that need lubricant, water, cold fluoroketone. However beyond that no specific support for planet specific crafting machines. It's expected all the base intermediates are supplied externally so they can profit from productivity modules, which is incompatible with universal recipe changing.
You tried to achieve 100%. As far as I see you added feature bloat (and created a huge product at the end), similar to what happens with modern software projects without a manager setting goals and resource limits. Do you know the Pareto principle, or the 80/20 principle? Just 20% of the effort is able to achieve 80% of the goals. Invest just 20% and get 80% of the desired features. Let the final 20% go.
However I didn't comment, because I didn't want to discourage you. I respect your work. But from my point of view, you used way too many combinators. The space they all occupy is probably enough to build a classic mall with dedicated machines, each with its hardcoded recipe. So this mall fails to achieve goal I have with such a thing: it has to be smaller than a classic mall and at the same time universal.
Your build contains more than 500 combinators.
That many combinators are not manageable. In their entirety it's not simple enough. You used some of the contraptions I published in my combinator cookbook and plugged them together, but I encourage you to find your own specialized solutions for the problems at hand. It appears a third of the combinators are just present to delay one tick. That's wasted space and manageability. Find direct solutions not dependent on long synchronized signal pipelines. You might have to simplify your goals and throw away desired features to achieve that. With the mall I made, I threw away many possible and nice to have features for simplicity. I still understand every combinator I built, one year later.
The core specification of such an auto-mall is: give it a list of items to craft and give it an inventory of existing items. The mall must build all the missing items so the amount of existing items is equal to or greater than the amount of desired items. This is a quite simple specification that opens up many approaches. Everything else is optional. Nothing beyond is granted and a "must have".
The solution I built needs 3 combinators per assembler and additionally 18 global ones. It doesn't need dummy machines just for reading recipes. I also added an optional foundry based universal mall for all belts (yellow to green, all 3 pieces) with 5 foundries and 17 combinators. There's also an optional component for modules. It's able to craft items that need lubricant, water, cold fluoroketone. However beyond that no specific support for planet specific crafting machines. It's expected all the base intermediates are supplied externally so they can profit from productivity modules, which is incompatible with universal recipe changing.
You tried to achieve 100%. As far as I see you added feature bloat (and created a huge product at the end), similar to what happens with modern software projects without a manager setting goals and resource limits. Do you know the Pareto principle, or the 80/20 principle? Just 20% of the effort is able to achieve 80% of the goals. Invest just 20% and get 80% of the desired features. Let the final 20% go.
Re: Can I get some feedback on this contraption?
I think if you want some feedback you can also explicitly ask for it, which isn't the case on the original thread, you say you are open to suggestions, but not "please give me your opinion" , as you did in this thread, maybe you would have received more feedback , you can also "bump" the thread for attention i suppose, anyway it's done now.
The auto-mall itself is a fun concept, but i'm sorry to say yours looks over-engineered to me, i have toyed around a few myself and tried to minize as much as possible the number of combinators. It's not just for the sake of it, i found it also helps me remember how everything works more easily, so that i can reuse it in other games potentially "years later". When you say "don't touch the timer combinator unless you know what you are doing", even if i feel confident around combinators, i'm intimidated / humbled by the scale, in order to know what i'm doing i'm going to have to understand the whole thing, or use it as a blackbox compared to a "simpler" auto-mall.
I think it's very good in that it's presented in the forum though, it's not "just working" , it takes a lof of time to further clarify the inner workings with words made for the others. It's not a "necessary step" in making an auto-mall , it's a step further and it gives a chance to analyze the result under a different angle as " is it doing the job for which it was made", but also "do i need to tell a lot of information to the 'other users'" , or maybe "does the machine comes with many rules and caveat". It reminded me of my first post on this forum where i tried to present a system with bots that worked great in game and people later gave me positive feedback in multiplayer, but the explanations takes an hour to read and understand, for a system that's much much simpler to just show or use.
In the case of the automall the sheer number of combinator seems a topic of interest in itself, it could help to break it down to several parts to refine each individually , if you are wishing to get more specific feedback on the logic, i imagine fom your presentation that you may be interested in practical problems you encountered rather than 'here's my mall /you could have done it this way". I hadn't read Tertus answer before writing this, because i didn't want to be influenced, but i don't want to be dismissive of his approach, I feel if you want to " make better the auto-mall for in game usage" that isn't the same direction as if you want to "learn about combinators thru the making of a very complex auto-mall". What kind of feedback are you looking for ? x)
In this particular case, it feels unfortunate that the most usable solutions in game are the "simplest" and least interesting to learn combinators from (imo). Things with the least amount that can go wrong. I don't think "refining each part individually" is the "smart" approach to design further auto-mall, but it can help talking (more) informed decisions for the next architecture/design philosphy, from a better understanding of the little details. So it's more than the sum of refined parts, it's thought to be more minimal as a system.
is it useful ? => yes , that's the best learning tool for you
is it overengineered => yes, that's part of what makes it a learning tool
does it work ? => i suppose, you say it does, i haven't tested it though, i was afraid to do something wrong following the instruction and didn't want to risk having to debug such complicated machines to make sure the screw-up didn't come from me
The auto-mall itself is a fun concept, but i'm sorry to say yours looks over-engineered to me, i have toyed around a few myself and tried to minize as much as possible the number of combinators. It's not just for the sake of it, i found it also helps me remember how everything works more easily, so that i can reuse it in other games potentially "years later". When you say "don't touch the timer combinator unless you know what you are doing", even if i feel confident around combinators, i'm intimidated / humbled by the scale, in order to know what i'm doing i'm going to have to understand the whole thing, or use it as a blackbox compared to a "simpler" auto-mall.
I think it's very good in that it's presented in the forum though, it's not "just working" , it takes a lof of time to further clarify the inner workings with words made for the others. It's not a "necessary step" in making an auto-mall , it's a step further and it gives a chance to analyze the result under a different angle as " is it doing the job for which it was made", but also "do i need to tell a lot of information to the 'other users'" , or maybe "does the machine comes with many rules and caveat". It reminded me of my first post on this forum where i tried to present a system with bots that worked great in game and people later gave me positive feedback in multiplayer, but the explanations takes an hour to read and understand, for a system that's much much simpler to just show or use.
In the case of the automall the sheer number of combinator seems a topic of interest in itself, it could help to break it down to several parts to refine each individually , if you are wishing to get more specific feedback on the logic, i imagine fom your presentation that you may be interested in practical problems you encountered rather than 'here's my mall /you could have done it this way". I hadn't read Tertus answer before writing this, because i didn't want to be influenced, but i don't want to be dismissive of his approach, I feel if you want to " make better the auto-mall for in game usage" that isn't the same direction as if you want to "learn about combinators thru the making of a very complex auto-mall". What kind of feedback are you looking for ? x)
In this particular case, it feels unfortunate that the most usable solutions in game are the "simplest" and least interesting to learn combinators from (imo). Things with the least amount that can go wrong. I don't think "refining each part individually" is the "smart" approach to design further auto-mall, but it can help talking (more) informed decisions for the next architecture/design philosphy, from a better understanding of the little details. So it's more than the sum of refined parts, it's thought to be more minimal as a system.
is it useful ? => yes , that's the best learning tool for you
is it overengineered => yes, that's part of what makes it a learning tool
does it work ? => i suppose, you say it does, i haven't tested it though, i was afraid to do something wrong following the instruction and didn't want to risk having to debug such complicated machines to make sure the screw-up didn't come from me
Check out my latest mod ! It's noisy !
Re: Can I get some feedback on this contraption?
About bloat and simplicity. About simplifying goals and not making 100% solutions. And about creating specialized solutions instead of chaining pre-made snippets.
It happens I continued my efforts to build legendary items. Some end products can be crafted best by upcycling them, and others can be crafted best by upcycling their intermediates, then directly craft the legendary item. And so I had to build a small mall for the small amount of these items.
It's just a byproduct of a rather large upcycling facility, so it really had to be simple because my patience dealing with this was already at an end.
So no dynamic recursive intermediate production. Just 1 machine with dynamic recipe changing.
So I built dedicated machines for the intermediates. Synergy: achieves the goal of maximum productivity with productivity modules to get maximum amount of output with a minimum amount of input.
The combinator contraption to select the recipe to craft is the group of 6 combinators at the lower right corner, and that's already bloat! Just 1 combinator is sufficient, but I bloated due to feature creep.
1 combinator to filter non-legendary requests (the Q) (workaround for human error). 3 for blacklisting items where not enough intermediates are currently available (workaround for mall stalling until some ingredient becomes available). 1 for increasing item requests for the requester chest for speedup (workaround for slow processing of fast recipes). 1 for selecting the recipe to craft.
Just the 1 to select the recipe for crafting is really required! The other 5 are feature bloat.
As "must have" bloat I identified the blacklist. It can happen some item is requested but the intermediates are not available so production stalls, but all the next items have enough intermediates but its waiting.
Goals I gave up with this approach:
(blueprint of the screenshot area, in case you'd like to inspect the mall logic and my comments in the combinators. Not really useful for general use because the rest of the factory is missing)
It happens I continued my efforts to build legendary items. Some end products can be crafted best by upcycling them, and others can be crafted best by upcycling their intermediates, then directly craft the legendary item. And so I had to build a small mall for the small amount of these items.
It's just a byproduct of a rather large upcycling facility, so it really had to be simple because my patience dealing with this was already at an end.
So no dynamic recursive intermediate production. Just 1 machine with dynamic recipe changing.
So I built dedicated machines for the intermediates. Synergy: achieves the goal of maximum productivity with productivity modules to get maximum amount of output with a minimum amount of input.
The combinator contraption to select the recipe to craft is the group of 6 combinators at the lower right corner, and that's already bloat! Just 1 combinator is sufficient, but I bloated due to feature creep.
1 combinator to filter non-legendary requests (the Q) (workaround for human error). 3 for blacklisting items where not enough intermediates are currently available (workaround for mall stalling until some ingredient becomes available). 1 for increasing item requests for the requester chest for speedup (workaround for slow processing of fast recipes). 1 for selecting the recipe to craft.
Just the 1 to select the recipe for crafting is really required! The other 5 are feature bloat.
As "must have" bloat I identified the blacklist. It can happen some item is requested but the intermediates are not available so production stalls, but all the next items have enough intermediates but its waiting.
Goals I gave up with this approach:
- skip selecting recipes with insufficient intermediates (blacklist works by waiting for a 30s timeout, then switch to the next recipe)
- dynamic crafting of intermediates to just have 1 assembler for intermediates with productivity modules and 1 for intermediates that cannot use productivity modules
- stop crafting intermediates as soon as a production target has been achieved (not visible from the screenshot alone)
- craft exact amounts (it eventually stops after the target has been achieved; the faster the recipe the more overproduction)
- use the electromagnetic plant/foundry/cryogenic plant for power poles and other items (either I'm not going to use their legendary variants or there is a separate factory)
- getting rid of the constant combinator supplying some [W] value (it's super ugly)
- 02-15-2026, 14-40-54.png (1.04 MiB) Viewed 265 times
-
inefficient
- Inserter
- Posts: 32
- Joined: Fri Jul 11, 2025 2:49 pm
- Contact:
Re: Can I get some feedback on this contraption?
Cool, thanks, very helpful, both of you!
I started out with the idea of having a machine where you need one constant combinator in which you put whatever you want and then have a bit of magic and then a made product. From then on I went very linear, as is obvious from the design and the way I used Tertius snippets. Because I never once reflected on the entire thing, and asked, what is really necessary. I also lacked the creativity how to get there using alternative approaches such as you, Tertius, have used for your mall, that never would have crossed my mind. Anyhow.
OK, now individual replies.
Tertius; thanks again for the feedback and your time. OK, its very useful feedback to forgo certain features. I think I was very holistic in what my machine should be able to do, and resulted in all the bloat, But yeah, no supervisor and no limited resources... Also the advice on focus on the essential feature is very useful, cheers. It just feels hard sometimes to let go
but much appreciated, will take that serious. Hmmm I was kinda assuming the snippets you made is what is used to build modern computers? I added all the delays to achieve something that I found out is called concurrency in computer science? So that's why I used them. I felt these are the basic building blocks of building such a machine so I didn't question this approach but thanks to your BP, and the added comment, it is very clear how to break this up into more manageable bits that can be worked on. Will keep that in mind for future projects.
mmmPI; ups, you are right, sorry, that would have been a bit more straight forward to ask for feedback straight away sorry, thanks for help anyways. Yeah, definitely, I will regret that if an upcoming patch changes combinators and/or wiring behavior 
hmm OK, I didn't think it how that would feel if I write it like that. But yeah, I agree, I could have sold it a bit better and honestly, I am rarely using some of the tuning combinators myself because as Tertius pointed out, most of the time you are not even looking at it so what does 5-10% faster mean anyways? Yeah, I had a look at all the automalls out there and only Tertius made an honest effort to explain what was going on, at least from what I saw. So I felt like this was the right thing to do. I totally agree that multiplayer is super useful to get feedback but also reflect on the build! Its a bit unfortunate that I started playing factorio only a year ago and now its quieted down quite a bit so its a bit hard to properly connect to people here to play together and most of my friends are not into automation games. Please don't look at the combinators, its very tedious, use your time for something useful, I just wanted to have superficial feedback. The machine works for now and doesnt need fixing or analysis. I will make another one in 2.1. when there is more stuff. Probably the feedback Tertius gave was what I was after? Just like, advice on how to make something that is easy to maintain, robust, and design principles that guide the creative process. Nothing more. Probably also what other people think when they see it? Like you did, I will rewrite the post a bit now knowing that you found it intimidating, just that people give it a go. OK, cool, the advice at the end of the post is also very useful, like I said, I will build another one eventually and apply what you guys taught me and hopefully cut the combinator numbers down substantially...
Anyhow, both of you, thanks again, very helpful, I will keep these principles in mind when designing more things. Thanks!
I started out with the idea of having a machine where you need one constant combinator in which you put whatever you want and then have a bit of magic and then a made product. From then on I went very linear, as is obvious from the design and the way I used Tertius snippets. Because I never once reflected on the entire thing, and asked, what is really necessary. I also lacked the creativity how to get there using alternative approaches such as you, Tertius, have used for your mall, that never would have crossed my mind. Anyhow.
OK, now individual replies.
Tertius; thanks again for the feedback and your time. OK, its very useful feedback to forgo certain features. I think I was very holistic in what my machine should be able to do, and resulted in all the bloat, But yeah, no supervisor and no limited resources... Also the advice on focus on the essential feature is very useful, cheers. It just feels hard sometimes to let go
but much appreciated, will take that serious. Hmmm I was kinda assuming the snippets you made is what is used to build modern computers? I added all the delays to achieve something that I found out is called concurrency in computer science? So that's why I used them. I felt these are the basic building blocks of building such a machine so I didn't question this approach but thanks to your BP, and the added comment, it is very clear how to break this up into more manageable bits that can be worked on. Will keep that in mind for future projects.mmmPI; ups, you are right, sorry, that would have been a bit more straight forward to ask for feedback straight away
sorry, thanks for help anyways. Yeah, definitely, I will regret that if an upcoming patch changes combinators and/or wiring behavior hmm OK, I didn't think it how that would feel if I write it like that. But yeah, I agree, I could have sold it a bit better and honestly, I am rarely using some of the tuning combinators myself because as Tertius pointed out, most of the time you are not even looking at it so what does 5-10% faster mean anyways? Yeah, I had a look at all the automalls out there and only Tertius made an honest effort to explain what was going on, at least from what I saw. So I felt like this was the right thing to do. I totally agree that multiplayer is super useful to get feedback but also reflect on the build! Its a bit unfortunate that I started playing factorio only a year ago and now its quieted down quite a bit so its a bit hard to properly connect to people here to play together and most of my friends are not into automation games. Please don't look at the combinators, its very tedious, use your time for something useful, I just wanted to have superficial feedback. The machine works for now and doesnt need fixing or analysis. I will make another one in 2.1. when there is more stuff. Probably the feedback Tertius gave was what I was after? Just like, advice on how to make something that is easy to maintain, robust, and design principles that guide the creative process. Nothing more. Probably also what other people think when they see it? Like you did, I will rewrite the post a bit now knowing that you found it intimidating, just that people give it a go. OK, cool, the advice at the end of the post is also very useful, like I said, I will build another one eventually and apply what you guys taught me and hopefully cut the combinator numbers down substantially... Anyhow, both of you, thanks again, very helpful, I will keep these principles in mind when designing more things. Thanks!
Re: Can I get some feedback on this contraption?
Yes and no. The CPU in modern computers is made of snippets. Actually it's layers over layers of snippets. Transistors make tiny snippets, tiny snippets make small snippets, small snippets make bigger snippets and so on. This will grow the numbers of transistors exponentially. Modern desktop CPUs have 1-2 billion transistors. This is a number nobody is able to grasp. If if was possible to reduce the amount of transistors in the lowest snippet layer just by 1 transistor, you would need just half or two thirds of that number, thus half of the silicon chip size, thus half the manufacturing cost.inefficient wrote: Sun Feb 15, 2026 9:32 pm I was kinda assuming the snippets you made is what is used to build modern computers? I added all the delays to achieve something that I found out is called concurrency in computer science? So that's why I used them. I felt these are the basic building blocks of building such a machine so I didn't question this approach but thanks to your BP, and the added comment, it is very clear how to break this up into more manageable bits that can be worked on.
So it makes sense to not create snippets just for the sake of modularization but instead for functionality. If you make the "small snippet" directly with 10 transistors instead of building it from 5 tiny snippets with 5 transistors each, you save 15 transistors, and that's a huge difference if you scale this up to a billion.
What transistors are in a computer CPU as smallest entity is a combinator in Factorio. It's a normalized device, its functionality can be implemented by 1-500 transistors in a CPU, depending on what it is. Addition is tiny, but multiplication and division is surprisingly expensive if it comes to the number of transistors.
But using combinators is not programming. A combinator isn't executing a program. A program is a list of instructions, and the CPU is executing these in order, one after the other. A program has access to some memory, either registers or external memory, accessible with an address.
Combinators aren't executing a sequence of instructions. A combinator doesn't have access to memory. They are just logic devices. They have internal rules to produce some output from some given input. Every tick they generate new output from the current input. All combinators are doing the same thing every tick, and this is in contrast to a program because a program will execute a different instruction every tick.
A program is able to maintain its state with variables in memory. Combinators have a volatile state, just what has been generated on the wire by the previous tick and this is given as new state to the next tick.
Programming has some similarity to combinator building but it's not the same. Circuits run their rules all at the same time. If this is called a program, it is executed from beginning to the end every tick.
It's difficult to explain how to find a good approach to design a circuit contraption. You need experience to know what is possible and you need imagination to simulate a possible contraption in your brain and see if this could work. In my combinator cookbook I tried to document possible functionalities. The intention is not to provide snippets, the intention is to show concepts. Don't copy the snippet. Instead, use the concept.
In my brain, I have a virtual image of 1-3 combinators, and I'm wiring this image and I'm checking how this could produce some desired output from a given input. The signals and their values are small boxes for me that will drive through the wires and being handled by conditions and output specifications. They appear like physical objects I can take in my hand and manipulate. The wires, the numbers. The funny thing is the game is doing this similar to my thinking. You can pipette every signal in the GUI and making it real, and you can put it into some place. You can take a wire in hand and link it somewhere. Wildcards are combs and funnels that split and merge signal paths. I guess everybody has a different representation of all this in their brain.
-
inefficient
- Inserter
- Posts: 32
- Joined: Fri Jul 11, 2025 2:49 pm
- Contact:
Re: Can I get some feedback on this contraption?
Thanks again for the reply and your time!
I also can relate to the way you imagine the combinators in your head and how you manipulate them using your hand. I don't have this with the circuits but with structures of biological systems, its just like I never developed an intuitive feeling for the circuits because I never spend much time with them. Until now Anyhow, thanks for the insight and sharing your approach to handling circuitry! I shall learn from it and build more robust and approachable factorio circuitry!
That makes sense! My background is biology and we have all these awfully complicated networks that sort out all sorts of things and have thousands of features so that was influencing my way of thinking. But given your description I am reminded of these images of depiction of circuits in text books. In biology we do have these simplistic depictions as well, but most of the time we quickly realize that instead of being simple and linear, every combinator so to say, has 10-20 different inputs that modulate the signal. But this is natures way of doing things, man made computation is, as you pointed out, much more orderly and simplistic, otherwise we couldn't control these things. For reference, below I attached a central signalling circuitry that, among many things, controls the division of cells in our bodies. Its much more messy and denser than what we build but thats kinda what went on in my head when I set out to build my little monster. In case you are interested, the circuitry below transmits information from the outside of the cell, the extracellular matrix, through the case of the cell, the plasma membrane, into the inside, the cytosol where it is integrated into the wider cellular state, e.g. am I a happy cell? Am I hungry?, and then ultimately converges onto the control center of the cell, the nucleus, that ultimately decides how to respond, e.g. lets grow! Lets protect ourself, and so forth.. the signals that are send are not very complicated, individually they are binary, on or off, complicated things such as addition, multiplication etc arise from the states the individual combinators are in. That makes it much simpler, conceptually, than man made computation but as you can immediately see, becomes very messy very quickly, as you pointed out that multiplication is surprisingly expensive when compared to addition/substration.In my brain, I have a virtual image of 1-3 combinators, and I'm wiring this image and I'm checking how this could produce some desired output from a given input. The signals and their values are small boxes for me that will drive through the wires and being handled by conditions and output specifications. They appear like physical objects I can take in my hand and manipulate. The wires, the numbers. The funny thing is the game is doing this similar to my thinking. You can pipette every signal in the GUI and making it real, and you can put it into some place. You can take a wire in hand and link it somewhere. Wildcards are combs and funnels that split and merge signal paths. I guess everybody has a different representation of all this in their brain.
- 02-16-2026, 20-13-01.png (289.28 KiB) Viewed 79 times
Anyhow, thanks for the insight and sharing your approach to handling circuitry! I shall learn from it and build more robust and approachable factorio circuitry!