Factorio Forums

I've been playing around with a new idea I had (maybe somebody else has already done it but I didn't see any). I'ts never going to be "the most efficient" or fastest, just for fun. It was inspired by the chains idea (https://youtu.be/EEvVFkzTtWY?t=377), but I wanted to do it with bots. Bots are nice because they have really good throughput, but as your factory size gets really large and the logistics network gets really large, the bots start taking really, really long journeys (maybe having to stop to recharge, etc.). This is not really a "problem" in that throughput is probably fine, but I wanted to see if I could design that issue away.

So I had this idea of building a factory out of large square cells, each cell precisely sized the same as a small logistics network, and the walls of the cell are a bunch of requester and provider chests with smart inserters in between. The chests are for transporting the stuff you use commonly, so basically the same stuff you'd put on a main bus. You can test the contents of one cell with the other, and turn on the smart inserters such that chest contents always went to the cell which had less. In this way you could have diffusion of materials across cells.

This is what a cell looks like: Note that the logistics network size ends precisely on the chests on it's side of the cell wall, so bots can only give and take to chests within its own cell: The "advantages" are that the furthest distance a bot can possibly travel is simply from one end of the cell to the other, so they rarely stop for charging, and there are raw materials available everywhere, so you can basically plop down any kind of bot-based assembly chain anywhere in any cell and they can get at copper, steel. circuits, or whatever else you decided to transfer along cell walls. Also it looks really cool in my opinion anywa (my build is messy as hell, but if you were the kind of guy that liked optimizing assembly lines for perfect squares, etc., it would be fun to design compact builds constrained in cell walls). You can also build totally in 2D, just spread out in every direction and materials will get there. You can also just build right on top of any deposit you feel like and absorb it directly into your network.

Many disadvantages: number of different items you can diffuse across cell walls is limited to the number of chests/inserters you have along the cell wall, which is limited by length of wall. You also need at least one chest pair/inserter in each direction, so that further limits items by half. Item throughput is limited to how fast a smart inserter can transfer items. So you have to duplicate chest->inserters for items you plan on using a lot, so I have 4X copper and 4x iron and 2x green circuits, which further cuts down on the total number of different items you can pass back and forth, and it's still not going to be as fast as a belt bus. Because you don't have access to a full logistics network, you have no way of using bots to bring back a finish project that's not passed through cell walls with bots, so ironically you have to belt back finished products (like, say, assemblers, solar panels, accumulators train tracks, trains, capsules, ammo, probably rocket components and stuff like that.

That being said, it's kind of a fun build, and sort of mindless in its own way - need more space to build stuff, literally just blueprint down a cell anywhere you have room. Need more red circuits? Just plop down a bunch of red circuit assembly lines in any cell, and they will pull the plastic and copper and green circuits from the cell walls, and the red circuits will end up saturating your cell network soon enough. Need more iron? Just build a cell over a deposit and throw on a bunch of drills and furnaces and those plates will end up in your network as well. Here's 6 cells - clockwise from top left: bunch of steel smelters, nothing, nothing, a cell on top of copper with furnaces supplying the network with copper, requester and provider chest assembly, then green circuits and smart insert production: It's fun watching the bots bring stuff across the cells: And it's cool at night watching the cell "nucleus" (the roboports) light up as well as the cells walls: Where I could use some help:

Suprisingly, it wasn't obvious how to build the simple cell wall requester->smart inserter->passive provider chunk such that movement tends towards the side with less stuff, while also making sure that there are materials in the provider chests. The way I have written it is basically, sum amounts of left side chests (requester+provider) and sum right side. If left is less than or equal to right side, then pull contents from right to left. Similar for right side. The effect of this is that even if they are tied for resources, they pull contents from the other side. That results in a lot of "churn", where both sides just suck resources from each other while bots pick them up from the provider chests and drops them in the requester chest. See the iron part of the cell wall here: Basically, all the inserters are firing like crazy (iron from left to right and right to left) while a swarm of bots just moves them up and down from provider to requesters. (If it's not obvious, in this image, the left and right inserters alternate, so the top is right requester->left provider, and 2nd from the top is left provider->right requester. This has the effect of tying up bots (not that much of an issue, though sometimes if lots of bots are churning and it's a very busy cell (lots of throughput of other items), it can result in a big mess of charging bots. But worst of all, sometimes it will simply tie up a ton of resources. So in this example, there might be ~150 iron per pair of chests here that just get swapped back and forth, while the cell wall on the other side of the wall may actually need the iron badly (it may be sitting at 0 because the cell next to it is sucking up iron for steel production), so while there should be a lot of iron available, a lot of it is stuck on this endless merry-go-round.

Here's what I discovered. If I had them test for "if my side is less than but not equal to the other side, then pull resources to my side", then I could get stuck where both sides had a bunch of materials in the requester boxes, but wouldn't pull them over to the other side. So I could end up with a stack of iron in the left requester and a stack on the right, with no iron in either of the providers, so there would be none available (bots can't pull out of a requester). So I had to test for "less than or equal to" to get them to default to pull something over. But that results in this churn. The churn stops only when there is full saturation of every requester and provider chest in the network . If anybody could help me design a simple mechanism with requester and provider chests that consistently pulled from the heavy side, and also was stable and did not result in churn, that would be super helpful.

You could use a row of cells and use belts for the high volume stuff like iron and copper and circuits in each cell you use a set of inserters to pull stuff off the belt and provide them to the cell below.

That'll fix quite a bit of the churn.

Do you want all resource types to be transferred all directions?
If not, it's easy.
Place a requester chest in the cell that's making the product and a provider chest in the receiving cell with any inserter in between.
I don't see any reason the provide for example iron plates to a cell that is producing iron plates.
If the product is needed in a cell that is not next to the cell delivering the product, the cell in between just has provider chests on one side and requester chests on the other.
No combinatorics needed this way.

This should work -
I'd set your requester chests to receive 10 or 50 items automatically and then leave them out of the wired networks.

Multiply 1 side of "Each" item x-1.1 and add it to the other side. Then connect the outgoing smart inserters for the other side to that wire and tell them to operate when that specified item is greater than 0.

example: There are 1,000 items of iron ore on the left side in the "Active Provider Chests" The bottom left combinator multiplies that by -1.1 and outputs -1,100 items of iron ore. The bottom electric pole has that -1,100 iron ore signal sent to it as well as the actual amount of iron ore in the "APC"s on the right side. Let's say there are 2,000 iron ore on the right side. The signals are connected, so the final tally is 900 iron ore on the signal which is sent to the smart inserters directed to the left. The inserters are told to operate when their specified material is greater than 0. So, the smart inserter assigned the material "Iron Ore" registers a number greater than 0 (900) and starts to operate until the left and right side quantities come within the 10% margin.

You really only need 2 combinators per cell and you only have to make 1 adjustment to modify the margin (I have 10% shown but you can use anything). You could also add a constant combinator if you wanted to modify the margin by an actual quantity instead of a percentage.

Please post a picture if you get this to work.

DerivePi wrote:Multiply 1 side of "Each" item x-1.1 and add it to the other side. Then connect the outgoing smart inserters for the other side to that wire and tell them to operate when that specified item is greater than 0.

Hi -thanks for the idea! It didn't work entirely, but I like it. I'm still new to combinators - it's not intuitive for me to simply sum things together by wiring them.

I had to multiply by -11 and 10 (since you can't do decimals) but the idea is the same of course. Same number of combinators as before (two multiplies on each side - I omitted the pole - just wired one side's *-11 and the other's *10 straight to the inserters). It's working "correctly", and it's kind of hard to tell, but I would say there is less churning than before, but still quite a bit. The biggest problem seems to be that it tends towards fewer and fewer items in the chests. Requester chests may be full, while APCs have 100 on each side (so inserters do not pull more from RCs to APCs). Then some bots come and take away some iron, so one has 80 and the other has 100, so the inserters fire until they are (roughly) tied at 90, and they stop pulling. Then 80,70,60, and sometimes it'll just completely deplete both sides and they'll both be stuck at 0 (even as the RCs are completely full.

I'm kind of thinking that this idea might not be fully feasible, which is kind of a bummer! Since I need for the inserters to err on the side of activating so that the APCs want to be mostly full, I suppose that will necessarily result in more churning (since bots will happily rip those resources right out of the APCs and put them right back in the requester chests). So the only time the churning stops is when the RCs are full (which I have seen with not the raw materials, but the stuff I'm passing along the cell walls that I haven't started consuming yet at this stage of the base - like my red circuits and green circuits saturated all the chests on all the cell walls of every cell, and then stopped churning). But the iron and copper, which is in use, will continue to churn because the chests will never stay saturated...

pieppiep wrote:Do you want all resource types to be transferred all directions?

Yes, that is kind of the idea - I wanted a mindless just full diffusion of resources everywhere, with the idea that all the cells would be identical so I could just smash them down everywhere without a care to what went where. e.g. in my example, I'm supplying copper from a belt from the west, but a few cells in, I just plopped a cell down right on top of a copper mine and put some drills and furnaces, and now copper diffuses out from that cell as well. It's actually kind of cool looking!

Can't do decimals - whoops! That's what I get for doing it on paper. I like your solution. You can also try a Constant Combinator chest - connect the CC to the item count and set the items in the CC to the margin amount you want for each item (100 iron pl, 100 cu pl, 50 wood, etc...) - then multiply by -1 and add to the other side.

You say the requester chests are full? Are they full with 10 items or completely full? They should only be set to request a minimum amount.

ribsngibs wrote:The biggest problem seems to be that it tends towards fewer and fewer items in the chests.

My faulty thinking with "Active" provider chests was that the items would be pushed to the center of the cell where the items are used. But, you also want to use those chests to measure how much material you have. Any Passive Provider chest or storage chest in the middle will short circuit that measurement. Maybe try Passive Provider chests instead of active? Or, wire together all of the internal storage and passive provider chests for a full count of items in the cell (I'd still ignore the requester chests though).

DerivePi wrote:You say the requester chests are full? Are they full with 10 items or completely full? They should only be set to request a minimum amount.

They are full to the amount that I asked them, which is actually quite a bit, because: If you only ask for 10 items, and if you have heavy draw on the neighbor cell sucking up all the iron, your requester chest gets emptied by the inserter pulling the iron to the other cell, and then only 2 bots (10 iron plates) are dispatched from the other side of your cell. When those 2 bot arrive 5 seconds later, the iron is deposited and eaten immediately, at which point 10 more iron plates in 2 bots are dispatched, so you only get ~2 iron per second throughput. If you ask for 100 iron or 200 iron, then a whole bunch of bots are requested at once, which results in better throughput. I think ideally you would ask for "max number of items a smart inserter can move from chest to chest in the max travel time for a bot within a cell" items. So... I would guess somewhere in the range of a hundred items or two.

DerivePi wrote: My faulty thinking with "Active" provider chests was that the items would be pushed to the center of the cell where the items are used. But, you also want to use those chests to measure how much material you have. Any Passive Provider chest or storage chest in the middle will short circuit that measurement. Maybe try Passive Provider chests instead of active? Or, wire together all of the internal storage and passive provider chests for a full count of items in the cell (I'd still ignore the requester chests though).

Actually, in my original design they were passive providers, and then I experimented with actives when your post suggested them. I'm not 100% sure on the in-game logic, but I actually think actives worked better (it's honestly really, really hard to tell what's going on because a few hundred bots are constantly in motion moving stuff all over the place, and it's random - which chest they pick up from and which one they drop off too if they have multiple options, and with 4 chests of each kind on 4 different walls, it's kind of a mess). I *think* that if you had requester chests that needed filling and a bunch of passive chests with supply, that the bots would tend to pick up plates from requester chests nearby and not further away, so you could have a cell where the south wall would be saturated with 2000 iron and the north wall would be churning chest->inserter->chest->bot->chest->repeat with only 50 iron in the system. I think that when I switched everything to active providers that the bots became more likely to take the long trek and bring some of the south plates up north.

In general though, active and passive should behave identically (in terms of churn, etc.) in my build - if there are no storage chests, actives and passives should behave the same - if there is an non-full requester chest bots will remove from the provider and if there isn't, they won't.

In my original build, I also had wired all requester and provider chests to get a count, but I don't think that mattered - I think the problem is basically unsolvable: in the RC->inserter->PC->bot->RC churn, the PC->bot->RC part is not fixable if the requester chest is not 100% satisfied, since that's just what bots do. And the RC->inserter->PC part must be active up to some set quantity, or otherwise the PCs will empty and thus no materials will be available to do work. So if the total number of items in less than "RC request amount + PC demand amount", it will churn, and the system will never demand more items than "RC request amount + PC demand amount". So if this cell wall is performing any useful service (providing materials for assembly or just transport of materials to another cell wall), it will always be under the "full" amount and it will churn churn churn.

Anyway, thanks for the help - it was just an experimental build, and it was fun, and it even kind of works to a limited extent.

So, I started mucking around a bit. I think I have a workable solution, and a SUPER terrible example build.

Essentially what we want is if the current cell has more of something than a neighboring cell, transfer to the neighbor.
So each of the four sides of your cell needs to talk to it's neighbor.
To decide if we should transfer or not, we need to know how much is stored in the current cell, and the neighbor.
We want to even it out as much as possible, without thrashing back and forth. If you have a difference of a hundred before you start moving items, each cell away from the producer will get 100 less items. Cell A has 200 circuits, cell B will have 100, cell C will have none. So ideally, you want as little difference as possible.
We can use a latch to remember if we are transferring to the neighbor, or they are transferring to us. The latch can reset at a high value, so eventually if the balance is upset (copper mine moved to other side of map), we start transferring the right direction.

My build is this: In each cell, all passive providers in the logistic network are attached to the RED circuit network. So we can see all the stored items of ONLY THIS CELL on RED.
Cell A is top, Cell B is bottom.

On the edge between A and B:

Combinator 1(arithmetic)
Cell A RED circuit connects to input
Combinator 1 is set to Each * -1 outputs Each
#This inverts the output, and allows us to avoid merging the red circuit network.

Combinator 2(arithmetic)
Combinator 1 output GREEN to input
Cell B RED circuit to input
Combinator 2 is set to Each * 1 outputs Each
#This sums up the two networks, giving the difference in item counts

Combinator 3(decider)
Combinator 2 output GREEN to input
Combinator 3 is set to Each < -1k outputs Each 1
#This is the difference between cells before we toggle between AtoB or BtoA transfers. 1k is probably too high, but depends how much you want.

Combinator 4(decider)
Combinator 2 output GREEN to input
Combinator 4 is set to Each > 1k outputs Each 1
#This is the difference between cells before we toggle between AtoB or BtoA transfers. 1k is probably too high, but depends how much you want.

Combinator 5(arithmetic)
Combinator 4 output GREEN to input
Combinator 5 is set to Each * -1 outputs Each
#Another inversion, used to reset the latch later

Combinator 6(decider)
Combinator 3 output GREEN to input
Combinator 6 is set to Each > 0 outputs Each 1
#first part of latch

Combinator 7(decider)
Combinator 5 output GREEN to input
Combinator 7 is set to Each > 0 outputs Each 1
#reset part of latch

Complete the latch
Combinator 7 output RED to Combinator 6 input
Combinator 6 output RED to Combinator 7 input

At this point, the output of Combinator 7 is 1 for each item that is set AtoB, and nothing(0) for each item that is BtoA. So now we know which direction each item should be flowing, preventing items from going the against the flow and thrashing.

Combinator 8(decider)
Combinator 2 output GREEN to input
Combinator 8 set to Each < 0 outputs Each 1
#This outputs 1 for each material that A has more than B

Connect Combinator 7 and 8 with GREEN
#the combined output here(you can check on a power pole if you want to see) is 0 1 or 2. 1 or 0 from the A has more than B combinator 8, + 1 or 0p from AtoB latch combinator 7

Now we can control our inserters between sides!

Inserter 1 - B to A
Combinator 8 GREEN to inserter
Inserter circuit condition set to your material of choice(iron in my case) < 1
#So this will run if B has more iron than A AND we are latched BtoA for iron (1 iron from the B has more than A combinator 8, 1 iron from AtoB latch combinator 7)

Inserter 2 - A to B
Combinator 7 GREEN and Combinator 8 GREEN to inserter
Inserter circuit condition set to your material of choice(iron in my case) < 1
#So this will run if A has more iron than B AND we are latched AtoB for iron (0 iron from the B has more than A combinator 8, 0 iron from AtoB latch combinator 7)

I'm sure somebody will come along and figure out how to do this with 1 combinator instead of 8, but it works!

Should behave well with various types of logistic chests, just remember they need to be part of the red circuit network to count.
I do realize that it STILL doesn't stop items flowing pointlessly around. It won't thrash in one cell, or between two cells. But if you make a square of four cells, it's possible that items could flow in a loop.

I'm super curious to see someone build this on a reasonable scale. Resources should flow between cells, almost like following a river.

I like the idea of using a latch to set the direction of flow.

- Instead of setting each material's margin to 1,000 items, use a constant combinator so that each item's margin can be set. Ex. speed module at 50 items, iron plate at 2,000 items.
- This allows items to be transferred up to A = B and avoids the return thrashing, but I think just subtracting A and B with a margin achieves close to the same thing.

I disagree that a circle of cells would flow pointlessly. The supply cell will always flow down to the demand cells - no MC Escher staircase.

DerivePi wrote:I like the idea of using a latch to set the direction of flow.

- Instead of setting each material's margin to 1,000 items, use a constant combinator so that each item's margin can be set. Ex. speed module at 50 items, iron plate at 2,000 items.
- This allows items to be transferred up to A = B and avoids the return thrashing, but I think just subtracting A and B with a margin achieves close to the same thing.

I disagree that a circle of cells would flow pointlessly. The supply cell will always flow down to the demand cells - no MC Escher staircase.

The per item margin would be great, but I couldn't figure out how to do it without a ridiculous number of combinators.
Best I could really think of was to duplicate the above setup a couple times. Then depending which one you connected your inserters to, you'd have different quantities. Say, 1k, 500, 100, 50.

The circle of cells can still flow: The arrows indicate the latch directions. A starts with 101 items, B,C,D start with 100. A has more than B, so smart inserter moves 5. A now has 96, B has 105. B now has more than C, moves 5 to C, AND D has more than A, moves 5 to A. A now has 101, B has 100, C has 105, D has 95. So on and so forth. It's pretty minor though, compared to the old thrashing. And depends on the latches ending up set like that.

Was thinking about a 'smarter' diffusion build as well. You'd need to connect ALL the cells together on one circuit network. Have a constant combinator in each cell that adds 1 to signal A. Divide the total number of each item by the number of cells(signal A), if you have more than that (plus say a margin of 10), transfer to your neighbor if they have less. But the wiring sounds too painful.

starholme wrote:So, I started mucking around a bit. I think I have a workable solution, and a SUPER terrible example build.

Sweet! I'll see if I can try something like that, though I'm a little worried about the wiring. If I get some time tonight I will try to get a blueprint string of my empty cell so you and others can take a crack at if it you like without having to go through the pain of setting the filters on all these inserts and requester chests...

starholme wrote:I'm super curious to see someone build this on a reasonable scale. Resources should flow between cells, almost like following a river.

Yes, that was the original idea! That resources would simply flow from areas of higher concentration "downhill" to areas of low concentration.