The sad state of circuit logic

[Yoyobuae]

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.

YES!!!

Super precise control where everything works exactly as you want will probably never be possible

That's to be expected. And besides, it would be no fun if it was too easy.

What's needed is little "islands of sanity" among the madness. Specially around logistic related stuff (belts, inserters, trains, bots, etc).

[MeduSalem]

ability to set the stack size of an inserter

Epic... Spoiler.

Probably more looked forward to by some people than the Nuclear Stuff



But apart from that I basically understand that super precise control is almost impossible without feature creep and a huge performance hit... And actually I don't really think that super precise control over absolutely everything is really necessary. It's only necessary with certain aspects and that's what people tend to complain the most about or suggest a lot.

What's needed is little "islands of sanity" among the madness. Specially around logistic related stuff (belts, inserters, trains, bots, etc).

I can only agree with that.

I think of them as interfaces that allow for controlled access to the otherwise asynchronous item flow.

[Optera]

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

Best news for 0.15 I've heard. This is the final piece of the puzzle I needed to make smart loaders, smart furnaces and so on work 100% reliable (together with my Inventory sensor)

[AcolyteOfRocket]

I must agree with the basic premise of the OP that circuit logic is in a bad way in this game. They look like a bolt on, that is then frigged by smart-alecs to psuedo-simulate relay logic to do some wierd stuff with marginal benefits to factory control at best. Because the rest of the factorio game is so good (well, maybe not biters ) they are visible as a real bad eyesore. They have the following big faults ;-

1. They are hard to comprehend - I had no idea how to use them until I went online for some detailed guide, the UI is so terse it was impossible for me to get them to do anything useful, and I have worked with industrial control systems to make a living in the real world.

2. They don't do what we want. Real controllers take a measured variable, apply a modifier and transmit a control signal as a controlled variable. Or they run a batch sequence. If you want to control, you need these things, and if you want to keep things simple, then you don't want to see to see being able to play a ticker tape message or run a video as a good thing, cos they are not.

3. Even what we have doesn't help. When the belt counter tells me a belt is full is it because I have high flow or stopped flow ?? Measurement in factorio is haphazard at best and without measurement you cannot control, only hope , ( or, in the real world, bullshit people).

4. Even laying out circuits is hard. The game seems to use the red/green wires to set up groups of entities that share data - fine. Let us see those entities in list form, instead of having to develop eyestrain trying to see if that wire goes to the inserter or the pole thats is in front of it. The graphical philosophy of showing wires on the screen is flawed and different ports on the combinators are hard to see anyway (I'm looking at you decider combinator, trying to figure out which end is your arse )

I get that there are limits to what you can do to maintain the scale the game needs to operate at, so maybe some things are not possible within that requirement. And anyway this a creative indie game still in alpha so not every idea will work out. We don't mind, hell, we like the game for these reasons.

But when the light is shone on the problem, maybe this is the time for a decisive design call - maybe its time to remove combinators as they stand, before you build too much on what is a flawed system.

[Yoyobuae]

1. They are hard to comprehend - I had no idea how to use them until I went online for some detailed guide, the UI is so terse it was impossible for me to get them to do anything useful, and I have worked with industrial control systems to make a living in the real world.

Agreed. They are closer to a weird, limited programming language than anything. Perhaps way too limited.

It is turing complete, so anything is achievable. But the complexity shoots up almost immediately, due to the strict limitations. Kinda like those super limited obfuscated programing languages:
https://en.wikipedia.org/wiki/Befunge

2. They don't do what we want. Real controllers take a measured variable, apply a modifier and transmit a control signal as a controlled variable. Or they run a batch sequence. If you want to control, you need these things, and if you want to keep things simple, then you don't want to see to see being able to play a ticker tape message or run a video as a good thing, cos they are not.

They can do that sort of things (because, turing complete), it's just not simple to do at all.

Sequences can be implemented as counters or state machines. There's some difficulty in building those out of the basic building blocks, and then interfacing them with factory elements (inserters, belts, etc) is a non-trivial task.

3. Even what we have doesn't help. When the belt counter tells me a belt is full is it because I have high flow or stopped flow ?? Measurement in factorio is haphazard at best and without measurement you cannot control, only hope , ( or, in the real world, bullshit people).

It's easy to take what belts do behind the scenes for granted. Belts are like a circuit network of their own. Taking an item off a full belt results in an instant domino effect upstream, merging across splitters and such, all the way to the producers creating a gap on which products can be inserted. Effectively an automatic supply/demand system, all for the cost of a few hundred belts (which is nothing really).

Problem with it is that it's just massively complicated. The code behind belts gets continual attention due to how CPU demanding it is. No hope to tackle the full complexity of belts with circuit networks.

Some compromise is needed. If belts are assumed to always be running and always be full, then circuit network control becomes much simpler. No longer need to wonder if belt is running or backed up, or guess how full it is.

Of course then you lose the automatic supply/demand system implemented by belts (need to re-implement it manually).

4. Even laying out circuits is hard. The game seems to use the red/green wires to set up groups of entities that share data - fine. Let us see those entities in list form, instead of having to develop eyestrain trying to see if that wire goes to the inserter or the pole thats is in front of it. The graphical philosophy of showing wires on the screen is flawed and different ports on the combinators are hard to see anyway (I'm looking at you decider combinator, trying to figure out which end is your arse )

Things would be much simpler if one could rearrange buildings without having to reconnect and reconfigure all the circuit settings again.

I always try to be organized from the start, but as the circuit evolves it gets difficult to keep the organization. Eventually I always have to resort to console commands to rearrange combinators into a more sane layout.

[MeduSalem]

Kinda like those super limited obfuscated programing languages:
https://en.wikipedia.org/wiki/Befunge

I expected brainfuck... https://en.wikipedia.org/wiki/Brainfuck

[Yoyobuae]

Kinda like those super limited obfuscated programing languages:
https://en.wikipedia.org/wiki/Befunge

I expected brainfuck... https://en.wikipedia.org/wiki/Brainfuck

Befunge has a 2D element, a bit like Factorio.


On a different note: Should circuit network embrace binary operations (bit shifting, bit filtering, etc)?

I find that many things are just a whole lot easier to do via binary operations than alternative methods. Other methods would either be very large, or use a ton of signals in parallel.

Supposedly binary shift will be added to arithmetic combinators in 0.15. But there's also need for bit testing operators in conditions. Maybe also a binary number input widget (gets old having to generate binary numbers in calculator program and copy pasting into Factorio). And some kind of binary display, it is possible to make a contraption with small lamps which displays binary, but that's kinda more complicated than it needs to be (also adds a cycle delay before output is shown).

[Optera]

When we get bit operations i hope we also get an option to display signals binary or hexadecimal.

[Hannu]

[*]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

I would not like this because then I would practically lose robot cargo size bonuses and would need many times more robots to keep throughput. I know that it would be able to solve problem by using more CPU to change orders during flight but if devs want to give more CPU for robots I would prefer better routing. If I have a large base I transport hunderds of millions of items and my CPU is struggling to keep tolerable UPS. It would not like to sacrifice performance to prevent five items to go to wrong place.

[*]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.[/list]

Someone gave very good idea in one discussion. There should be wire connection in rails like belts and it would give contents of single wagon if there was a wagon over track and contents of train if there was a locomotive over track.

[hansinator]

So many posts since I last had time to check the forum.. I'll try to answer the ones I believe are most relevant to what I wanted to say in the first place.

@ssilk
I don't fully agree with your analogy. It somehow fits the belt situation. I do like that belts are hard to control. But then there are those situations where things take 1 tick longer under circumstances that can not be detected by circuit logic - and this just breaks many concepts for no good reason. Fixing these things would also be invisible to the non hardcore circuit players. It can be done without adding new features (I'm referring to the feature creep that Twinsen referred to).

@Twinsen
Thank you for your insight. And thank you for the changes you already implemented. I'm absolutely delighted.

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)

That's also not what I would want. But the current situation is, as MeduSalem put it:

I'm not really satisfied with how half-baken it is implemented ever since the major changes that came with 0.13.

Half-baken. That's the right word. Because currently you cannot do much with the circuit logic besides creating fancy blinking lights (which is also a good thing, I do like DaveMcWs work in that direction) or realize a proper backup power system. I am not aware of many more things that you can currently do without an insane amount of combinators (maybe I missed another useful applicaton). Ok, when you add nuclear then there's that to control. But its very special and not versatile. I don't want more combinators or tons of options for each entity, but I'd like to do meaningful stuff with circuit logic. I also believe that it's not necessary to add more and more things.
What is necessary is to be smart about the things to implement such that it gives the most freedom while being the least obtrusive. And that's where Factorio could do better in my opinion.

That being said, it wouldn't be too much if every entity would have just one option menu for circuit logic. It would be consistent and wouldn't be too much for new players I suppose. Radar, rocket silo, assemblers, maybe splitters (please!) don't have one yet. I see potential for interesting things there. However, I didn't want and still don't want this thread to be a place to discuss suggestions for new features - it makes the discussion go into too many different directions. There's a dedicated forum for that

[*]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.[/list]

Someone gave very good idea in one discussion. There should be wire connection in rails like belts and it would give contents of single wagon if there was a wagon over track and contents of train if there was a locomotive over track.

That is a fantastic idea - at least the part with wiring the rails. I'm not sure if the difference between wagon/loco is smart. Maybe this could be discussed further in a suggestions thread. Can you provide a link to the discussion you mentioned?

[MeduSalem]

[...] That's also not what I would want. But the current situation is, as MeduSalem put it:

I'm not really satisfied with how half-baken it is implemented ever since the major changes that came with 0.13.

Half-baken. That's the right word. Because currently you cannot do much with the circuit logic besides creating fancy blinking lights (which is also a good thing, I do like DaveMcWs work in that direction) or realize a proper backup power system. I am not aware of many more things that you can currently do without an insane amount of combinators (maybe I missed another useful applicaton). [...]

Well I think toys like Dave's Movie Player etc have their place... At least they are a funny relief from the game sometimes.

I think the most useful part for the Circuit Network/Combinators is currently:

• Refinery/Cracking by controlling the liquid flow.
• Switching Power to individual factory departments on/off depending on demand

And that's exactly the kind of stuff I would like to do more with my Factory... like:

• If Items flow this or that way depending on a CN state. (Like setting a splitter or inserter filter and stacksizes etc)
• If this item or that item is crafted depending on a CN state. (Like Setting a recipe)
• Telling trains to go to this station or that station.
• Knowing what trains have loaded. (Though it might be better to know the contents of each individual train wagon)

Day-to-day stuff that is currently very hard to control or even impossible to do in Vanilla.

Some of the stuff like setting a filter for Inserters are a thing, and setting the stacksize or getting the train contents will be a thing... but some others haven't been quite touched yet except in some vague discussions about how they eventually might be done.

[hansinator]

Well I think toys like Dave's Movie Player etc have their place... At least they are a funny relief from the game sometimes.

I think the most useful part for the Circuit Network/Combinators is currently:

• Refinery/Cracking by controlling the liquid flow.
• Switching Power to individual factory departments on/off depending on demand

And that's exactly the kind of stuff I would like to do more with my Factory... like:

• If Items flow this or that way depending on a CN state. (Like setting a splitter or inserter filter and stacksizes etc)
• If this item or that item is crafted depending on a CN state. (Like Setting a recipe)
• Telling trains to go to this station or that station.
• Knowing what trains have loaded. (Though it might be better to know the contents of each individual train wagon)

I fully agree.

[Twinsen]

And that's exactly the kind of stuff I would like to do more with my Factory... like:

• If Items flow this or that way depending on a CN state. (Like setting a splitter or inserter filter and stacksizes etc)

Can be done by splitting a belt, connecting the 2 output belts and setting a contidion to wich side you want active

• If this item or that item is crafted depending on a CN state. (Like Setting a recipe)

Can be done similarly by having multiple assembling machines but only activating the output inserter of the one you want to produce.
If you want to turn on or off a block of assemblers, control output belts or use power switch.
Setting recipe for an assembler is on my todo list, although I believe it's one of those features that will cause more confusion and complication than good, due to having to deal with leftover ingredients. Factorio was never and probably will never be designed to work with "one assembler crafts many" since this limitation is at the core of Factorio's gameplay.

• Telling trains to go to this station or that station.
• Knowing what trains have loaded. (Though it might be better to know the contents of each individual train wagon)

Done to some degree in 0.15.

[hansinator]

And that's exactly the kind of stuff I would like to do more with my Factory... like:

• If Items flow this or that way depending on a CN state. (Like setting a splitter or inserter filter and stacksizes etc)

Can be done by splitting a belt, connecting the 2 output belts and setting a contidion to wich side you want active

It can be done, but the solution is messy because items will remain on the stopped belt. That in turn is hard to avoid. It can be done.. it just requires some more tricky circuitry. It is too hard for the average player, I guess.

Setting recipe for an assembler is on my todo list, although I believe it's one of those features that will cause more confusion and complication than good, due to having to deal with leftover ingredients. Factorio was never and probably will never be designed to work with "one assembler crafts many" since this limitation is at the core of Factorio's gameplay.

I have gained a lot of experience with the problems that arise from leftover items by building a belt-based smart furnace. I'll list the things to consider from my perspective:

• Control how many items are input into the machine. I have a very simple working solution for that (viewtopic.php?f=193&t=35380). Being able to set the inserter stack size would basically change nothing for smart furnaces or smart assemblers that are fed from belts.
• Check if a recipe is complete, i.e. if enough items have been put in to make one unit. For this one I rely on fast modulo. Achieving a fast (1-tick) modulo is possible but it requires 5 combinators for mod 5, 10 combinators for mod 10, etc... You need some ingenuity to implement it. A non-fast modulo solution is based on the fact that circuit signals are integer only and requires many many combinators as well. It's also not easy for non-programmers. This is a major source of inconvenience and makes the combinator count go up very fast. Having a native modulo operation would make such setups much easier.
• Determine what ingredients are needed for a recipe. This requires manual setup of constant combinators and a fair amount of other combinators to select the proper constants dynamically (as a basis for the modulo part). It would be very nice if we had a recipe combinator - or maybe even better (not sure) - if the assembler or furnace had a means to output what material it requires to produce an item or finish a recipe. If it would output how many items it needs to finish a recipe then one would not need the modulo and the whole thing gets so straight-forward that most players would come to a solution fast, I guess (spoiler: wire the what-is-needed-signal as a set-stack-size-and-filter signal to an inserter).
  
  edit:
• Measure what really has been put into the machine while controlling the stack size at the same time. The stack size solution I am using makes this non-trivial. If we can set the stack size of an inserter and connect both red and green wire to it (f.e. red to set stack, green to read hand), the inserter will read back its own read-hand-contents signal (twice!) which adds to the set-stack-size signal. That of course makes the inserter grab more (or less, it depends on if you use integer overflow) items than it should. A native set-stack-size implementation is able to solve this quite easily.

Unfortunately the furnace is not yet in a showable state, otherwise I'd post a link to give an example of what I mean. I still need to document it though.. But after months of struggling with the circuit network I need a break.

[Optera]

Control how many items are input into the machine. I have a very simple working solution for that (viewtopic.php?f=193&t=35380). Being able to set the inserter stack size would basically change nothing for smart furnaces or smart assemblers that are fed from belts.

Sadly this method only works when there are no larger gaps on the belt.
An inserter set to a specific stack size should wait infinitely until it has requested amount in hand.

Measure what really has been put into the machine while controlling the stack size at the same time. The stack size solution I am using makes this non-trivial. If we can set the stack size of an inserter and connect both red and green wire to it (f.e. red to set stack, green to read hand), the inserter will read back its own read-hand-contents signal (twice!) which adds to the set-stack-size signal. That of course makes the inserter grab more (or less, it depends on if you use integer overflow) items than it should. A native set-stack-size implementation is able to solve this quite easily.

You'd have to use pulse mode for reading the hand and store the pulse until a new one comes along... that is getting complicated very fast indeed.

Unfortunately the furnace is not yet in a showable state, otherwise I'd post a link to give an example of what I mean. I still need to document it though.. But after months of struggling with the circuit network I need a break.

I hope you'll post it once it's done.

[ssilk]

I don't fully agree with your analogy. It somehow fits the belt situation. I do like that belts are hard to control. But then there are those situations where things take 1 tick longer under circumstances that can not be detected by circuit logic - and this just breaks many concepts for no good reason.

Hm. Well, it's an analogy. Not more.

[But maybe in some centuries mankind finds out, that quantum physics works as is works, cause they see with some kind of particle-accellerator into the depth of space-time (10E-120 meters or so) and what they see are little items of information running around on connected surfaces. ]

Fixing these things would also be invisible to the non hardcore circuit players. It can be done without adding new features (I'm referring to the feature creep that Twinsen referred to).

I dunno. Not all things can happen at the same time. For you it looks eventually simple, but you and me have no idea, how that is really implemented.



All in all I must say, that this thread shows very much lack of knowledge. That is a critics to those, who say "Uhhhhhuuhhhuh, this circuits is soooo sad", but also a sign for the devs, that the game really needs some kind of tutorial ASAP.

[Yoyobuae]

Can be done by splitting a belt, connecting the 2 output belts and setting a contidion to wich side you want active

Could this be integrated into the splitter itself, somehow. As mentioned by hansinator above, having to stop the belt after the splitter causes non-insignificant complexities which are not really necessary. It would be so much easier if it was possible to wire up each splitter side with output enable/disable conditions . I don't even care about filtering options which are so frequently requested, simple enable/disable would do.

[hansinator]

Sadly this method only works when there are no larger gaps on the belt.
An inserter set to a specific stack size should wait infinitely until it has requested amount in hand.

It still works then but the inserter will pick up less than the stack size you have set.

You'd have to use pulse mode for reading the hand and store the pulse until a new one comes along... that is getting complicated very fast indeed.

A simpler solution is to use a single wire to set the stack size and read back the inserter-holds-in-hand signal. The inserter-holds-in-hand signal will cause the integer overflow which produces the stack size limit in the first place. This is done by adding a very large value. You can use a second combinator to subtract the same very large value which will give you the original inserter-holds-in-hand value. This way you can properly account what has been put into a machine.

Fixing these things would also be invisible to the non hardcore circuit players. It can be done without adding new features (I'm referring to the feature creep that Twinsen referred to).

I dunno. Not all things can happen at the same time. For you it looks eventually simple, but you and me have no idea, how that is really implemented.

I agree that we don't know how it is implemented, but that is another topic. I was saying that the average player would not notice the change and that it would not change the feature count. I was not saying that all things should happen at the same time.

All in all I must say, that this thread shows very much lack of knowledge. That is a critics to those, who say "Uhhhhhuuhhhuh, this circuits is soooo sad", but also a sign for the devs, that the game really needs some kind of tutorial ASAP.

I don't see how a tutorial could help with the topics that have been brought up here. There is already the combinator 101 and the wiki has lots of example circuit network applications. Or do you mean something different than circuit network tutorials? Maybe I'm misunderstanding something..

Nevertheless, I have the feeling that you want to defend the devs against criticism because of their good work that they have put into the game (again, correct me if I'm wrong). It's not that I (and probably the other people, too) want to attack them or discredit anything. If it leaves the impression that I am disrespecting their work then I offer my excuse for that. In the end it is also necessary that criticism is brought up and be discussed in a constructive way. I'd say the overall discussion is very constructive. So far we have heard very different perspectives in this thread and I hope everyone got a little wiser from that. At least I did.

[ssilk]

I don't see how a tutorial could help with the topics that have been brought up here. There is already the combinator 101 and the wiki has lots of example circuit network applications. Or do you mean something different than circuit network tutorials? Maybe I'm misunderstanding something..

Well, it's a free play game and follows this credo to the excess. But the devs cannot test all situations, they cannot know, how a player thinks.

For example:

Control how many items are input into the machine. I have a very simple working solution for that (viewtopic.php?f=193&t=35380). Being able to set the inserter stack size would basically change nothing for smart furnaces or smart assemblers that are fed from belts.

Maybe I'm playing too long Factorio or so, but I don't see so much sense in doing this. I believe that this is an interesting experiment and see some players think into that direction. But why?? ... There are so many other ways to build stuff, dozens, many, many more, that it is just not really needed. No real need in building this kind of machine.

Of course, some will cry now: "Cause I can do it. Cause it's interesting!"

No question. But when I tried to do things like that (and I really tried a lot) I come to some point and see, that it wouldn't work as expected and then I destructed the whole part and rebuild some simpler construction, that does the same, but it works and takes more resources to built or more space...
Unlike other players I have no problem with that. O.K. I'm a bit sad. Just a bit.

So I think I understand most of the arguments. But I think some players don't realize how many possibilities they have and that there is no reason to be sad. For example belt logic is a chapter on it's own: You can build otherwise complex logic just with belts and inserters and chests. Possibilities are really ENDLESS.

What I meant with the tutorial is, that the devs should show in such a tutorial, how they thought to use the whole stuff in this game. What possibilities a user has from their sight. How the stuff was implemented and why. That would bring players faster to success, if they are stuck, cause I see them thinking in a bubble.
The other possibilities would still exists and can be explored. But perhaps after they learned the basics.

Yes, basics is the right word! Comparison: Children learn in school addition before multiplication. In Factorio you are free to learn anything in (more or less) some order. That's fine. But I think there are players, which never learned addition and started with multiplication and now lament about how complex it is to add things. But I cannot be sure and I cannot ask them "Did you learn circuit lesson #2?".

And I know: This subject is about circuits. But - again - circuits are not thought to be needed or even complete, cause of the other possibilities you have.

So the point of this discussion is, that there are some players, that like to build circuits and don't like, that they can't do everything with them. No offense. I mean, it's a bit meta to discuss about non-existent problems of computer simulated logic circuits in the size of a washing machine.

(BTW: The Washing Machine Tragedy by Stanislaw Lem: https://books.google.de/books?id=1DNVzp ... dy&f=false )

Nevertheless, I have the feeling that you want to defend the devs against criticism because of their good work that they have put into the game (again, correct me if I'm wrong). It's not that I (and probably the other people, too) want to attack them or discredit anything.

No. No, really it's just that I don't see the point. Circuits is just one "world" of Factorio. Besides them there are others: Belts, trains, logistics, which are all about the size of the circuits to learn and really understand. They go just into another direction... There are players, that want to play only with circuits. Well, that's fine. But that system is currently not complete and not thought to be complete and perhaps will always have "flaws".
You need to see the factory a whole and not as power-delivery for the circuits to show videos. IMHO playing only with the circuits doesn't bring you really forward in Factorio.

If it leaves the impression that I am disrespecting their work then I offer my excuse for that. In the end it is also necessary that criticism is brought up and be discussed in a constructive way. I'd say the overall discussion is very constructive. So far we have heard very different perspectives in this thread and I hope everyone got a little wiser from that. At least I did.

Ah. That's cool. I don't see any need to defend them. I have my own opinion.

But I'm also wiser. I tried if there is something, which describes the kind of mathematical problem behind the belts and so on and I found this:
https://en.wikipedia.org/wiki/Integer_programming
which I found through the list of NP-complete-problems:
https://en.wikipedia.org/wiki/Karp%27s_ ... e_problems

It's a good question if Factorio belongs into that class of problem and if the game is a way to solve this problem in "linear time"...

[Yoyobuae]

You need to see the factory a whole and not as power-delivery for the circuits to show videos. IMHO playing only with the circuits doesn't bring you really forward in Factorio.

Well, it's a free play game and follows this credo to the excess.

Well, being a "free play game" means I can decide what "forward" means.

Anyone can make/launch a rocket (the game is designed for that). It's those things that games are NOT designed for that I've always found most interesting. There's basically two paths to go:

• Build BIG. Megabases fall in this category. Going for scales which bring the game engine to it's knees
• Building clever. Stuff no one else has though about yet. I tend to go for this kind of thing

The factory itself is almost irrelevant (I almost always play using creative mode). What matters for me is the ideas/concepts behind the build. Knowledge/creativity is what matters.

Besides, circuits are a relatively new addition to Factorio. There's tons more stuff to discover. It's not a bad thing a few players are overly enthusiastic about them. If we all treated circuits as the average players does, then the playerbase as a whole wouldn't fully explore it's possibilities, and the devs wouldn't know where to take circuit networks. It's our duty as players to exhaustively search for all possibilities, even if just for the sake feedback for the devs.

I think that's what this is all really about. It's not that we selfishly want our wishes to implemented. It's about the difficulties we continually run into, because we worry those difficulties could also hinder and discourage other players.

I personally don't care about the difficulties. I'll continue fighting thru every one of them.