Friday Facts #122 - Better circuit network (Part 1)

[MeduSalem]

When we can connect the Assembling Machine to the Circuit network to control what they should build would be my dream ...
Then i can make a full automatic fabric that build what it need without that from each type 1 Assembling Machine are needed.
And progamable smart Inserter (Filter) whould be also nice.
Set the smart Inserter to "Signal" then it filter what came as signal.

But the new features also be great ... when we can have it to play with it
Thank you dev team for the great work you make!

That would actually be one of my dreams for using the Circuit Network... to create multi-purpose assembly lines. Using the circuit network to send all the necessary signals to program the assemblers to different recipes as well as inserter filters would really be something I look forward to.

Currently the only "assembler type" which allow for such a functionality are furnaces because they adapt their recipe automatically depending on the input resource. That said I am an expert on creating multi-purpose furnaces so I know that there is an additional problem of reusing the same furnace to smelt a different resource. The problem I am talking about is:

Inserter Stacksize Bonus.

The inabillity to adjust wethether an inserter should grab 1, 2, 3, 4 or 5 items from a chest is eventually what turns multi-purpose assemblers into a nightmare. Because if you don't insert the exact amount of resources expected by the recipe it might lead to a deadlock where the assembler can't craft the item or is stuck with "rest material" for all eternity, unable to change the recipe to something else.

This problem can be best seen when trying to build a multi-purpose furnace smelting all 4 available resources (Copper Ore->Copper Plates, Iron Ore->Iron Plates, Iron Plates->Steel Bars, Stone->Stone Bricks). The Steel bars as well as the Stone Bricks require more than 1 source material. Stone Bricks for example expect exactly 2 stone to craft 1 brick. If the inserter remains as stubborn as it is and inserts 5 stone instead of 2 or 4 then you will be left with 1 stone in the furnace and then the furnace is unable to switch to another recipe and it doesn't accept another resource other than stone anymore without manual intervention.

1) So if programable assemblers/furnaces/inserters ever become a thing then inserters would have to be changed in such a way that they are intelligent enough only to grab resources so that they don't leave residuals in the assemblers. Otherwise it would prevent the assembler from being reprogrammed as the stuck material can't be processed into something.

2) Another approach would be that assemblers/furnaces connected to the circuit network actually output how many resources they already have inside them so an inserter may stop inputing further resources causing uneven amounts. But even that would require to be able to override the inserter stack size bonus.

3) Or there could be a way to remove residual material from the assembler by a secondary output inserter. If I would be able to extract uneven amounts of stone from the furnace, like when an inserter accidently put 1,3 or 5 stone into the furnace then the problem would be gone as well because I could remove the residual with the secondary output inserter and put it back into the resource cycle to be processed somewhere else, rendering the assembler/furnace unstuck and thereby ready to be reprogrammed to a different recipe.

4) Another solution I came up with is that assemblers could have something like a resource buffer, like a small chest with stacks for example 10 different items that is built inside them. Depending on the current recipe it would draw from the correct items and leave the others alone. It would allow for a context switch without having to remove or worry about any residuals left inside that buffer. Call them smart assemblers/furnaces if you want to.

That ugly side effect of the stubborn Inserter Stacksize Bonus is a problem I have been stressing for about a year now. So I had a lot of time of thinking about possible solutions and I guess the easiest one would be to go for number 4) as it offers a lot of potential.

It may not be a prominent problem now but if programable assemblers ever come to existence it will be the biggest problem because with the dozens of recipes out there all having different amounts of resource requirements the problem would become really serious.

[NPE]

@vaderciya: I learned about combinators from this forum post https://forums.factorio.com/forum/vie ... 18&t=14556,
Combinators 101 by GopherAtl.

[vaderciya]

@vaderciya: I learned about combinators from this forum post https://forums.factorio.com/forum/vie ... 18&t=14556,
Combinators 101 by GopherAtl.

Thank you! I appreciate it

[DOSorDIE]

This problem can be best seen when trying to build a multi-purpose furnace smelting all 4 available resources (Copper Ore->Copper Plates, Iron Ore->Iron Plates, Iron Plates->Steel Bars, Stone->Stone Bricks).

Thats not a problem.
Look here i have this and it works without problems ...
https://forums.factorio.com/forum/viewtop ... 89#p123691
Smartsplitter with wires to the chest is the solution ... and with the Stack Bonus:
When you have Bonus 2 you can move 3 items from chest to chest ... so use 2 chests (2+3=5).
From Belt it takes only 1 so no probem to limit it here.


Dont think so complicate ...
With the programable Assembling Machine will the only problem when something is in it what happend with it?
Will it simply gone or it will only change when its emty ... the rest is not a problem that combinators or smart inserter cant solve.

[Marconos]

Really enjoyed this weeks FF and can't wait for the 0.13 release.

Glad you are changing the splitter mechanics, they have always felt a little off to me.

Keep up the great work.

[MeduSalem]

This problem can be best seen when trying to build a multi-purpose furnace smelting all 4 available resources (Copper Ore->Copper Plates, Iron Ore->Iron Plates, Iron Plates->Steel Bars, Stone->Stone Bricks).

Thats not a problem.
Look here i have this and it works without problems ...
https://forums.factorio.com/forum/viewtop ... 89#p123691
Smartsplitter with wires to the chest is the solution ... and with the Stack Bonus:
When you have Bonus 2 you can move 3 items from chest to chest ... so use 2 chests (2+3=5).
From Belt it takes only 1 so no probem to limit it here.


Dont think so complicate ...
With the programable Assembling Machine will the only problem when something is in it what happend with it?
Will it simply gone or it will only change when its emty ... the rest is not a problem that combinators or smart inserter cant solve.

Well I have already replied to your post in the thread over here: https://forums.factorio.com/forum/viewtop ... 70#p123848
Didn't see your post here until now.

Believe me when I say from 1.5 years of experience dealing with multipurpose/smart furnaces that the solution of putting chests in between two inserters and hooking them up with wiring to limit the amount of input source items just because the assembler/furnace would choke on its own limited failsafe capabilities of being unable to deal with residual items just sucks in my opinion because it wastes a lot of space and time people could spend on other, more fun things. So in the end almost nobody would ever use it if it means such an overly complex contraption for something that could be done way more elegant if the game would just provide some little "help".

Also the more resources are involved the uglier it gets. I played around a little bit with mods like DyTech and Bob's Mods and... yeah... "GAHHH... To hell with this crap"-feeling all the way with multipurpose furnaces because of how complicated safe control of item flow gets. So I have quite a bad gut feeling already because of the entire "inserter stack size bonus" or "residual items"-problem not being resolved in a usefull manner.

The Devs would have to work their way through the stacksize bonus problem or how to deal with the overflow/residual buffer items to make it a worthwhile experience. There is no way around that if they ever intend to hook the assemblers/furnaces up the circuit network for full "programing flexibility".

From my standpoint there are two possible perspectives:

• Making the stacksize bonus a hardcoded global research upgrade with no way to override it for local inserters is just a problematic design choice that makes controlled item flow difficult, if not impossible in that matter. The same goes for the Robot cargo/carrying capacity upgrade (I explain further below why). One could solve those problems by giving the option to set each individual inserter to their own stack size values. Or setting the robot cargo capacity for a particular logistic network to different values than the global one. In any case it would only be a viable solution if the quantity of a particular source item doesn't exceed 5. If it needs more you are out of luck and you need some ridiculous contraption again to count the items. Also there might be a conflicting situation where a recipe switch may become impossible because of how one inserter always spams the slots, not giving the assembler enough time to empty everything before trying another recipe switch, etc. That's one side of the view.
• The other side is:
  "Would it be better if the items in the assembler/furnace buffer slots are allowed to be semi-independent from the current active recipe?"
  "What if I put 6-8 buffer slots in the assembler and told the assembler it is allowed to accept specific items (like filters) for each of those slots?"
  
  With Semi-Independent I mean you can specify for example Iron Plates, Copper Plates and Gear Wheels as buffer items (similar to selecting a filter in train wagons). First you start Recipe A which only needs Iron Plates and Gear Wheels and doesn't touch the copper plate stack while being active. Then comes a circuit network signal to switch to Recipe B which needs for example Iron Plates and Copper Plates and while being active it doesn't draw from the Gear Wheel stack. Then comes signal for Recipe C which draws from all three stacks and then again back to Recipe A or whatever the Circuit Network tells the assembler and as long as the source items required for the recipe are specifed in the buffer slots.
  
  It would allow to switch the recipes on the fly depending circuit network signal without risking the assembler to get stuck with residual items and without losing what is in the buffer since the item buffer is independent from the current recipe. The signal itself could be the recipe. Like if a signal comes on a particular item channel it means the assembler should use that item as a recipe. If the value on the item channel is different from 0 it could specify an exact amount of how many items it should produce before retiring the recipe, if it is 0 it continues to produce that item infinitely as long as the signal exists or something like that.

I looked into the problem at least a hundred hours while working on multipurpose a.k.a. "smart furnaces" and found the inserter stack size problem and caused residual items and the contraptions needed to overcome the limitation to be way too unfun and a burden to just tell the player "deal with it".

Also I came up with dozens of approaches and the only one I found to be working is with the chest in between two inserters (follow the link above to see exactly what I am talking about), one of which is picking stuff up from the belt one by one to gurantee no item overflow in the furnace, thereby reducing the max production speed to belt-grabbing fast-inserter speed, rendering beacons and Speed Modules unuseful in the process. Not only that, it basically doesn't even work with Robots and requester chests that way because they don't deliver items one by one but rather in packs anywhere between 1-4 even on the highest research level causing an another unforseeable problem. So with robots you would have to sacrifice even more space to overcome the Robot carrying capacity problem.

Not to forget that the contraptions needed to get around the problem would only get worse considering that not all of the recipes are as easy as the ones used by the furnaces. Some of them are using up to 5 different items with varying quanitities. It will probably get so ugly that it might even be futile trying to implement programable assemblers/furnaces in the first place if the only way to gurantee controlled item flow is by building such an item counting contraption for each source item of all the possible recipes the assembler could switch to over the course of its circuit network programing.

The stack size bonus/residual item problem is already so prominent that I think the problem is severe enough to justify an overhaul of the stack size bonus system or how to deal with residual items if programable multipurpose/smart assemblers/furnaces ever become a development goal.

And in my opinion having smart assemblers/furnaces with 6-8 slots (with filter) designated for selectable buffer items from which multiple recipes (selected by circuit network signal) could draw their required amounts is actually not that bad of a solution. On the contrary, one could leave the inserter stack size bonus as it is. And in my opinion it would still offer additional puzzle solving problems of how to get all the required source items into the assembler with the limited space available around the assembler and how to deal with the finished products all being output to the same output belt. And also the necessary Circuit network logic to switch between recipes, control the flow of source/target items, etc.

I am the last guy to demand ridiculous features, some people might know that already because I rarely suggest new over the top features. Instead I rather try to approach a problem from a logical perspective and if there are "reasonable" other solutions to a problem I am willing to accept them. But in this case I say the way how the stack size bonus or the overflow/residual buffer items are dealt with are one of the necessary things to overhaul should programable multipurpose/smart assemblers/furnaces controlled by circuit network signals ever become a thing. I say it because of experience and with the current implementation the experience was... not fun.

If the devs never intend to hook the assemblers and furnaces up to the circuit network to program them via signals in the first place, well then the entire discussion about the problem is purely hypothetical anyways. Though I would like the feature of being able to tell an assembler or furnace on the fly what recipe to use depending on a circuit network signal. Would offer the ability to build some mind boggling factories and would actually give the circuit network capabilities some sense beyond controlling oil cracking.

[ske]

[quote="MeduSalem"][/quote]

Is there a mod with smart/multipurpose Assemblers/Furnaces?

[mrtux]

I like the light colors in vanilla (used a mod until now, but that's not the same as the light colors were static); also taking the color from the circuit network. There are coloured signals, it is logical to use them.
In this sense, I am always for less options in a UI window and more to be built with "real" factory stuff.

A suggestion: allow the train signals to be set by the circuit network in the same fashion: enter a red/green/orange/blue circuit signal and let the signal show that respective value (also make the preceeding signals behave accordingly).

[The Phoenixian]

I also have kind of a design rule to try not add new entities in the game(not just combinator entities, entities in general), for a number of reasons:

1. It's easier to get into the game without being overwhelmed by an unreasonable amount of content.
2. One of the core fun things about Factorio is that you can combine few things in many ways. It's fun when you discover that you can use or connect an entity in many different ways.
3. Cleaner toolbar and inventory.
4. In the end game, some people like to have a factory that makes all the possible entities in the game. Too many entities means unreasonably big manufacturing location.

I'd like to make an argument against some of these points, at least in the extreme form. Certainly, minimizing duplicate items is good, but as things stand at the moment it feels like there's a lack of items in Factorio rather than a surfeit. (If you're just talking about having 20K types of belts though? Yeah, no argument.)

So thus, for the sake of argument.

1. Factorio already has a tech tree as a really excellent way of keeping you from being overwhelmed and giving you only one or two new things to play with at a time.
2. I have no problems with this: It's a good argument against unnecessary propagation of subtypes. (IE: belt types of each tier have one belt, a splitter and an underground belt, and it's enough to do basically everything you'd ever need. Likewise you could have more inserters, but it would have to be part of a truly new or specialized sector of the factory, like the large bridge crane, to really add much.)
3. Again, I'm okay with this as an argument to reduce subtypes of items. Not so much for reducing the total types of items to build, as you can always put away the items for one job and take out the items for another.
4. If anything the factory that produces everything strikes me as a reason to add stuff, not limit it. Certainly the aforementioned "20K belt types" hyperbole means unreasonable sizes, but if the player is challenging themselves like that... why not add more challenge?

[RobertTerwilliger]

Many people have asked for logic combinators, bit combinators, timers, etc.

Come on! All these functions can be made using units we have already!

Logic: set of logic units, that check every rule used, and outputs, say, signal A=1. Next unit depends on logic operator: "AND" is "={connected inputs}"; "OR" is ">0"; "XOR" is "=1" etc.
Bit combinators: nothing to explain - uses same units operating only at 2 levels "0" and "1"
These can be quite massive, depending on how complex the task is. BUT these are not vital items. In fact, this is more exotic feature for guys who want to do some programming just for fun. And most guys who don't use circuits won't do it with new elements as well.

Timers are also can be done quite easily.
For example, simple cycling timer is:
=A,B=>[A=A*B]-A->[A=A+1]-A->[A<X then B=1]-B->output
|===<==A,B==<===A,B==<=|----<---B---<---B--|
where
A is timer count,
B=0 is reset signal that is also used as output (in most cases output will require inversion ),
X is time value (in ticks) that specifies timer reset (that is also can be variable, provided as an input)
Also it is easy to add quite infinite "phase" points ( [A=Y then output D=1], where Y<X etc), so timer will provide specific complex cycle that will trigger outputs in specific timed sequence.
Also it is possible to modify this timer to be non-cyclic by removing B feedback and using input binary control signal.

And now consider I haven't dug deep into possibilities of current circuit system - I'm just an amateur who just knows tiny bit of programming and binary logic&math.

New elements may make some modules more compact, but I agree

because of the reasons mentioned above, I believe it is not worth it

It's better to give circuit system more practical usage. Because now it has very few practical usages:
- limiting items in chest not equal to stack (say, 50 green circuits etc)
- having a chest with multiple limited items (quite unusual need though)
- distant item stock monitoring (ergonomics only for now)
- liquid redirection
- liquid 1:1 splitter (2 pumps with values [A=1] and [A=0], 1 simple clock (self-feedbacked logic element [A=0 then A=1])
- inserter-based power failure detector
We know it is planned to make circuit-controlled stations, and with appearing of power switch we surely expect to have accumulator charge value as an input - because inserter-based power failure detectors are ugly and don't prevent failure - only deal with it after it occurs X_X

[ikarikeiji]

Changing the splitters to per lane sounds reasonable, but please please please make it so that mods can create alternate splitters that go per item like they do at the moment.

Because now that I've seen this I don't ever want it to go away

[JMBarbarossa]

I get what you guys are saying about not having too many entities.

However, after going through so much of the game, I feel like I wish there was more complexity in terms of different resources to mine and different kinds of miners/resource node types to exploit. Like deep metals, etc. I guess maybe I've mastered a lot of what it takes to get the factory going, so I am in a different situation than new or intermediate players would be (I must have played at least 150 hrs by now.)

Yet, I still wish for more, and not necessarily from mods.

One thing that you guys did which adds more without requiring prerequisite complexity are the modules (except for some more advanced stuff like armors and L3 Assemblers obviously.)

Would you guys consider adding resources that could be used to increase either the yield or even the effectiveness of produced items?

I can explain this a little by referencing Paradox's Hearts of Iron 3. They have strategic resources in the game such as tungsten which increase your nation's hard attack values which are used to penetrate armor by 15%. What if there were resources that you could mine that would help increase the yield of smelting? Like different types of coal/coke. Tungsten could increase the attack damage of ammo made with it. Certain chemicals could be created in chemical factories that work as catalysts that increase the speed of production.

The thing which also helps with the complexity is putting it behind a research wall, as you already do. Also requiring better mining techs for more rare minerals and things with better miners?

One of the things I like about Factorio is all the complexity and lots of resources and things to build.

[Zeblote]

Yet, I still wish for more, and not necessarily from mods.

Probably not related, but one reason why I don't like using mods to extend gameplay is that their graphics tend to look like garbage compared to the default ones. They either don't fit the art style, don't fit the lighting, or are just recolored default sprites. That's not fun.

[Peter34]

So will it only be 7 Lamp colours available? White, red, green, blue, cyan, magenta and yellow?

I'd really like just a few more options. For instance I might want to make a short line of Lamps that light up in increasing "hotness" colours, such as a dim red, then normal red, orange, yellow, yellow-white, white, so signal increasing urgency about something, on a scale from 1 to 6 (omitting 0 since no light/colour at all might cause players to worry if the lights are working or forgetting that the Lamp line is even there).

For that, I'm missing dim red, orange and the yellow-white.

[Peter34]

Is there a circuit/combinator tutorial somewhere that I can watch or read? I want to use them in my factories, but I don't know how they work

Well, what is it you want to build? The Combinator system is used to control stuff in your factory, so you must first decide what you want to control, then after that you build that.

What I wanted to control was I wanted to shut off some of my lines of 10xSteam Engines based on the percentage charge in my Accumulators. I needed a mod to be able to "measure" the amount of energy stored in an Accu (hopefully in alpha 0.13 that'll be possible without a mod), and the rest I did based on Constant Combinators and those that compare values (I think they were Decider Combinators). Oh, and one Arithmetic Combinator to calculate the charge of one Accu in Joules divided by a fixed value (I think 25 or 250) to yield a result value from 0 to 100 which was the percent of maxed out charge in it.

I used the Constant Combinators to define thresholds for when different lines of 10xSteam Engines would be shut off or not (if shut off, the Small Pumps feeding them hot water would shut off) and Decider Combinators for determining whether each line should be on or off (by comparing that line with its specific Constant Combinator).

Setting that up helped me learn the system.

[MeduSalem]

Is there a mod with smart/multipurpose Assemblers/Furnaces?

Not that I would know of.

But would definitely be a mod I would use if it never becomes implemented as a feature to the main game.

Yet, I still wish for more, and not necessarily from mods.

Probably not related, but one reason why I don't like using mods to extend gameplay is that their graphics tend to look like garbage compared to the default ones. They either don't fit the art style, don't fit the lighting, or are just recolored default sprites. That's not fun.

I am with that. I would wish more stuff would be integrated to the game, some as regular features, some as "advanced optional" ones or just because they provide alternative approaches to existing stuff.

My reason for why I am not using mods as often if at all is because they break so easily. Just one update to the core game and some of the more complex or fragile mods tend to freak out. And the worst part about it being that the initial developers of those mods often give up on keeping things up to date for whatever reasons (like reallife getting in the way or they become frustrated with the project, etc) so compatibility runs out and that's it.

For that reason I only really start using mods if official development on a game has long since been abandoned and modders are all there's left of the community. Then there is basically guranteed that another update to vanilla will never happen, thereby never breaking compatibility with something and the only real problem to deal with being mods messing with one another or the bugs left behind by the original developers of course. xD

[Twinsen]

So will it only be 7 Lamp colours available? White, red, green, blue, cyan, magenta and yellow?

I'd really like just a few more options.

Yes, I decided to leave a small number of colors for now, but I made it really easy for modders to add more colors.

[sillyfly]

... I made it really easy for modders to ...

That's the spirit

[MeduSalem]

So will it only be 7 Lamp colours available? White, red, green, blue, cyan, magenta and yellow?

I'd really like just a few more options.

Yes, I decided to leave a small number of colors for now, but I made it really easy for modders to add more colors.

I take a wild guess but the limited amount of colors will be among the first things people will come to the forum and complain about after the release. xD

I am fine with the 6 main colors + White/"Black", I wouldn't create fancy nightclub signs or christmas light shows anyways. I am way too much of a constructivist and functionalist to ever build something like that.


... but that said I would have really implemented the 24 bit RGB standard somehow, just because I can already see the threads with people crying for it.

Could be done with having a condition for each of the 3 color channels on the lamps. That way one could apply/map a specific circuit network signal to a specific color channel and it would use whatever value is on the circuit network signal as value for that color channel as long as it is between 0 and 255. Anything above 255 would automatically be the pure color for that channel.

That could also work together with a manual slider/input field for each channel so people could give the lamp a permanent color in the RGB space without the need of a circuit network signal. The sliders would be overriden by the circuit network signal.

Or at least I would have expected it to be something similar to that because that approach seems to be the straight forward, flexible and logical solution to me. And specifying RGB colors actually isn't that hard as there are like a million websites providing calculators or tables for common colors (not to forget that common codes could be in an on-hover tooltip as well, a feature that would provide a lot of help in various places).



... also on a side note... which signal/value corresponds to which color with the actually planned way? Will it become a horrible standardization mess when people cry for more colors eventually? :s

[JC1223]

On where the splitters were mentioned in the topic: I think they should have multiple modes we can choose from, per-item, per-belt, per-side and stuff like that because it adds more functionality without more items to add or take up memory. Different setups need different things, and maybe we could adjust how it splits: 1:1, 2:1, 3:2, etc, so if we don't want an even distribution because we only need a little of an item one way and a lot the other, it doesn't take a huge and complex jumble of splitters to get the ratio we need.
if you agree please show that or something so the devs can see how many people would like this. (If there are that many people, I haven't seen a suggestion like this yet but plenty of people probably want this.)