The sad state of circuit logic

[aober93]

... ability to set the stack size of an inserter) are done or to be done for 0.15.

Well thats good ,some would probably say they buy the game one more time but this will remove 1 annoying part of the game for me which is loading a waggon with multiple items which made the inserter stall.

Fix this and tons of issues will vanish. Although i would imply that more finecontrol is not needed for the game, instead when the game works better in certain aspects that finecontrol wont be needed anymore. I think this was a point here that managing certain things here is annoying. But that doesnt imply creating even more micromanagment, instead circumvent with other features. If that makes sense

[Edit]
But also realistically, i dont know why some people want to control the items in a machine. I dont see how this can be implemented, nor have they provided ideas. Anyway ,you cannot change the recipe so why the fuck do you want to control the input side of things? The inserter grabs the correct items it needs anyway. If it takes more than that who cares, because it needs em for the next item it creates. Additionally this actually makes sense, because it pregrabs items it needs for the next item, saving time. I think this is part of a core mechanic for any player. I want to see one example of why this is entirely needed to be changed.

Im also sceptical if "set recipe" is nessecary. There arent so many items that assembling machines are a limiting factor. Its actually the other way around, seeing the popularity of mods that add recipes.

[The Eriksonn]

i had a problem in a factory that only craft say 16 belts, and then the factory gave me exactly 16 belts, and nothing was over on the belts and so on.
the problem was with many assemblers for the same thing for example red science packs, then 1 assembler would end up with one copper and another with the gear, had some fun trying to make inserters putting things in temporary chests so that the assemblers only picked up the thing they needed, and never got out of sync

[Yoyobuae]

i had a problem in a factory that only craft say 16 belts, and then the factory gave me exactly 16 belts, and nothing was over on the belts and so on.
the problem was with many assemblers for the same thing for example red science packs, then 1 assembler would end up with one copper and another with the gear, had some fun trying to make inserters putting things in temporary chests so that the assemblers only picked up the thing they needed, and never got out of sync

Hehe, perfect sync is a bit of my specialty. Here's a sneak peek into what I'm working on now:




The control circuit allows adjusting timing of inserters down to the cycle. Given that belts move at fixed speed, it becomes possible to pick/place specific items from specific locations.

[hansinator]

Thank you ssilk for taking the time to explain your perspective. I get your points and they are of course very valid. I still feel the need in optimizing usage of assemblers, furnaces and train lines with circuits, but I see that opinions differ greatly on that topic. I think this thread has done it's job to bring forward that there are people who like the circuit play-style and that these people desire some improvements. When I started the topic I thought that the circuit people get overheard a little, but now I've learned that it's not the case. I should mention that I played factorio a couple of months without circuits and during that time, when I read the forums, I was asking myself why the heck are the people building such useless things like smart furnaces or sequencer factories. But then I needed a new challenge and found my factories to be to inefficient without feed-back control.

@Yoyobuae
Hey wow I need that Does it work with blue belts? I've got one version of a smart furnace that works off a single belt. Each furnace can be controlled individually and smelt a different material. The smart furnace part is working flawlessly (never blocks), but I've lost interest in syncing the inserters with the belt contents. Here's a video to highlight the problem: https://youtu.be/2Y2NGrRr1Zc. At first it smelts iron ore to steel in one go, then I switch it to stone and then to copper. The left row of numbers shows what the inserters hold in hand and the right row shows the "inverse" of how many items are needed to finish the recipe. Maybe we can discuss that somewhere else, it is a little OT.

Anyhow, those are good examples of circuit play-style For the furnace, I believe it is more energy and space efficient than having furnaces+beacons for each material, at least that was the goal before the combinator count exploded. Interestingly the changes in 0.15 would only make some of the constant combinators obsolete.

[aober93]

The control circuit allows adjusting timing of inserters down to the cycle. Given that belts move at fixed speed, it becomes possible to pick/place specific items from specific locations.

Isnt this a pain to maintain? I mean in contrast to the reward this setup gives.

[Yoyobuae]

The control circuit allows adjusting timing of inserters down to the cycle. Given that belts move at fixed speed, it becomes possible to pick/place specific items from specific locations.

Isnt this a pain to maintain? I mean in contrast to the reward this setup gives.

I simply write a lua script which wires and configures all the inserters for me. (but that kinda supports the whole "circuits are not ready for general use" complain)

Besides, "more pain than it is worth" is a way of life when it comes to circuits.

If you want it easy there's tons of circuit-less solutions which you can copy&paste into your factory, and be happy.

@hansinator: It should work with blue belts. The real issue is dealing with inserter stack bonus.

My approach to inserter control is a bit different. I don't even read input from all of the inserters. Only the very first inserter (which is pulling from a chest) has "read hand contents" mode on. That is the "master" inserter, all the rest are just "slaves" which follow what the "master" one does (or did some time ago).

Then the problem of controlling a whole line of furnaces (or assemblers, or whatever inserters interact with) becomes strictly a timing problem (how much time slave X needs to wait since master made a pickup). And I have a great solution for solving complex timing problems: shift registers. Kinda like the one XKnight used for this (got the idea from that post):
viewtopic.php?f=193&t=29444

But I'm using far longer shift registers (thousands of bits long). Turns out there's an efficient way to get very large shift registers with relatively few combinators (up to +80 bits per additional combinator). Posted an explanation on reddit a while back:
https://www.reddit.com/r/factorio/comme ... 2/dbxhd5b/

Shift registers are very nice for this because they don't just implement a delay (ie. like a counter would) but are a memory cell which holds the whole history of a (binary) signal. Basically can simulate what happens on a belt, as long as belt never stops.

[aober93]

Well i dont mean the setup effort duh! I mean that if the belt stops or you pick something up or there is a power outtage by some laser turrret just a millisecond. Or you edit an assembler. Anything that throw a setup like this totally off. Then the items wouldnt be "perfectly alligned" on this belt anymore and you'd have to put them in line again. And since inserters dont care about the allignment of items on a belt, it seems rather weird to still want them sorted given all the things that ridicule it.

[Yoyobuae]

Well i dont mean the setup effort duh! I mean that if the belt stops

It will never stop. Items will flow from chests to belts, to assemblers, back to belt then back to chests. Circuits take care that chests have enough items, if not the process is halted until enough items are added to input belts. Same with output, if enough items are in output buffer then the circuit will stop the input.

you pick something up

I won't ever pick stuff up.

you pick something up or there is a power outtage by some laser turrret just a millisecond.

Will have an isolated power network specifically for it. And maybe it will shutdown when it detects there will be a power outage (ie. coal running out).

Anything that throw a setup like this totally off. Then the items wouldnt be "perfectly alligned" on this belt anymore and you'd have to put them in line again. And since inserters dont care about the allignment of items on a belt, it seems rather weird to still want them sorted given all the things that ridicule it.

If the worst happens and everything goes crazy, it's easy enough to force shutdown via circuits. Then would need to clear any mess left in belt, clear any mess left in assemblers, then can restart it.


Of course, regardless of what I plan things might not work out very well. It might be this kind of contraption cannot work outside of the "laboratory environment" were I initially build them. But that's fine too, because the fun part was building them in the first place, seeing them work (even if on lab environment), and show them to other players.

Again, such is the life of the circuit network enthusiast.

[hansinator]

But I'm using far longer shift registers (thousands of bits long). Turns out there's an efficient way to get very large shift registers with relatively few combinators (up to +80 bits per additional combinator). Posted an explanation on reddit a while back:
https://www.reddit.com/r/factorio/comme ... 2/dbxhd5b/

Ahh good stuff 80 whopping bits! Is there a blueprint for the single-belt-furnace from the video somewhere? (edit: found the save )

Well i dont mean the setup effort duh! I mean that if the belt stops or you pick something up or there is a power outtage by some laser turrret just a millisecond. Or you edit an assembler. Anything that throw a setup like this totally off. Then the items wouldnt be "perfectly alligned" on this belt anymore and you'd have to put them in line again. And since inserters dont care about the allignment of items on a belt, it seems rather weird to still want them sorted given all the things that ridicule it.

I agree with Yoyobuae. Most things can be worked around. In another thread someone has talked about a circuit that determines if the accumulators have enough power to make it through the night by calculating their discharge rate. If you know power will fail, you can safely shut down critical stuff. And then you can also always make circuitry that detects a fault condition, halts the machines and cleans up to bring everything back into a known state. It is just tedious and usually needs boatloads of combinators. However, if one doesn't give up a solution can be found in a lot of cases.

My automatic supply train I am working on will detect if you pick up or place stuff into the chests that it is using and will take that into account properly. It can't stand power outages so it's got an isolated power supply. I just have one rule for it: never manipulate the cargo wagon inventory manually. That is one thing that can not be worked around, because it is not yet possible to read the train contents.

[hansinator]

But I'm using far longer shift registers (thousands of bits long). Turns out there's an efficient way to get very large shift registers with relatively few combinators (up to +80 bits per additional combinator). Posted an explanation on reddit a while back:
https://www.reddit.com/r/factorio/comme ... 2/dbxhd5b/

Ahh good stuff 80 whopping bits! Is there a blueprint for the single-belt-furnace from the video somewhere? (edit: found the save )

Well i dont mean the setup effort duh! I mean that if the belt stops or you pick something up or there is a power outtage by some laser turrret just a millisecond. Or you edit an assembler. Anything that throw a setup like this totally off. Then the items wouldnt be "perfectly alligned" on this belt anymore and you'd have to put them in line again. And since inserters dont care about the allignment of items on a belt, it seems rather weird to still want them sorted given all the things that ridicule it.

I agree with Yoyobuae. Most things can be worked around. In another thread someone has talked about a circuit that determines if the accumulators have enough power to make it through the night by calculating their discharge rate. If you know power will fail, you can safely shut down critical stuff. And then you can also always make circuitry that detects a fault condition, halts the machines and cleans up to bring everything back into a known state. It is just tedious and usually needs boatloads of combinators. However, if one doesn't give up a solution can be found in a lot of cases.

My automatic supply train I am working on will detect if you pick up or place stuff into the chests that it is using and will take that into account properly. It can't stand power outages so it's got an isolated power supply. I just have one rule for it: never manipulate the cargo wagon inventory manually. That is one thing that can not be worked around, because it is not yet possible to read the train contents.

Edit:
Brilliant stuff @ Yoyobuae! I have all inserters on a single multiplexed bus which controls stack size, sets filter and reads back hand contents all at the same time. It should be no problem to wire the shift register solution in front of my multiplexer. And then finally the single belt smart furnace could become a reality. How awesome is that!

[Frightning]

I figure I should get around to adding my 2 cents:

First off, I admittedly have made little use of circuits. I mainly have used them to regulate oil cracking (and I'm sure many other players have). I am aware of how to do quite a bit of more advanced stuff with them, but most of that stuff isn't practically useful to me (I do just fine controlling my factory designs with mechanical back-pressure, so I see little use for circuits in my games so far).

That being said, there are things I would like to do with the circuit network, that I haven't yet because they are either not possible, or else so complex to implement that it doesn't feel worth the hassle to even try, and that right there is I think where the OP and I would be in agreement: The circuit network can't do things it aught be able to do, and even quite a bit of the things it can do are disappointingly complex and/or intuitive to actually implement.

By way of examples, to help give the devs so suggestions on where to take things, here are some things I've wanted to do, why I haven't done them, and what perhaps could be added/changed that would remedy the problem, as I see it:

-Making a display to track how much of something is in storage: This is, in some sense, currently done automatically by the logistics system, but of course, this only works for items actually in the system's storage and passive provider chests. The problem isn't so much getting the count: that's easy with a few wires, it's displaying that number in a way where the player can see it 'at a glance'. Now this has been done, but creating displays is complicated and rather tedious (I did figure out how to make one with help from the forums, including from XKnight himself). The resulting display is also quite large (each lamp takes up 1 building square, so to get decently readable numbers, that's probably at least 5x3 per number; quite big actually). The solution to this is fairly simple imo: add displays as a buildable entity that are much more compact. There are already some nice ones in mods out there for the game, this is an example of something from a mod that imo ought be implemented in the vanilla game.

-Creating a system to dispatch trains to pickup ore (or pickup/deliver other items) only when there is a full load stored at the mine: The problem with this one isn't controlling the train itself so much as the fact that you don't gain any benefit over a mechanical back-pressure system because trains have set schedules, hence you still need at least 1 train per mine (or else having the train stop at multiple stations, which introduces its own set of headaches and ofc the train pathing is less efficient than the ideal dispatch system would be). Perhaps there is a way of doing this that I haven't thought of, but then the issue imo would be that it's quite unintuitive how to achieve the desired setup: some number of (small) mines, all served by 1 train which is dispatched to whichever mine has enough to fill the train (so as long as total mine output doesn't exceed train throughput, no backups), gets filled there, then comes and delivers back to base, (one could even have multiple trains and a 'waiting' area for trains ready for dispatch). Being able to set a train's next destination via circuit connected to the train stop would be a very useful feature (there would obvious have to be some consideration given to implementation, for instance, one would want the train to only visit that stop once typically, then continue with the rest of it's scheduled round, or similar) and would straightforwardly solve this problem.

-Another thing I've wanted to make, but haven't dared attempt: A smart assembly block. That is, a Requestor chest connected to some inserters and other chests and a Furnace, Chemical plant, and Assembly machine 3. Which be controlled by the circuit network so that: I could make a request for some number of some item to be made, it would automatically calculate raw materials needed (up to oil derivatives for fluids), and then deliver the raw materials to the chest (and fluids to storage tanks), after which it would assemble the materials into components and those into further components until it at last made the desired item. I haven't made this in part because I would expect it to be complicated to begin with, but it would be nightmarishly so with the current state of combinators, not to mention the myriad of potential problems a system like that can have in the present state of the game, plus the daunting (but understandably needed) task of hand wiring all the logic and manually programming all the (relevant) recipes. I wouldn't expect a project like that to be simple to do: it's exactly the sort of thing I would expect to appeal to a circuit enthusiast and the sort of problem that makes me wanna dive deep into learning the ins and outs of the circuit, but even the masters here on the boards have struggled with similar smart factory designs and most of them report that their designs have the potential to be messed up easily by a host of possible unforeseen causes (the inserter stack size problem is just the latest in a long history of such issues). The big problem with this in vanilla atm is that you can't set assembler recipes by circuit network, and there is a fairly understandable reason why: Where should the unused ingredients in the assembler go? I don't have an easy answer here, but I think something should be thought up to address this is a logical, usable way because the ability to set recipes opens a ton of doors for useful circuit contraptions (and something new to optimize: how to make everything you need on as few assemblers as possible).

This is by no means a census of things I've longed to do but haven't due to complexity, size, lack of robustness of the system, lack of features necessary to do it, and so on. Speaking to more macro level question of what to do about the circuit situation in a general sense, I think the main problem is that the circuit network is kind of like coding in Assembly, people hardly ever do that nowadays because it's too low level for most of what software engineers are trying to make. Much easier and more efficient to code it in C++ or Python or whatever. If the circuit network was remade in a way where many of the basic things you'd want to do with it were built into the functionality of the most basic components, then it would be both much more accessible, and perhaps even, more powerful than the current implementation (it'd certainly have way less design headaches!).

As an example of what I mean by higher-level functionality, consider the following prospective changes:
-All 3 current combinators merged into a single device called 'Combinator' (current tech level) with 3 modes of operation: compare, compute, constant. Would serve the function of all current combinator types with a single device, just the set the mode based on what you want it to do and voila, the rest works as it does now.
-New device called State machine (intermediate tech): It would have a configurable number of states (up to some reasonably small limit, maybe 5 or 10) as well as conditions for state change, and outputs associated with each state. The inputs would be used to trigger the state changes from one state to another. Vastly simplifies the creation of finite automata and other state-based systems.
-New device called Processor (more advanced tech): maybe 3x3 in size or so, more wire connection points than combinators and state machines, has an internal grid (maybe 10x10 or 20x20) similar to modular armor within which you could place State machines and combinators, configure them, and wire them to one another, and the Processor's connection points accessible in this menu from the edge of the aforementioned grid. The point being to allow for more complex systems to be made (relatively) compact (one of the reasons I feel the current circuits are janky is that combinators are freaking huge for how simple a component they are (I don't mind this for early level tech, but some miniaturization later on would be nice; consider the real world equivalents are literally microscopic with current tech). This would also enable more complex circuits to be built compactly, and would make organizing larger circuit designs much easier. Not to mention the convenience of being able to blueprint Processors for specific complex tasks and then being able to replicate them automatically with logistic bots (wiring, settings and all).

[Xeteth]

-Another thing I've wanted to make, but haven't dared attempt: A smart assembly block. That is, a Requestor chest connected to some inserters and other chests and a Furnace, Chemical plant, and Assembly machine 3. Which be controlled by the circuit network so that: I could make a request for some number of some item to be made, it would automatically calculate raw materials needed (up to oil derivatives for fluids), and then deliver the raw materials to the chest (and fluids to storage tanks), after which it would assemble the materials into components and those into further components until it at last made the desired item. I haven't made this in part because I would expect it to be complicated to begin with, but it would be nightmarishly so with the current state of combinators, not to mention the myriad of potential problems a system like that can have in the present state of the game, plus the daunting (but understandably needed) task of hand wiring all the logic and manually programming all the (relevant) recipes. I wouldn't expect a project like that to be simple to do: it's exactly the sort of thing I would expect to appeal to a circuit enthusiast and the sort of problem that makes me wanna dive deep into learning the ins and outs of the circuit, but even the masters here on the boards have struggled with similar smart factory designs and most of them report that their designs have the potential to be messed up easily by a host of possible unforeseen causes (the inserter stack size problem is just the latest in a long history of such issues). The big problem with this in vanilla atm is that you can't set assembler recipes by circuit network, and there is a fairly understandable reason why: Where should the unused ingredients in the assembler go? I don't have an easy answer here, but I think something should be thought up to address this is a logical, usable way because the ability to set recipes opens a ton of doors for useful circuit contraptions (and something new to optimize: how to make everything you need on as few assemblers as possible).

This is already possible and is actually fairly simple to implement once you get your head around it. Sure, wiring takes a long time but the reward at the end pays off. This factory can make every item I will ever need with barely any waste at all, as each item required up the production chain is made via circuit network control. It's also extremely power efficient thanks to the power switch



Sure, there are limitations to get EXACT amounts of items due to various issues such as inserter stack size and what-not, but in a game which is resource infinite I honestly don't think that level of precision is required and such features would only be used by a minority of people, hence I can see why it's unjustified adding these kind of things. Don't get me wrong I'd love to see these features, but I think the game suffers more directly from a lack of end-game content and would much rather see development being focused on that.

A major part of why I love this game is due to the circuit network so I am always eager to see more entities added to the network and as such allows new creations and contraptions, but I think these additions have to be really well thought out and contribute greatly to the gameplay before they are worthy of being put into development - this helps to reduce 'feature-creep'.

[Optera]

-Creating a system to dispatch trains to pickup ore (or pickup/deliver other items) only when there is a full load stored at the mine: The problem with this one isn't controlling the train itself so much as the fact that you don't gain any benefit over a mechanical back-pressure system because trains have set schedules, hence you still need at least 1 train per mine (or else having the train stop at multiple stations, which introduces its own set of headaches and ofc the train pathing is less efficient than the ideal dispatch system would be). Perhaps there is a way of doing this that I haven't thought of, but then the issue imo would be that it's quite unintuitive how to achieve the desired setup: some number of (small) mines, all served by 1 train which is dispatched to whichever mine has enough to fill the train (so as long as total mine output doesn't exceed train throughput, no backups), gets filled there, then comes and delivers back to base, (one could even have multiple trains and a 'waiting' area for trains ready for dispatch). Being able to set a train's next destination via circuit connected to the train stop would be a very useful feature (there would obvious have to be some consideration given to implementation, for instance, one would want the train to only visit that stop once typically, then continue with the rest of it's scheduled round, or similar) and would straightforwardly solve this problem.

If you don't mind using mods you may want to give my Logistic Train Network or Siggboy's Smart Train Deliveries with Combinator Magick a try.

[hansinator]

-New device called State machine (intermediate tech): It would have a configurable number of states (up to some reasonably small limit, maybe 5 or 10) as well as conditions for state change, and outputs associated with each state. The inputs would be used to trigger the state changes from one state to another. Vastly simplifies the creation of finite automata and other state-based systems.

I believe that is too advanced for many players.

-New device called Processor (more advanced tech): maybe 3x3 in size or so, more wire connection points than combinators and state machines, has an internal grid (maybe 10x10 or 20x20) similar to modular armor within which you could place State machines and combinators, configure them, and wire them to one another, and the Processor's connection points accessible in this menu from the edge of the aforementioned grid. The point being to allow for more complex systems to be made (relatively) compact (one of the reasons I feel the current circuits are janky is that combinators are freaking huge for how simple a component they are (I don't mind this for early level tech, but some miniaturization later on would be nice; consider the real world equivalents are literally microscopic with current tech). This would also enable more complex circuits to be built compactly, and would make organizing larger circuit designs much easier. Not to mention the convenience of being able to blueprint Processors for specific complex tasks and then being able to replicate them automatically with logistic bots (wiring, settings and all).

But I would love this one! I have thought about that previously and would have called it integrated circuit
.. or maybe Field Programmable Combinator Array (FCGA)
.. or maybe just combinator matrix or combinator grid or combinator array

[BenSeidel]

@Ssilk
I never thought that the developers would have been intentionally building in chaotic elements into the game play that were not there to be overcome. It's an interesting perspective and makes me wonder if that is their intent or if it is just something that has evolved through the development process. Also, The comparison between quantum mechanics and factorio is interesting. Unfortunately quantum mechanics is not chaotic, while factorio is, at least from the point of view of the player. It would be interesting to find out if factorio is probabilistic from within the game (from the point of view of the character).
Anyway, I thought I would exercise my ability go off-topic.

As for the circuit network logic, it's a tough one. On one hand I can see the arguments of both the pro and con's camp for the indeterministic nature of some of the entities.

What no one has really spoken about is that all these uncontrollable probabilistic traits are only related to the logistics network & throughput related issues. There are some exceptions, such as train loading and unloading, but they will be addressed in the 0.15 patch. You have to take into account that once you introduce a belt into the system you are able to control exactly how many items are to be moved from one area to another. This means that the only builts that suffer in an uncontrollable way from an indeterministic process the are builds that only use the logistics network. As the only builds that requires you to use only the logistics network are builds built for pure throughput: requiring you to beacon the crap out of the assemblers with as small amount of space wasted.

So my question is, Is going for both high throughput and high efficiency something that would add to the game? Because, as far I can tell, that is essentially what everyone is asking for.

My opinion is no. If we allow that then you will get builds that are, in every aspect, superior to any other build and will become the default for every factory. As it stands you have to choose. Do you want a zero waste factory or a resource gobbling machine? Are you a control freak or do you just want to make sure that the belts are full?

I still think that the circuit network can be improved, and I really do agree with many of the points in the thread, especially the points about the usability / UI aspects.

[hansinator]

You have to take into account that once you introduce a belt into the system you are able to control exactly how many items are to be moved from one area to another. This means that the only builts that suffer in an uncontrollable way from an indeterministic process the are builds that only use the logistics network.

That is only half of the truth. If you only use belts, you can control it exactly. As soon as you use splitters the problems start. Inserters are also not properly controllable, because they need an indeterministic amount of ticks to execute their rotation so you can not know reliably when it would be able to pick up an item. They behave differently across chunk boundaries and in different orientations. The circuit network does not know about orientations and chunk boundaries, unless you manually supply the information somehow. It all has been said before, just read the previous posts or look around in the combinator creations forum. So far however I have always found ways to solve the problems that arise. It is just inconvenient and requires complex circuits. My point is that it'd be nice if it would be simpler so you don't need a diploma in computer sciences to make circuits to control your factory reliably.

[Escadin]

I realize I'm kinda late to the party but this is a very interesting thread and I hope some people will at least consider the idea I came up with. Please bear with me because I haven't read all 3 pages but especially Twinsen's reply caught my interest.

Reading this thread I came to two conclusions about circuits:
1) They're unsatisfying because they have little impact on your factory (And I can relate. What good exactly are they when the factory works perfectly fine without them too?)
2) They have little impact because none of the typical puzzles in this game involve circuits

If anything has become clear to this point then it's that having a circuit logic capable of reading and controlling every detail of your factory is not feasable because it would mean the game runs twice in extreme cases and the circuit logic becomes an engine in the engine. I've read the call for a clear border line several times but a clear purpose would be more than that. A clear reason to use circuits not only suggests where this border is meant to be drawn but also encourages the use of circuits in the first place. It also makes it easier for the devs to focus on the important details you're supposed to control because they know what is required to fulfill said purpose. Choosing this purpose wisely they can also control how taxing the solutions become.
Let me give you an example:

We all know about the upcoming nuclear power. Well this is a fairly advanced technology and they already hinted at what the puzzle behind a good nuclear plant might be. It involves adjcency bonuses and pipes and of course, being a high tier technology said puzzle should be more difficult than those before. So why not take the full step and involve circuit logic in the process too? It would add another dimention to the puzzle which makes it more complex by requiring yet another game mechanic of your arsenal. Sounds fair and square to me.

How would this work?
Well it's obviously up to the devs to put their puzzle together but I have a suggestion which shows this is possible without breaking something important. They said they're still playing with the idea to have meltdowns but they aren't sure how. Well let me tie it all together for you:
Imagine the nuclear power works as they presented in the recent update.
Imagine the game calculates and regulates the power for you as usual.
Imagine doing exactly that, your plant and it's individual reactors can never run above a certain friction of it's max power (say 50%). Why? Because the actual output likes to fluctuate and the game plays it save so you don't risk a meltdown.
But what if you know it better? What if you can measure the current power of each reactor and control the whole chain manually - garuanteeing safety yourself?
Well if you actually can manage to build a circuit logic which achieves that (and that is the additional complexity, the additional part of the puzzle) maybe you can get more than 50%. 60%, 70% maybe even 90% if you're really good. And soon everybody will be sharing blue prints for a 90% nuclear powerplant or a 85% one which runs more stable even when attacked by biters or...

And of course, if you're not into that you can skip the extra complexity and just build a second plant or a bigger one at the (not irrelevant) cost of additional space and resources. Not to mention you'll be wasting half your uranium. Or in other words, all of a sudden there is a chance to save all that, resources, space and production costs using circuits in a clever way a.k.a. an actual effect on your gameplay experience and a noticable improvement to your factory.

What do you think?

[Yoyobuae]

If anything has become clear to this point then it's that having a circuit logic capable of reading and controlling every detail of your factory is not feasable because it would mean the game runs twice in extreme cases and the circuit logic becomes an engine in the engine. I've read the call for a clear border line several times but a clear purpose would be more than that. A clear reason to use circuits not only suggests where this border is meant to be drawn but also encourages the use of circuits in the first place. It also makes it easier for the devs to focus on the important details you're supposed to control because they know what is required to fulfill said purpose. Choosing this purpose wisely they can also control how taxing the solutions become.

There are many reasons to use circuits. Some are more accessible. Like oil cracking, or backup steam power. They are easy because the involve a static decision: IF condition THEN action. At worst you need hysteresis so something like: IF condition1 THEN enable_action, IF condition2 THEN disable_action.

Then there are others which are extremely challenging, like smart furnaces or smart belt logistics. Those don't just require making static decisions, but involve a process which takes time. And this is where things turn real ugly. Then you not only need to know WHAT to do, but WHEN and even HOW MANY. Need to go deep into sequential circuit logic to solve those kinds of issues, and need to deal with stuff like stack inserter bonus, complex inserter/belt interactions and loads of other "fun" stuff which continually gets in the way. And that's not even getting into the limitations of the circuit network itself.

A factory is a really complex system. And as you say it's not feasible to tackle all that complexity at once. But it is possible to create "islands of sanity", just enough to make really neat stuff with circuits possible. Some of my own examples:
https://youtu.be/cGfAFxHplnE
https://youtu.be/7d6rwMiO4u8
https://youtu.be/tFOyaQAEb9g

I always try to keep things "simple". But simplicity is relative here, because circuit network is such a clunky tool to do anything beyond simple static decisions. Someone posted the perfect analogy in another thread:
https://youtu.be/OpLU__bhu2w

We all know about the upcoming nuclear power. Well this is a fairly advanced technology and they already hinted at what the puzzle behind a good nuclear plant might be. It involves adjcency bonuses and pipes and of course, being a high tier technology said puzzle should be more difficult than those before. So why not take the full step and involve circuit logic in the process too? It would add another dimention to the puzzle which makes it more complex by requiring yet another game mechanic of your arsenal. Sounds fair and square to me.

I personally would would be a lot meaner

• Get rid of the adjacency bonus/boiler/heatpipe puzzle. That will only be solar ratio 2.0 (ie. boring)
• A single reactor accepts a number of fuel rods
• A single fuel rod in reactor produces some power output by heating water or making steam
• For each doubling of fuel rods in reactor the power output quadruples
• Reactor accepts up to 16 fuel rods
• Reactor can work 100% safe with only 4 fuel rods. Initially it's locked to only accept 4 (via locking slots, similar to chests)
• Fuel rods put in cannot be taken out until they are spent
• Circuit can read reactor temperature and number of rods as separate signals (something like how roboports output bots available/total)
• Meltdown (BOOM!) happens when temperature reaches some critical level
• Only way to cool reactor is to consume the power, or dissipate it (ie. cooling towers)

[BenSeidel]

You have to take into account that once you introduce a belt into the system you are able to control exactly how many items are to be moved from one area to another. This means that the only builts that suffer in an uncontrollable way from an indeterministic process the are builds that only use the logistics network.

That is only half of the truth. If you only use belts, you can control it exactly. As soon as you use splitters the problems start. Inserters are also not properly controllable, because they need an indeterministic amount of ticks to execute their rotation so you can not know reliably when it would be able to pick up an item. They behave differently across chunk boundaries and in different orientations. The circuit network does not know about orientations and chunk boundaries, unless you manually supply the information somehow. It all has been said before, just read the previous posts or look around in the combinator creations forum. So far however I have always found ways to solve the problems that arise. It is just inconvenient and requires complex circuits. My point is that it'd be nice if it would be simpler so you don't need a diploma in computer sciences to make circuits to control your factory reliably.

Ok, I see what you are saying. If i change the part of "only builds that suffer in an uncontrollable way from an indeterministic process the are builds that only use the logistics network" to "only builds that suffer in an uncontrollable way from an indeterministic processes are the builds that try to minimise space", would that suffice? As you said, all the indeterministic parts of the game are controllable, they just require a PHD to do, but my thought is: It's like that in real life. If you don't want to figure it out for yourself, go to the quick-e-mart and buy an off-the-shelf one.

Anyway, my point was that the game should offer you you a choice, control vs throughput.

[AssaultRaven]

I haven't worked with circuits much, but it sounds to me like the biggest single problem, inserters, would be solved with some kind of asynchronous control system for inserters. As in, being able to tell an inserter, "move X items", with the details of implementing that being left to the inserter. (This would presumably include grabbing less than its full stack size if needed.)

If there was a means of controlling them other than on-off, this could also allow telling them to move items forward or backwards.

The green ones, at least, are supposed to be "smart", right?