Factorio Von Neumann Mk 1 - Lessons Learned and the Question

[GenericKen]

Cross posted from reddit.

http://imgur.com/a/P5PKp/titledesc

My computer's starting to struggle with the simulation, so I figure this is a good time to stop and take stock.

The dream of the Von Neumann factory is the dream of Factorio - a factory that spits out more factories. In theory, with blueprints, a Von Neumann factory could double its size every 20 minutes, but in practice there are a number of interesting challenges to contend with when playing with the base game.

1) Mineral patches are randomly distributed, so there must necessarily be some manual involvement in the layout of mining outposts.

2) Logistics robots do not have any kind of priority algorithm. They seem to choose tasks within their network arbitrarily and their pathing distance grows exponentially. As far as I can tell, there is no way to establish effective filtering or resource distribution in storage chests to attenuate this pathing distance explosion. Logistics networks simply cannot scale beyond a screen or two, so they must manually be separated between factory expansions.

3) Large blueprints, more than two or three screens in size, are very difficult to place accurately. The ideal way to grow a factory with blueprints is to tessellate it, with overlapping identical parts on the edges, but blueprints are always centered on the cursor, so it can be hard to find a common overlap. Even when you can, it can then later be hard to tell what random tree or rock off the edge of the screen is blocking your blueprint placement. The dream of doubling the blueprint size with every iteration is not realistic when construction robots can't destroy rocks or fill in small bodies of water (or clear biter nests).

I thought these problems would be fun to engineer around and I think I've found some modest success with this first try. I built this factory off of my speedrun save, so biters are passive and resource patches are rich and the tech is maxed.

*

I'm fairly satisfied with the baseline factory expansion design. It's quite compact. I settled on 12 refineries, feeding 3 plastic and 12 batteries. The plastic fed 25 red circut factory (1 roboport factory) and the batteries fed 4 accumulator factories. The elements of the design are simple - two assemblers fed by a requester chest and feeding into a provider chest, with an electric pole and red wired smart inserters to manage the buffer. When fully supplied, the factory creates enough components to create a copy of itself every 20 minutes, refineries and trains and logistic robots and mining outpost materials and all.

The components are loaded onto a 9 car train and shipped to the next factory site. The roboports in the center, surrounded by lights, are laid out at very particular ranges. The leftmost allows for the preliminary construction of the loading station in which the 9 car train can be offloaded. The second brings the offload chests into logistics network range, allowing construction to begin once the networks has been disconnected from the previous factory, as we do not want logistics robots stealing the supplies. The third brings the loading chests into logistics network range, once the factory is running and ready to produce the next copy.

The raw resource loading station is fairly straight forward. I have 5 drop spots - c, i, o, s, and m for copper, iron, oil, stone/coal, and mixed copper/iron. The outposts are generally named c1, i1, o1, etc. It's very important to name them the same for every factory expansion, as it quickly becomes unweildly managing 30+ train stops. Because their names are the same, it's important that the raw resource train network remains disconnected between factories. Trains will prioritize the nearest available stop and have no sense of the current fullness of the station, so you'd very quickly get factory starvation. Unfortunately, water must be connected manually, but it's not terrible. A single water line supported by four-pump pumping stations can support roughly 3-4 factory expansions.

*

Important lessons:
-It doesn't actually seem important to minimize the number of requester/provider chests in a factory logistics network. The throughput is the same, whether a robots feed one chest feeding a line feeding 8 furnaces, or whether robots feed 8 chests. Thus, I settled on a belt-less design, as belts are rather space-inefficient when squeezing a factory into a train.
-Put the barrel assembler right next to the 9 car factory train and load directly into it. Do not put barrel assembly onto the logistics network, or you will saturate your pipeline with empty barrels and actually prevent the emptying of full ones.
-Refineries require level 3 assemblers, so you might as well use them elsewhere as well. I'm pretty happy with feeding each level 2 green with a single level 3 wire factory (and double fast-inserters). I'm not actually sure if double fast-inserters are necessary with the inserter bonus - I assume they are.
-Rail signals are very awkward to try to blueprint on top of each other. Avoid putting them within your blueprint's overlaps, if you can.
-I allow my copper and iron to pollute each other a bit at outposts, as it's trivial to clean up at the station. Logistics robots will clean them up for you, but be sure to have a couple of smart inserters filtering specifically for one or the other per train car, to ensure that copper doesn't saturate and starve out iron (and vice versa).
-Factories take much more iron to make than they do copper. Modules are the only real copper sink in the game.

*

Mining outposts have been more problematic for me. I went through a number of ideas before I settled on this scheme.

-I initially planned to blanket the map in roboport coverage, until I learned that I only needed about 2 roboports worth of solar panels to power each expansion, and until I learned that I had to manually disconnect the logistics networks of each outpost to prevent the robots from blowing out their pathing distances. It was more work to disconnect the networks than it was to just set up small networks on the line.
-I played with the idea of powering each mining outpost independently with solar, without stringing power out to them, but it was a massive pain to layout, and you could only set up the initial roboport during the day. It just wasn't worth it - big electric poles are pretty easy to string from a train.
-I was using blueprints to stamp rail, but it really is just faster to manually lay it from a train (especially because of the aforementioned big-blueprint problems).
-I was also stamping 4 way intersections, with a roundabout embedded between the two tracks. This is theoretically a fine layout for expanding mining north or south, but it caused east and westbound traffic to block each other, which was no good. I find that a simple narrow loop is a lot more robust.
-For a long time, I was committed to the idea of having a small supply train that carried all the outpost materials I needed, but it was always unwieldy. A train with 2 cars is slower to lay track than a lone locomotive. It's difficult to get a precise number of materials into a train without reserving train car spots, and it's not possible to blueprint those and it's inconvenient to copy them from one expansion to another. And at the end of the day, two train cars really only gets you 40 slots - your inventory has 80 some, and you really only need most of it for laying mining expansions once the plans are set. It's just easier to set up personal logistics slots or a couple of requester chests near the factory exit.

The current scheme is this. I fill my inventory with track and mining materials, I place a locomotive, and I lay track west until I've seen enough resource patches. I manually put down a turn and lay track back east to the factory. I make a second circuit to place power poles, and a third to lay periodic rail signals. I go out a fourth time to plop blueprints for the miners and the loading stations and I start up each station's 2 car train.

One thing I hadn't changed was having the miners feed directly into electric furnaces. Smelting is very space consuming, so it makes sense to do it out in the field rather than having it crowd my factory. It's not possible to get full coverage with electric furnaces on top of ore fields, but really, only 2 tiles are wasted out of 24 - that's 92% coverage. It's an independent self-scaling modular plan that requires no alignment. The loss in mining density can be somewhat painful, but this feels like the fastest possible way to set up miners.

The most time consuming thing is still clearing out big-spitter nests, even with maxed upgrades of everything. In future attempts, I think I may play with small nests.

*

It may look like I'm over producing power, but most of the factories are not operating at capacity. I believe my math is about right here.

In the future, I may consider using substations instead of tessellating medium power poles for my solar farms. Certain configurations can give medium power poles exceptional space efficiency, but substations may just be easier to work with, and aren't much more expensive.

*

You can see it plainly in the production tab. The production is very modest compared to some factories I've seen on reddit. I could up the throughput by expanding more rapidly, consuming the resources the 6 expansions can produce, but my computer seems rather unhappy with my ambitions.

This is my big question, to anyone who might know: What is the most computationally expensive thing about my factory, and how can I minimize it? Is it the 200 logistics robots servicing 200 requester/provider chests per factory expansion? Is it the 70 isolated red wire networks per expansion? Is it the logistics networks at the mining outposts? Or is it simply the biter/spitter density?


I'm planning a Mk 2, possibly on a map with smaller biter nests, and I'm considering things to do differently.
1) The station layout, with supplies laid out vertically while the factories themselves expanded vertically, was very awkward. The previous factory couldn't build the next factory's loading station without manual intervention to disconnect the two logistics networks, and in my experience, it's far more work to disconnect two logistics networks than it is to simply start a fresh one.

A far more elegant solution would be to simply place providers at the bottom and requesters at the top. The requesters would feed directly into the next factory's providers with smart inserters in the 1-tile gap between each factory's logistics network. If there's a shortage of materials in one factory, the factory before it can feed the one that comes after. It would function much like a huge main bus, and every factory along the line could participate in a large expansion without any player intervention.

A direct chest-to-chest bus would be less flexible than the train solution. It would be quite a lot of work to turn or extend the line to avoid lakes and the like. But at least I wouldn't be drowning in seldom-used factory supply stops.

2) Without the need to squeeze the factory into a train, I'm free to use a wider variety of materials in the factory's design. I'm thinking about using belts again, if the raw number of requester/provider chests is in fact the computational problem. The main bus could be an actual 30-wide bus, if the belts simulate better than 200 logistics robots.

3) I believe I'll start automating poison capsules at each factory.

Any other suggestions?

[ssilk]

This is my big question, to anyone who might know: What is the most computationally expensive thing about my factory, and how can I minimize it? Is it the 200 logistics robots servicing 200 requester/provider chests per factory expansion? Is it the 70 isolated red wire networks per expansion? Is it the logistics networks at the mining outposts? Or is it simply the biter/spitter density?

Short answer: It is the sum of all.

Long answer: I really enjoyed your article, would like to see more, get access to a save etc

And I think this is a point, where we really can begin to compare the reality with the game: why don't we have just a big gigantic factory here on earth surface? I mean: we have the power, the technology to spread all over the earth, build some small villages every 3-5 kilometers, some factory complex, some agriculture, houses, streets, a shop, etc.

Why isn't it so? Why is it the opposite? Why do we have mega cities and the villages in the country are dying? (Here in Germany, especially eastern Germany we have such things, and it's happening all over the world).

The answer is, that it is just an economic aspect. It's much cheaper to build some mega cities instead of building many small.the core of the problem is, that you cannot plan everything. You build things and suddenly you see, this isn't working as planned. This is quite normal and normal planning solves this with two options: planning in some extra resources and having a time buffer.

Extra resources is in our times nearly almost money. Because if you have forgotten something, you just buy it. But this is much easier, when the distances are narrow. In Factorio you see that, when the bots need N quadratic time to do a job (N is the average distance to the "center" here). The costs explode with the distance.

The costs explode also when you do it differently: bring all stuff on a ship to an island and build a house. Now you forgot the screws, which are needed to fix the roof and you need to travel back for them. Of course here it's differently: we put in the ship much more stuff, than we really need, just in case of missing something. This is much cheaper than traveling back, but the costs are much higher, cause eventually you never need the extra stuff.

In other words: the costs in Factorio to spread exponentially (von Neumann is not the right word for it, but I don't have a better) are,
- how much time is needed to travel to that point to initiate the construction of a structure
- how much resources you need to build a structure
- how much stuff is needed to craft the items
- how much time is needed to build the items
- how much time it takes to bring the items from A to B
- how much items you need to build, that are not used, that are wasted
- how long it takes to change a plan
- how fast the changes can be produced and brought to the target
- how high are the costs for this "express delivery"

What does that mean for Factorio?
- It makes no sense to create one copy of your factory and repeat it every x tiles. We need to concentrate. A Factory every 200 tiles is much, much too thight. My experiences showed me, that it is much more like one big factory every 2000 or 3000 tiles. And that is still quite too thight.
- so it makes sense to specialize. An area for solar panels only for example. One quite, quite big area for smelting. The problem is then still, that you need too much unneeded stuff, cause you cannot really plan that.
Edit:
- not every area is equally useful. There are many reasons, why cities are build at certain places. Mainly, because their surrounding is optimal in many points; there is never only one reason!

What do we need for that?
- we need some tool to request things far away and it will be brought very, very fast. See Pneumatic delivery https://forums.factorio.com/forum/vie ... f=6&t=7150 that does exactly this.
- we need some possibility to build small outposts quite cheap and with high throughput. See ropeway thread: https://forums.factorio.com/forum/vie ... f=6&t=7977
- we need ways to go really fast from A to B. Teleporters for example.
- ways to transport a lot more stuff then yet. Packaging for example. https://forums.factorio.com/forum/vie ... f=6&t=8398
- easier ways to reduce distances in logistic network. Colored logistic: https://forums.factorio.com/forum/vie ... tic#p38564

And many more stuff.

[GenericKen]

Attaching the save, if the devs are interested.

@ssilk - The word you're looking for is viral. The key to virality is the self-sufficiency and self-similarity of each cellular bit. Where a complicated organism (or city) can excel at a complicated task or at an efficient distribution of resources or at adapting to changing conditions, a viral organism can excel at growing.

The logistics network allows for a very compact layout of each cell, one that's relatively easy to stamp, but everyone seems to agree that it's killing my computational efficiency. I'm contemplating a requester-less design, or possibly even a mega-bus design, with 25 straight belts threading their way through the growing line of factories, but people are saying that belts are computationally inefficient too.

Are belts generally inefficient? Or is it the winding, the corners, and the splitters that take up most of the computational power?

[ssilk]

I think viral is the right direction, but not exactly, cause in my thinking virality is exactly this "I spread everywhere, no matter, if it is good or bad". I mean to spread only at some points, which have some distance to the next.

To your question: I think a 25 belts bus through all your factory is it's dead. I tried that just with 5 and the advanced circuits bus was killing me, cause the belts store too much stuff on them (per belt about 12 items).

A short calculation: if this bus is "only" 100 tiles, we have 1200 items stored only on the belts. Or 2400 plastic and iron and 6000 copper. Having one chest of copper more or less in that state is a big difference.

[GenericKen]

Hm. I suppose leaving stuff on the ground would just be terrible computationally.


I did some experimenting with chaining train cars, and unfortunately, there are a number of insurmountable problems:
1) End to end (and in general), rails will only lay 2 tiles apart. They will never lay 1 tile apart.
2) If you place two rails two tiles apart, even if you place train cars on them such that they overlap, fast inserters will not insert from one to the ohter.
3) If you use long inserters, it's possible, if you're not careful, to place train cars on the rails such that the long inserter won't reach both. You'd have to be careful putting them down, and long inserters aren't even that fast. They'd cut your throughput in half.

4) If you try to mix materials when inserting between in train cars with long inserters, it's very possible for a inserters to get stuck holding the wrong material when the other material runs short (even with reserved slots in the cars). Inserters only ever seem to be smart about inserting different materials when they're inserting into an assembler.

*

I did notice, however, that a chain of inserters moving materials through a chain of chests can move materials just as quickly as a "chain" of inserters between rail cars with fast inserters. With full inserter upgrades, they'll have excellent with a pretty decent throughput.

In my latest test, where I load a belt with 6 inserters instead of 1, I find that the throughput of a chain of chests and fast inserters is like 3 times that of a normal belt. It's slightly more than the throughput of half of a fast belt, and about equal to that of half of a fast belt.
Obviously, it would take a lot of power and would be half as space efficient as a fast belt and each chest would hold a ton of items in buffer, but it wouldn't put any items on the ground, and it would turn corners quite nicely.

Does anyone know if belts are computationally efficient when they run underground? Does the game track objects underground, or do they "disappear" for a bit?