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

[ske]

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.)

This sounds complex. It is an interesting idea but there are so many possibilities and it's hard to get the interface right. What about signals, sorting, programming the splitter with a script?

The idea per se is not bad but I think there are other problems that need to be solved soon. When the steam release brings in a sustained stream of fresh money such things could be added to the endless stream of cool new features.

[MeduSalem]

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.)

This sounds complex. It is an interesting idea but there are so many possibilities and it's hard to get the interface right. What about signals, sorting, programming the splitter with a script?

The idea per se is not bad but I think there are other problems that need to be solved soon. When the steam release brings in a sustained stream of fresh money such things could be added to the endless stream of cool new features.

All of those possibilities have been discussed over in the Ideas & Suggestion section a couple of times each. The devs don't want to make "smart splitters", for the sake of gameplay simplicity (the rule of not adding additional items so players don't get "overwhelmed") and because they are tired of fiddling around with the splitters.

I bet nobody would ever have found the quirk described in the Journal if the devs would have given in and added a "Smart Splitter" a long time ago to specify ratios or filter out certain items to control the item flow. Now people have to come up with all kinds of ridiculous and overly complex contraptions to achieve those things due to lacking game functionality and on the way they find all kinds of weird behavior and other things that were never intended.

Being "forced" to change the Splitter behavior again for that reason is just pure irony at this point.

But in the end we may have Smart Inserters and Smart this and smart that, but we won't get a smart splitter because it has been decided "modders can do it" and if I remember right there is a mod for that even it bugs out a lot.

[BigDub]

Maybe it's just me, but I am not excited by additions like combinators or colored lights. These things seem like toys to play with in a free building mode or in a normal game after your factory has become so stupidly large you could have "beaten" the game easily and are building for its own sake.

The changes I want to see are the ones that impact gameplay, the ones that have practical use in a playthrough. The main game still feels a bit lacking and the updates are talking about stuff that seems like polish and extras to me.
The changes that I like to see are the ones like the spider and cement, things I might actually use if I were playing through the game for the first time and trying to win, not stuff for just messing around.
I want to see changes to the core of the game, things like more ores than just iron and copper, power lines' transferring efficiency (though the technical aspect might make this unfeasible), needing to find and subsequently to drill an oil well before you put a pumpjack on it, pumping water down a well to increase oil output from other wells, needing to crush/grind/filter ores and having to worry about the efficiency of these processes rather than basically picking it up off the ground and throwing it into a furnace.

One of the things I loved about playing through Factorio was that I was able to learn about production processes I knew nothing about before. When the missions/tutorials showed me how to process oil into plastic it got me so curious about it that I spent a couple hours on wikipedia learning about the whole process from finding an oil well to the separation of different intermediate products in distillation towers to the production of plastics from some of those intermediate products. I love that about Factorio, so it saddens me to see core components of the game, like mining, so overly simplified.

Maybe I'm alone in this, but I would love to see the Friday Facts show me that Factorio is taking steps towards incorporating more real-world processes into the game and adding more game content and depth rather than what I see as kind of just fluff.

[Zhab]

Hi there twinsen. Basically I'm wondering if you decided to implement a feature you've talked about in the past in this topic. It was about dynamic selection of what items a smart insert is or isn't allowed to pickup.

The way I would like to do it is to have the inserter be able to also work in "filter mode", meaning that if you send copper plates and batteries in the circuit network, the inserter will only pick up copper plates and batteries. Basically a filter programmable by the circuit network.

This way you can also do "one condition for each slot", not directly in the inserter, but with a combinator setup.

This feature would be invaluable to me for the type of combinator operated factory I have in mind. Is it, will it or can it be part of the 0.13 update ?

[ratchetfreak]

The behavior of splitters should be modable

vanilla can keep the simple mechanics but modders should be able to define complex-ish behavior for the splitter

[Originus]

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.

I think the idea of an assembler which builds depending on circuit signals is great, but I think your ideas of the implementation are way to complex, more easy:

if you tell the assembler to build nothing, it "releases" all materials it has (and the ones which are in the inserting inserters "hands"). The inserter which normally takes the finished product out of the assembler put these materials on the output belt/chest. In this way you just have to sort the output between product and unused material and dont get any deadlocks in the assembler.
(and I am sorry but I dont care if this solution works for multi-purpose furnaces or not, i think they arent nearly as interesting as multi-purpose assembler)

[ske]

I think the idea of an assembler which builds depending on circuit signals is great, but I think your ideas of the implementation are way to complex, more easy:

if you tell the assembler to build nothing, it "releases" all materials it has (and the ones which are in the inserting inserters "hands"). The inserter which normally takes the finished product out of the assembler put these materials on the output belt/chest. In this way you just have to sort the output between product and unused material and dont get any deadlocks in the assembler.
(and I am sorry but I dont care if this solution works for multi-purpose furnaces or not, i think they arent nearly as interesting as multi-purpose assembler)

I like this idea. With the provider chests it would already work well today.

The idea also goes well with my design where all items are on a single circular belt. The only thing needed to make this complete would be smart belts (like smart chests) which give a count of the number/type of items on a belt (see https://forums.factorio.com/forum/viewtop ... =6&t=18953).

I don't see a problem with multi-purpose furnaces.

[MeduSalem]

if you tell the assembler to build nothing, it "releases" all materials it has (and the ones which are in the inserting inserters "hands"). The inserter which normally takes the finished product out of the assembler put these materials on the output belt/chest. In this way you just have to sort the output between product and unused material and dont get any deadlocks in the assembler.

It would cause so much overhead first to output everything to the belt one by one and then to sort out all the stuff that an assembler might eject if there's a recipe switch that it might as well render the entire contraption unuseful and something that could be better achieved if one would build individual assemblers with fixed recipes for everything again.

Just imagine for example an assembler with an active recipe for Processing Units. There are 40 electronic circuits in the buffer and the assembler is currently waiting for an advanced circuit to be able to craft the processing unit. Then comes a signal from the circuit network telling the assembler to switch recipe to whatever for whatever reason. Baem... you'd have to eject 40 electronic circuits to the output belt. You'd dismantle the assembler immediately and never think about using multipurpose assemblers again. Granted, maybe that's an extreme case but still a possible one and I guess you get the point.

And even if you don't care about the multipurpose furnaces, which is your right because I agree that it might not be fun for everyone, the people who played around with them, including myself, showed that having to control item flow very exactly always results in overly complex contraptions which literally nullify the advantage gained by them. They make just everything 2-3 times more complex than they need to be, making them prone to errors and throughput bottlenecks.

Some of the contraptions needed might be circumvented by making the filters of smart inserters programable as well but the thought alone that the way to handle the problem is to eject the residual materials rather than storing them in a small built-in recipe-independent buffer is just... urgh.

If at all a possible implementation of such a "smart assembler" should be more futureproof and efficient. And I think that could only be achieved by leaving the residual items inside a built-in recipe-independent buffer pool, untouched during recipe switch and for later use if the recipe switches back to the original one(s). It would cause less overhead and less intervention and contraptions.

[ssilk]

Being "forced" to change the Splitter behavior again for that reason is just pure irony at this point.

There is nothing forced. Those who read this forum carefully saw this coming. That splitters splits per lane has already been discussed as bug. There are dozens of suggestions around the splitter, most around sorting. And it is clear, that the number of mods around the splitter is also a signal, that the splitter needs a change. This new "tweak" is just the drop in the bucket, which brought the devs this point of view.
And if they say "we need a change" it has always been a "complete review".
Always.

So I'm very keen on what the changes will bring new.

[I await some kind of connection to the circuits: when used as output: counting items, when used as input sorting items (or item-gate). But that is pure speculation!]

[MeduSalem]

Being "forced" to change the Splitter behavior again for that reason is just pure irony at this point.

There is nothing forced. Those who read this forum carefully saw this coming. That splitters splits per lane has already been discussed as bug. There are dozens of suggestions around the splitter, most around sorting. And it is clear, that the number of mods around the splitter is also a signal, that the splitter needs a change. This new "tweak" is just the drop in the bucket, which brought the devs this point of view.
And if they say "we need a change" it has always been a "complete review".
Always.

So I'm very keen on what the changes will bring new.

[I await some kind of connection to the circuits: when used as output: counting items, when used as input sorting items (or item-gate). But that is pure speculation!]

Well that's why I quoted the forced. Couldn't think of a better word or phrase while I was writing the post. xD

But in general I am with some of the people who cry for such a thing as a Smart Splitter for filtering/ratios and so on because for the most part the belt mess and the throughput problems are a major reason why I eventually give up on using belts and switch over to robots to deal with certain problems, doing it the easy way. Eventually if there is no "simple" or at least "good looking" solution possible to something I give up on further agonizing myself about it. Having to built belt-rebalancers or inserter-based sorters is just... brrr... not even going to bother with that because they are neither simple nor good looking when you ask me. It may be a personal preference though so I might not see it completely objective.

[DOSorDIE]

Wires are just sprites You can easily make a mod to replace the sprites with any you'd like.

Who i can find that ... i have search but find all but not the sprites for Red/Green Cable Wires.
Im blind or what?

[Zhab]

Wires are just sprites You can easily make a mod to replace the sprites with any you'd like.

Who i can find that ... i have search but find all but not the sprites for Red/Green Cable Wires.
Im blind or what?

C:\Program Files\Factorio\data\core\graphics\wire-shadow.png
C:\Program Files\Factorio\data\core\graphics\red-wire.png
C:\Program Files\Factorio\data\core\graphics\green-wire.png
C:\Program Files\Factorio\data\core\graphics\copper-wire.png

C:\Program Files\Factorio\data\base\graphics\icons\red-wire.png
C:\Program Files\Factorio\data\base\graphics\icons\green-wire.png


I found that by going to C:\Program Files\Factorio and typing "*wire*" in the search box (no quotes).

[DOSorDIE]

Wires are just sprites You can easily make a mod to replace the sprites with any you'd like.

Who i can find that ... i have search but find all but not the sprites for Red/Green Cable Wires.
Im blind or what?

C:\Program Files\Factorio\data\core\graphics\wire-shadow.png
C:\Program Files\Factorio\data\core\graphics\red-wire.png
C:\Program Files\Factorio\data\core\graphics\green-wire.png
C:\Program Files\Factorio\data\core\graphics\copper-wire.png

C:\Program Files\Factorio\data\base\graphics\icons\red-wire.png
C:\Program Files\Factorio\data\base\graphics\icons\green-wire.png


I found that by going to C:\Program Files\Factorio and typing "*wire*" in the search box (no quotes).

I was really blind ... Thanks!

[striepan]

These new combinator graphics look great!
Could they maybe be backported to 0.12 ?

[ske]

These new combinator graphics look great!
Could they maybe be backported to 0.12 ?

When was the date for the steam package? The 29th? That's in 2 days.

[Zeblote]

These new combinator graphics look great!
Could they maybe be backported to 0.12 ?

When was the date for the steam package? The 29th? That's in 2 days.

Wait, what? :O

[daniel34]

These new combinator graphics look great!
Could they maybe be backported to 0.12 ?

When was the date for the steam package? The 29th? That's in 2 days.

Wait, what? :O

Steam release is on February 25, but in the FFF they wrote they need to provide the Factorio package one month before. Although I think/hope they can make changes to the release version until release (1 month would seem awfully long if bugs are found until then).

Steam release date

We have been pushing the stem release forward for a pretty long time, but we finally have a definitive release date of Factorio on steam. The date is 25. February, exactly 2 months from now. We planned it to be in January, but we have found out, that we have to provide the Factorio package one month before the release to steam for inspection, and we need some extra time to solve all the little problems in 0.12 release. We also need to prepare the campaign and finish the trailers, so it is all done right.

[ske]

These new combinator graphics look great!
Could they maybe be backported to 0.12 ?

When was the date for the steam package? The 29th? That's in 2 days.

Wait, what? :O

Steam release is on February 25, but in the FFF they wrote they need to provide the Factorio package one month before. Although I think/hope they can make changes to the release version until release (1 month would seem awfully long if bugs are found until then).

I stand corrected, it probably was 2 days ago - how time flies!

[striepan]

These new combinator graphics look great!
Could they maybe be backported to 0.12 ?

When was the date for the steam package? The 29th? That's in 2 days.

I know the developers might be busy right now, but other than that I don't see how it is related to my question.

[ske]

I know the developers might be busy right now, but other than that I don't see how it is related to my question.

They use 0.12 for the steam release because 0.13 is not stable yet.

They ported the new icons back to 0.12 in order to get a better looking steam release (and maybe to avoid any copyright related issues).

The date for the steam version to be released in two weeks already has passed. I don't know how many changes can/should be made after that date.

I would expect the work on 0.12 to be stopped by now - except if steam demands changes. Instead the work will go into 0.13 because that is the next release and that will get the new graphics.

Disclaimer: I'm not a factorio developer. Everything could be different.