The sad state of circuit logic

[hansinator]

Hi everyone,

recently I have became very disappointed with cirucits and when reading the forum I feel that I am not the only one. I wanted to create something useful with circuits and achieve better control of what my factory is doing. The goal was to increase automation and better utilize my assemblers, belts, robots, trains and furnaces.

The problem with factorio is that there are many things where you can not control the things precisely due to the somewhat lame game mechanics. It is very hard and sometimes impossible to control item flow down to a single item. One can barely control which path a single item takes in a splitter. You can not read the contents of a train (which is something I am battling with to build an automated supply train) - I have seen in another thread that this is already implemented for the next version. Then you can not exactly know how many items are in your logistics system. The roboport provides a readout but that does not include items that are in transit. You can not control how many items are delivered to a requester chest - it often ends up with extra items on a random basis. The list goes on.. Not knowing the state of things exactly is the same as randomness: it will yield unpredictable results. This makes precise control impossible. And for me it destroys ALL the fun. It also degrades the whole circuit logic thing to a toy that is mostly useful for making movie players and other non-factory-related gimmicks. This is sad.

Some things can be worked around but is means days or weeks of hard work and dozens of combinators. But this is a game and I'd prefer it to be more of a fun challenge. Don't get me wrong, Factorio is a great game, but at a certain point one has built everything and the challenge is gone - except for building complex circuits and smart factories or ever bigger factories.

I really hope a developer reads this. I wish you had a rule to check every change to the game mechanics to determine if it adds that sort of randomness (and breaks the ability to precisely control item flow) before implementing it. Like the inserter stack size change that is heavily frowned upon for the reason that it breaks control of item flow where it was possible before.

Edit:
Now that I have complained, I have seen that there's already a good discussion about some points in this thread: viewtopic.php?f=9&t=30853&start=100 .
Recently the poll descriptions there changed to indicate that some things have been implemented. It seems like we'll be getting the ability to read train contents. That's good news

Edit 2:
Based upon the direction the thread is taking I want to add an explanation for why I feel this is important: When one first discovers circuits they make a big promise. They promise that you can do almost anything and realize your wildest factory automation dream. Then when one takes that promise and tries to do stuff, the game mechanics slap you in your face. That broken promise seems to be a painful moment for many. After that people turn to the forum and make suggestions to improve the situation. The reaction then is even more painful. People say "write a mod" or dev's say "not going to happen". You earn even more slaps in your face

[Yoyobuae]

Yep, so true.

When making super precise circuit network logic all the little normally unnoticeable implementation details leak thru.

A couple I've recently ran into:

• Furnaces idle for 1 cycle when they finish consuming a fuel item and begin consuming the next. This resulted in the last furnace of my latest contraption to not have enough room to place the very last smelted plate to complete the full belt (8 slot gap instead of 9 slot). Had to an extra cycle of delay to output inserters to fix that.
• The number of cycles it takes for an item to go thru belt corners, side loading, splitters is extremely weird. For example, it takes 30 cycles to go thru the first splitter, but 31 cycles for each every splitter after that.
• From a fully compact belt (fast or express), have one inserter pick up items with stack capacity over one, and have another try to fill those gaps. The second inserter will randomly fail to insert, despite the gap for the item being clearly available.

And the list probably goes on and on.

I simply don't think Factorio is meant for this kind of stuff. These are probably the untested corner cases. But I also understand that not every obscure corner cases can be tested and fixed (there's other stuff with higher priority, there always will be).

[aober93]

Yea all the little things

[evildogbot100]

You do know many things you complaint are going to be implemented in 0.15 right? I think 0.15 going to add many train functionality like switching off train stop and reading train content. Besides, I think anything aside from dynamic train schedule is implementable with circuit network in the current version for trains.

[AssaultRaven]

I've always thought we should just have a Controller object that we can code assembly into. Something as powerful as a Comodore64. The current setup reminds me of how Robot Odyssey is called the hardest programming game ever, except that the reason it's so hard is that it's actually an electrical engineering game that you have to program with, and anything can be made unreasonably difficult by forcing the player to operate at a level of abstraction lower than is really appropriate for the challenge. The current situation with circuits is the same way. Some people think this is more thematically appropriate, but even then I disagree because, like...

Okay, you know how in Star Wars: Attack of the Clones there's that scene with the seismic charges that explode in that asteroid field, and then shortly later you hear their sound? This is wrong because there's no sound in space, but of course everyone knows that there's no sound in space and everyone also knows that both audiences and film-makers are both just supposed to ignore that in an action space fantasy movie for the aesthetics, and they both do, and everyone gets to enjoy their noisy space fights without wondering about what exactly is supposed to be "hearing" these sounds from across the void. But for me, this scene breaks that contract, because by adding in the sound propagation delay, they're explicitly calling attention to the fact that there is sound traveling across space, and so it can't be ignored because the film is slapping you in the face with it instead of just putting it out there and leaving you to enjoy the scene's sound design in peace.

Well, I feel that Factorio sets up the same sort of situation where things would be fine if not for the fact that the game is slapping you in the face with something that makes it seem wrong, when it forces me to manually wire together giant circuit components instead of just being able to have a single programmable board, in a way that, for example, redstone circuity in Minecraft doesn't, because if there is one thing in this world that we can be absolutely certain that the player character and their factories are able to produce, it is electronic circuits.

[Yoyobuae]

I've always thought we should just have a Controller object that we can code assembly into. Something as powerful as a Comodore64. The current setup reminds me of how Robot Odyssey is called the hardest programming game ever, except that the reason it's so hard is that it's actually an electrical engineering game that you have to program with, and anything can be made unreasonably difficult by forcing the player to operate at a level of abstraction lower than is really appropriate for the challenge. The current situation with circuits is the same way. Some people think this is more thematically appropriate, but even then I disagree because, like...

[...]

Well, I feel that Factorio sets up the same sort of situation where things would be fine if not for the fact that the game is slapping you in the face with something that makes it seem wrong, when it forces me to manually wire together giant circuit components instead of just being able to have a single programmable board, in a way that, for example, redstone circuity in Minecraft doesn't, because if there is one thing in this world that we can be absolutely certain that the player character and their factories are able to produce, it is electronic circuits.

One big issue with programmable combinators is that the naive implementation has no running time bounds. So one could potentially make factorio freeze with something like:

Code: Select all

while true then
  <some code>
end

"But then you set some running time limit", you say? Then where back into the whole abstraction leaking implementation details problem. How much run time would be allowed. How to even estimate the run time. What to do if run time runs out before program finishes.

There are games which do allow writing and running program code, but that's their main focus. Doing that sort of stuff correctly is quite a bit of work, pretty much a game engine of it's own.

And none of that solves the issues of controlling finicky aspects of the factory. Instead of spaghetti wiring you would have spaghetti code.

[hansinator]

Besides, I think anything aside from dynamic train schedule is implementable with circuit network in the current version for trains.

No. Let me explain.. Take a smart furnace as example. Or imagine a factory with an assembler that can change recipes (using a mod). Then you will need to precisely control how many items you put into the assembler or furnace, otherwise it will block when you change recipes. Most of these problems boil down to the fact that you need to move exactly, say 3 items.

Now, try to move exactly 3 items from one chest to another. Or from one belt to another. Or from a belt to a chest or vice versa. Well, you can not do that. At least not if you aren't genius like XKnight. But some problems are still unsolvable.

Some times the game will move less or more items. What it does is some sort of random. Randomness makes precise control impossible. That makes your smart furnace or your smart assembler setup impossible.

I've always thought we should just have a Controller object that we can code assembly into. Something as powerful as a Comodore64.

And this will not solve any of the problems, it will just make the game unappealing for the "simple minded player" I guess. However, if you want to implement it as a mod, I would use it.

Let me repeat it so that everybody really understands the core problem: Try to move exactly 3 items from one place to another without doing it manually. You can't do that.

Take a look at XKnights smart furnace: viewtopic.php?f=193&t=31766 . It is a good example of how you need to go to great lengths to make something barely work. And then it doesn't work if the furnace crosses a chunk boundary, because some inserters will take one tick longer to place an item across chunk boundaries. To make it work you have to go to debug mode and watch the chunk boundaries. Woohooo!

[orzelek]

If modded solution is ok then it should be easy to solve the item counting problem.
Bob's mo (logistics I think) separated research of inserter stack size so you can easily make a mod with inserters that always move 1 item. And then you can count your items one by one in any context.

[hansinator]

If modded solution is ok then it should be easy to solve the item counting problem.
Bob's mo (logistics I think) separated research of inserter stack size so you can easily make a mod with inserters that always move 1 item. And then you can count your items one by one in any context.

If you argument this way then one can remove all the circuit logic from the base game and put it into a mod. Because when you can not control aspects of the game, like moving items, then you can only use circuit logic for blinking lights.

Inserters are also not the only problem. If that would be solved, the next problem begins with requester chests that get more items delivered than you want. And don't forget that you can't read train contents. And the list goes on.

Edit:
That's why I wish there was a rule to check if a change to game mechanics breaks the possibility to work count-perfect.

[AssaultRaven]

One big issue with programmable combinators is that the naive implementation has no running time bounds. So one could potentially make factorio freeze with something like:

Code: Select all

while true then
  <some code>
end

"But then you set some running time limit", you say? Then where back into the whole abstraction leaking implementation details problem. How much run time would be allowed. How to even estimate the run time. What to do if run time runs out before program finishes.

There are games which do allow writing and running program code, but that's their main focus. Doing that sort of stuff correctly is quite a bit of work, pretty much a game engine of it's own.

I won't say that it's easy, but I don't think that would be one of the big problems. (A Commadore64 is probably way overkill though. I didn't remember that the C64 has a 1 MHZ CPU). If it's assembly, just execute a fixed number of instructions per tick, say 10, which corresponds to a 600 Hz system, or until a blocking instruction that can't be resolved on that tick is reached, whichever comes first.

Well, I can program a little bit. Maybe I'll just try implementing it myself as a mod.

And none of that solves the issues of controlling finicky aspects of the factory. Instead of spaghetti wiring you would have spaghetti code.

Unfortunately, there is a level of complexity in games like this where the appropriate interface really is a CAD suite or IDE, and Factorio passed that mark before it even had combinators.

[Optera]

Take a look at XKnights smart furnace: viewtopic.php?f=193&t=31766 . It is a good example of how you need to go to great lengths to make something barely work. And then it doesn't work if the furnace crosses a chunk boundary, because some inserters will take one tick longer to place an item across chunk boundaries. To make it work you have to go to debug mode and watch the chunk boundaries. Woohooo!

That's basically what it boils down to for me as well. We need to go to excessive lengths like XKnight's smart furnace or write mods like my Inventory Sensor to get the fine grained manipulation we want from a game like Factorio.

• Inserter need to be programmable to pick up x items
• Deliveries to a storage Chest need to be counted towards total items in logistic network
• Requester Chests need to recieve exactly the ordered amount instead of amount + drone stack bonus
  but when a player orders 3 plates he recieves 3 plates
• 0.15 will add train stop reporting total train inventory
  What about reading inventory of a single wagon? Mods do take a lot more UPS than native C code.

[golfmiketango]

Disclaimer: the following contains mostly speculation about the history of factorio and the intentions of the developers, which may or may not be correct. If I'm wrong about people's intentions, however, I might still be right about certain other aspects of my thesis. Anyhow please take it with a grain of salt.

I think the developers have discovered a balance issue, here. I presume that pocket crafting, belts and splitters were the first factorio logistics control systems and become the "gold standard" around which the game was balanced. One quirk of these systems is that there is essentially no way to automate something without a significant (but somewhat controllable) amount of overproduction. In this balancing model, the design of your factory -- particularly, the physical layout of belts and assemblers, has a very significant impact on the amount of overproduction that will occur, and under what circumstances various kinds of waste become unavoidable. Especially as you approach the later stages of the game, when overproduction of certain very expensive items becomes a possibility, minimizing this overproduction can become a significant challenge.

When flying robots were added, I suspect that a design was chosen to partially preserve these limitations. And, likewise, I suspect that as circuits have become a more and more powerful means of ameliorating overproduction, that increasingly large stack-size bonuses have been made available, so that, at the very least, the player feels they must make a choice between productive power and economical precision.

But, I am pretty sure, most players will always go for productive power given the choice -- in fact, I'd go so far as to say that it's not really much of a choice. Sitting around waiting for things is boring and it's just a video game, so, fuck it, moar things!

Only problem is that factorio also has a "hidden" economy of OCD triggers which make us feel that we need to fix things which are not fundamentally broken. For many of us, the end result is frustration. The inserter stack bonus issue is such a puzzle. I can tell you some ways to solve it, right now -- it's actually easy to solve. But you won't like them -- they won't feel "elegant" and they will leave you wanting a "cleaner" solution.

Perhaps such a solution is possible using the tools we already have -- it's hard not to feel that this is so -- but, let's face it: clearly, the problem of elegant precision-logistics in factorio is a very, very hard one and, indeed, there is no proof, yet, that it is solvable at all.

[Yoyobuae]

Perhaps such a solution is possible using the tools we already have -- it's hard not to feel that this is so -- but, let's face it: clearly, the problem of elegant precision-logistics in factorio is a very, very hard one and, indeed, there is no proof, yet, that it is solvable at all.

I'd say it's as hard as simulating factorio in factorio. If some circuit can fully simulate all aspects of some part of factorio, then that circuit can achieve 100% accurate control over it too.

For example, a circuit which could simulate bot dispatching logic could predict exactly how many items would reach a requester chest. Doing that, of course, is just silly.

[ssilk]

Interesting discussion.
I throw also some thoughts in:
I really like this kind of uncertainty. Someone above called it "randomness". Why? I would say the effects are "chaotic", not random, cause that means really something different.

I will try to explain the difference (you can leave out the spoiler).

Factorio and quantum physics

One of my hobbies is quantum-physics (I'm not more than a shadow of an amateur). But I'm good enough to see similarities between Factorio and quantum physics and what we can see there is a similar.
"Similar? This guy is crazy!"
Let me explain: You don't see the quantum physics - until you come to a certain point. If you go further that point you cannot longer say "An object is at this or that position", or "has this or that speed". Or - that follows from the before - "There are such many of this". You can only say "With a certainty of X % the object is here and has with a certainty of Y % this speed."
Or "with a certainty of X there are now Y items on this belt".

Well, quantum physics in less than 1 minute is a fail. I know...

But the point is: We have similarities in Factorio. For example: how many items are at any moment on a moving and fully compressed belt?

See https://wiki.factorio.com/Transport_bel ... s_yourself
shows under which condition there are 4 or 5 items on a lane. So the result is for one lane simple: With a probability of 4/9 there are 4 items on a lane and with 5/9 there are 5 items on a lane.

For a belt with two lanes this cannot be just added: There are states, where on one belt are 4 and on the other are 5 items. This isn't that simple to calculate! We can say that with a certainty of 1/9 the upper belt is shifted to the lower belt by 1, With a certainty of 1/9 it's shifted by 2. And so on.
So when the lower belt has 4 items, the upper belt has with a certainty of 5/9 5 items and with 4/9 4 items. And vice versa.

So the probabilities of how many items are on a belt look like so:

Code: Select all

left lane|    4/9    |     5/9       < right lane
---------------------------------
   4/9   |   8/18    |    9/18
   5/9   |   9/18    |   10/18

This can be read so: in 1/4 of the cases there is the chance of 8/18 to have 8 items on the belt. In 2/4 the chance is 9/18 and in another 1/4 it's 10/18. And you need that to multiply by 2, cause there are two lanes and this calculation needs to be made also vice versa.

Which results in 1/2 of 8/18 is 0.2222, 1/1 of 9/18 is 0.5 and 1/2 of 10/18 is 0.2778.

Well, the above is not so interesting and I'm not a mathematician, but the result of how probable is it, that 6, 7 or 8 items are on a belt looks like so:

Code: Select all

 items  |  probability that in one tick are that many items on a running, fully compressed belt
-------------------------
   6     |  0.2222
   7     |  0.5
   8     |  0.2778

The average amount is then 7.05544. [Which is astonishing, cause I had bet with myself, the average is 7.1111, see https://wiki.factorio.com/Transport_bel ... to_measure , which can also explained with the size of the items x required space: if an item is 0.28125 tiles long, you can put 7.1111 items on a belt (two lanes). Maybe someone can explain me that difference? Where is the miscalculation?]

Ufffz. I hope some will still follow my thoughts. Sorry, it's a bit complex, maybe I'm thinking too much around the corner.

What I want to say here is this: The belts look simple. At first. And they are such a simple system (32 slots, moving one slot per tick) and the rules, how they work are really well known. So you are about to think: "I know everything about belts, so I can do this and that, and I can control the flow". But that is only correct as long, as you don't want to do things, which are below the limit of the quantum physics. Or maybe better formulated: Once you begin to make calculations about how many items they transport in a given time exactly you come very soon into similar effects as in quantum physics: you can't make exact prediction how many items are transported in a time. Just estimations, cause it depends on, WHEN you measure, or when you begin and end measuring in reality.

And so it goes with many other things in Factorio, and the inserters and circuits is just one simple example where the things seem to go crazy and where the resulting machine doesn't work, cause of these chaotic effects.

You cannot do things, where you need to measure more exact as the (quantum) system provides. Think to a combination of belts and inserters: As long as the belt is fully compressed, the things are more or less predictable. In the moment, when the flow is reduced it is suddenly not longer predictable. It begins to behave chaotic.

With smart furnaces I think it is very similar, but the quantum effects are not really visible in that case, cause both (the inserter and the furnace) is in that case a very small quantum systems and that reduces the problem somehow to a simple algebraic problem.

So, what I think (may be discussed) is this: This is the first game, where the mankind can SEE quantum effects taking place.

Well, the above is eventually a bit off-topic.
But there are some conclusions, that follows from the above (and I hope, it's not so academic speak as above):
- The effects take place everywhere, but most visible in the belt mechanics. But all entities have some small amount of quantum effect included, which in sum gives this big, chaotic factory.
- Another example: The speed of information-flow (in the circuits) is limited. Every changes take one tick to have an impact anywhere else. Minimum. There is no way around that. This is like speed of light: No event-chain can happen at the same time and place.
- Trying to avoid or going around the effects is complex... (leads to complex solutions).

And, yes, no question for me - the inserters need some kind of more control.
But to be able for more control you need (n most cases) more CPU cycles. That follows from the fact, that information-flow needs time and avoiding time needs more information flow. And that last point is perhaps the whole problem: With only one entity that measures a bit more exact or can be controlled more exact it's no such a problem. But hundreds or thousands of such changed entities do a significant performance hit on the game-engine, if you increase the needed amount of CPU per entity just by one micropromille per tick.

[Yoyobuae]

@ssilk: It's always possible to calculate and predict exactly everything that happens in Factorio. The reason is simple: Factorio is deterministic. If it wasn't then MP games would always desync.

But just because it is possible, it doesn't mean it isn't hard. The deeper one goes into details the more the complexity level increases. Up to the point where the complexity would be as high as the Factorio engine itself.

Belts are, in fact, quite easy. It's entirely possible to iron out a non compressed belt into compressed packets of items. Those compressed packets then become predictable:
https://youtu.be/aq85okkr3JI

A belt lane can be simulated by a simple shift register. Each tick belt advances by N slots, and shift register advances by N bits. Same thing.

Given an item in belt at some position, an inserter always takes the same amounts of cycles to pick the item up and place it. Again all predictable delays which can be simulated.

Same with furnaces smelting, assemblers crafting, etc.

The issue are the little implementation details that leak thru. As I mentioned above. Those are complexity that needs to be accounted for, or simulated for the control circuit to behave reliably. Complexity is the enemy of large scale logic circuit control. It turns an initially elegant and understandable solution into a incomprehensible mess.

[ssilk]

@ssilk: It's always possible to calculate and predict exactly everything that happens in Factorio. The reason is simple: Factorio is deterministic. If it wasn't then MP games would always desync.

Well, I didn't say, that Factorio is not deterministic. I say: If you look deep enough into simple looking systems you'll find chaotic behavior.

Those compressed packets then become predictable:
https://youtu.be/aq85okkr3JI

Increase amount of measurement and chaotic behavior disappears. This video-example is not longer measuring one belt, it measures 10 belts. And only one lane. So it is simple to count: With 9 belts you can measure always exactly 4 belts, that contain 4 items and 5 belts that contain 5, so 41 items. Plus either 4 or 5, so it is always either 45 or 46 items. That is good enough in that case to keep the control.

The issue are the little implementation details that leak thru.

Which are coming from not being able to measure/control exactly enough (you can measure only whole things). (Which behaves like quantum physics)

It turns an initially elegant and understandable solution into a incomprehensible mess.

Exactly. This remembers me to that:

[Yoyobuae]

Those compressed packets then become predictable:
https://youtu.be/aq85okkr3JI

Increase amount of measurement and chaotic behavior disappears. This video-example is not longer measuring one belt, it measures 10 belts. And only one lane. So it is simple to count: With 9 belts you can measure always exactly 4 belts, that contain 4 items and 5 belts that contain 5, so 41 items. Plus either 4 or 5, so it is always either 45 or 46 items. That is good enough in that case to keep the control.

There's no chaotic behavior. It's only chaotic if one is not willing to try hard enough to figure it out.

I could probably get reliable measurement off a single belt tile, it just would be very complicated.

Saying "it's chaotic" is just the lazy way out.

"The devs don't play dice with Factorio".

[MeduSalem]

I'm with hansinator...

But I guess my previous posts all over the forum have made my opinions about the Circuit Network pretty clear already. I'm not really satisfied with how half-baken it is implemented ever since the major changes that came with 0.13.

The circuit network on its own/as a standalone may be designed quite flexible, which is good, but the interaction/interfaces with the actual factory elements like Inserters, Trains, Logistic Network, Machines is not where it should be to make the Circuit Network actually useful. Currently it feels like the Circuit Network could be its own game because it doesn't really feel well integrated with several core gameplay elements.

Half the time one lacks the necessary information to work with, with no way to get it, so you have to measure things by rule-of-thumb estimates
And even if one manages to get some information the other half of the time one lacks the necessary fine-grained control over the machinery, inserters, trains, logistic network, etc.

That in turn makes it either impossible to implement some things or they become so ridiculously complex that they stop being fun or would require a master degree in programming to understand, which render these kind of contraptions inaccessible to many players. It includes me too, because I have absolutely no clue how certain of these ridiculous contraptions others came up with are even working and I don't feel like copying & pasting blueprint strings all the time without understanding something because that takes away from my fun I'm having with the game as a player.


To sum it up... Currently getting the Circuit Network to work with certain other gameplay aspects is like trying to wipe one's ass with a cactus. Yes, you might manage to get it to work but it's only a painful rather than enjoyable experience... and that's a problem.

And contradictionary to what some people might believe mods just won't be able to miraculously patch everything together that is currently lacking.

But let's see how some of the improvements that come with 0.15 will turn out. It will probably solve some things, but probably not all of the complaints.

[DaveMcW]

I could probably get reliable measurement off a single belt tile, it just would be very complicated.

Yellow or red belt, yes. Blue belts are impossible to measure reliably unless you do a block of 9.

[Twinsen]

Interesting topic indeed.
Warning, this is more of a personal blab, don't take it too seriously:
I've seen this urge for extremely precise logistics and micro-management in Factorio.
I often see new players desperately try to design setups where belts never back up, where the number of items being put on the belt is the same as the number of items being used. But Factorio was not designed that way. Why? No precise answer, but one of the reasons is FUN.
Very precise control means more complexity and more complexity is not always fun. And there is also this element of chaos. There are an incredible amount of things happening and interacting with each other. A item is moved on the belt, an inserter tries to pick a item using natural motion, while doing so it consumes a precise amount of electricity that is generated by a steam engine with heated water from boilers heated with coal placed by some other inserter(and I can go on...); meanwhile laser turrets are firing, creating a spike in electricity, making your lamps flicker and making your inserter slow down, putting that ingredient in the assembling machine later than expected. Imagine having to precisely understand and control all of this, it would be too much, it wont be a fun game. All you have to do is place a output inserter and a input inserter and it just works, you don't need to deal with too many details. But you can see all these things things happening and interacting with eachother, even if they are not under your precise control. This makes the game look cool, complex and alive. You look at the complex factory and say "I built this!", you follow all these complex interactions and sometimes optimize and improve some things, as far as the game lets you.
This is where seasoned players come in. Dedicated Factorio players will always want more options, more features, more control, but the game has to stop somewhere. The place where we draw the line is where we think the game is most fun for everyone. I always ask fellow designers to look at the game elements from the perspective of the new players. Image we added all the possible controls, you open the GUI of the inserter and suddenly you see 20 options and sliders and configs, most of them requiring paragraphs of explanation to what they do.
Imagine we took 90% of the suggestions this forum and implemented them in the game. After every added feature you will say "the game is better now". Then at the end you look at the game and see that it's a massive mess of features that create a bloated confusing game. (Feature creep)

And then there are the circuit networks. Because it's complexity you think it's the next level, you think now you can finally fine tune EVERYTHING that you couldn't before.
- It tries to go in that direction, but again it has to stop somewhere. Like before, you can't just open an inserter and see 10 different modes of operation all with their different options. I try to add the minimal amount of options for maximum amount of control. The idea of the combinators and circuit network was that you make simple controls(turn off that pump when oil > 1000), but as usual everyone wanted more so more features were added on top of that.
- The circuit network is still like an optional addon of the game. It is build on top of the existing base game. Implementing a feature in the circuit network will never change the gameplay of the base game into something worse just so the circuit network would be better.
- Similar to the point above, the circuit network tries to have as little CPU impact as possible on non connected entities(One of the great features of Factorio is the ability to build huge factories). Sometimes this becomes tricky as a more customizable entity behavior means more processing power required.
- Trying to add fine control to something that was never designed to have fine control is not easy.
- And there is of course programming time. I'm the only developer working on the circuit networks when more important tasks are not on my list. Sometimes bigger features and fixes are more important than small customization features.

The game is still in alpha. Many of the things mentioned(train contents reading, basic train control, ability to set the stack size of an inserter) are done or to be done for 0.15. After we see how it works out and how players react, more will be added. Super precise control where everything works exactly as you want will probably never be possible, but I will try to go in that direction wile keeping the game fun and understandable for as many players as possible.