Factorio Von Neumann Mk. 3 - The Omnibus

[GenericKen]

Factorio Von Neumann Mk. 3 - The Omnibus

Album here: http://imgur.com/a/ATPXn

01. In my last post (https://www.reddit.com/r/factorio/comme ... d_and_the/) I said that the dream of factorio is to create a self-replicating factory. It's good to know that the developers share this dream (https://www.factorio.com/blog/post/fff-103).

The cellular factory draws its inspiration from nature. Each cell is self-contained and, when fed, will produce another cell. In theory, this factory could grow exponentially, as each growth increases the rate of growth, but practically, the growth is bounded by the linear rate of outpost construction. Still,
a linearly growing factory is a thing to behold.

The two primary challenges of building a cellular factory are transporting the components for each factory cell to the site of each new cell, and feeding each cell with mining outposts with a minimal amount of manual intervention.


02. My first cellular factory was roboport-based with a manual train transport system. It eventually became bogged down by the computational requirements of the exponential pathing of logistics robots and the inefficient roboport outpost layout. With the performance improvements and the addition of the personal roboport in version 0.12, I decided to try building a belt-based cellular factory that could explicitly direct its materials, whose cells would merge and transport the components for a new factory cell along a massive 32 belt "omnibus". My current save stands at 12.5 factory cells and runs at 22fps on my computer. This screenshot was taken at max map zoom.


04. The omnibus has a couple of advantages over robot and train-based transport systems. It's completely directed (no backflow), it's completely autonomous, and it prioritizes transport from the oldest cells rather than the youngest cells. It also comes with some challenges. The blueprint for a new factory cell contains 24k elements, 12k of which are red belt. Because fast inserters can only load 1 element into a provider chest at a time, it would take an hour and a half for the redbelt for each new factory cell to load from transport belt to provider chest (besides the fact that each provider chest can only hold 2.4k redbelt). So I put 6 provider chests in each factory cell's provider supply, along with an inserter to put elements back onto the belt once the head of the omnibus expanded past the current cell.
-There's little reason to use both sides of the belt when the inserters are the bottleneck. Each half-red-belt will satisfy 6-8 inserters.
-I thought there would be more use for brick, but alas, floor elements can't be placed alongside regular elements in blueprints. It's just as well, given my existing problems with element counts.
-I kept a couple of things off the omnibus. Each cell contains just one Yellow Assembler, 3 Radars, 4 Logistics chests, and 7 Requestor chests, so these just sit in provider chests next to where they're assembled and are transported directly from a recent cell. Robots also sit next to where they're assembled, primarily to replace randomly lost ones.


05. Given that the omnibus is already 30 belts wide, I figured I'd add 6 more for a raw material feed bus. It makes it a lot easier to get a new factory cell started if you can pipe coal and empty barrels from the older factory cells. Furthermore, it'll help balance resources (and liquids) between the cells when their outposts don't feed them equally.
-It's very important to limit the number of empty drums you put into each cell. If you don't, the empty drums will prevent full drums from unloading at each cell's grand central station and everything will grind to a halt. Here, I have a smart inserter to ensure that there's never more than one cargo wagon of barrels in a grand central at any given moment.


06. Turning and merging a 30-belt wide bus is not trivial. Every bit of space that you use forces the rest of the bus to grow that much wider, so I put an inordinate amount of effort into making the component factory as horizontally efficient as possible. You can see underground belts popping up between assemblers and direct (stack bonus) insertion between assemblers throughout the component factory.
-The component factory is proportioned to produce the components for a new cell roughly every 20 minutes. However, it turns out that two redbelt iron lines were slightly insufficient to meet this threshold. Four would have been better.
-Each outgoing component line is gated by a smart inserter that ensures that no more than 10 factory cells worth of the component are sitting in provider chests in the grand unified logistics network. This is to ensure that certain components don't starve out other components, filling the omnibus plus each cell's loading station. They're then balanced to the top side of the belt and merged directly into the omnibus. (as usual, red belt must be serviced by more than one smart inserter)
-In retrospect, using both sides of the belt for two different material types would have saved me half of the width of the omnibus, and might have been worth it. I decided against it because the inserter that unloads elements from the provider chest back onto the belt couldn't control which side it unloaded onto, but I'm sure an elegant solution exists to this problem.


07. Where the space below the mainbus is dedicated to component construction, the space above is dedicated to intermediate material construction and to the outbus. Here, I settled on having each cell of the factory produce and transport satellite and rocket components south, though you could theoretically configure it to make whatever you want. Each cell should support about 1/10th of a silo with its current ratios, but it fairly quickly starves out on oil.
-I'm overproducing red circuits here, but in my defense, I would've needed these if I were producing more roboports or modules.


08. There is, unfortunately, one resource that each cell cannot rely on outposts for: water, which is necessary for cracking and for acid/accumulators/blue circuits. In the base game, water can only travel by pipe and can only really be consistently pumped from the starting player location. The water transport must be serviced periodically by pumping stations to ensure rapid flow to the outermost cells. I built the aqueduct 100 wide in anticipation of going 100 cells deep, but I clearly overestimated my computer's ability to go the distance.
-In theory, each cell could survive without water. You could refine oil with basic refining and turn excess light/heavy oil into solid fuel, which you could burn to heat the raw crude to drive steam engines instead of relying on accumulators. However, you'd still need acid for blue circuits for rocket parts, and you're oil/plastic bottlenecked anyway, so it's probably not worth sacrificing the efficiency. Still, I'm not super happy with my current water solution.


09. Each cell's grand central loading station is isolated from the others and is more or less standard. I have 6 stations - ofbsci - oil, fuel, brick (stone), steel, copper, iron. Steel gets its own station since I'm smelting in the field. Smart filter inserters to prevent catastrophic belt pollution when I accidentally mis-assign a train to the wrong station.
-My trains run on the left side to put the train signals in the middle of the track. This guarantees that outpost spurs never have overlap issues with each others' signals.
-I have an outpost supply train that'll carry bulk outpost materials for me on my access track, but it's an awkward solution that I'll explain in the next picture.


10. The goal of the outpost design was to require as little manual alignment as possible. The 15 miners plop directly onto the minerals. Then, I plop one solar array (x4 substations worth) to support copper/iron smelting in the field (2 for steel smelting). Then, I plop a spur at the insersection between the outpost and the rail and rename the outpost to i1/c2/s3, etc. Each outpost is electrically independent, so there's no need to string power along the primary rail loop.
-The standard cell requires 2 oil, 1 fuel, ~0 brick/stone, 2 steel, 2 copper, and 4 iron outposts. Unfortunately, this number of outposts combined with the smelting in the field means that the components for a standard outpost run require my entire inventory plus three cargo wagons. Smelting in the field saves on inserters, but it's certainly not inventory-efficient, and running back and forth between the wagons and the outpost under construction is a painful timesink (esp on sand).
-Field smelting is also not very space efficient. While they's plenty of space out in the wilderness, there have been a number of mineral patches that were irritatingly too close to the rail line. Rotating the outpost also threw off the chest alignment, so squeezing the outposts into awkward spaces was also very time consuming. In the future, I'll probably lay out my outposts horizontally by default.
-I could probably also replace the outpost loops with spurs and double-headed trains. I originally built with loops because I was originally placing the trains at the outposts, but it's actually a lot easier to place them at grand central once all the outposts are placed. You avoid cross traffic on the way back and you get to carry less coal around.

11. The factory cell blueprint is large. It's large enough, in fact, that the game has issues plopping it if the ghosts don't start off in range of a roboport (https://forums.factorio.com/forum/vie ... 49&t=15063), so I've also dedicated an inventory slot to a skeleton blueprint of the cell, containing only rail, electric, and roboports.


12. The cell blueprint is several times larger than the game's default max zoom, but I made sure that the blueprint was centered so that it could be aligned and plopped from a standard zoom level. Still, to save the time and frustration of running from one end of the cell to the other every time I wanted to update the blueprint, I would use "/c game.player.zoom = 0.1" instead. I could have refreshed the blueprint without this command - I just chose not to.
-Shotgunning rocks, trees, and peaceful biter nests is, likewise, an utterly tedious waste of time. I used this command instead:
/c
game.forces.enemy.kill_all_units()
pos = game.player.position
area = {{pos.x - 20000, pos.y - 10000}, {pos.x + 20000, pos.y + 1.5}}
for _, enemyName in ipairs({"stone-rock", "dead-tree", "dark-thin-tree", "dry-tree", "green-thin-tree", "dark-green-thin-tree", "red-thin-tree", "green-tree", "dark-green-tree", "red-tree", "root-tree", "green-coral", "dead-grey-trunk", "dry-hairy-tree", "dead-dry-hairy-tree", "spitter-spawner", "biter-spawner", "small-worm-turret", "medium-worm-turret", "big-worm-turret"}) do
for _, entity in ipairs(game.player.surface.find_entities_filtered{area = area, name = enemyName}) do
entity.destroy()
end
end
-I also found extracting the skeleton blueprint of my cell blueprint tedious. I used this command to clear the non-rail/power/robo ghosts from my plopped cell blueprint:
/c
pos = game.player.position
area = {{pos.x - 20000, pos.y - 10000}, {pos.x + 20000, pos.y + 1.5}}
for _, entityName in ipairs({"fast-transport-belt", "solar-panel", "basic-accumulator", "pipe-to-ground", "small-lamp", "fast-inserter", "assembling-machine-2", "electric-furnace", "chemical-plant", "pipe", "long-handed-inserter", "fast-transport-belt-to-ground", "logistic-chest-passive-provider", "smart-inserter", "fast-splitter", "small-pump", "oil-refinery", "storage-tank", "assembling-machine-3"}) do
for _, entity in ipairs(game.player.surface.find_entities_filtered{area = area, type="entity-ghost"}) do
if (entity.ghost_name == entityName) then
entity.time_to_live = 0
end
end
end


13. The interesting thing about assembling rocket silos and satellites is that they require substantially more throughput than a belt inserter belt can provide. If you want to autosupply the assembler with any kind of throughput, you need to take advantage of chest-to-chest stack inserter bonuses like I do here...


14. ...and here.
-(yes, I have blue circuit pollution on my rocket control unit belt. D=)


15. My power and production stats are actually rather modest at rest. Some of it is from my isolated smelting, but a lot of it is coming from the fact that a lot of each factory cell is vestigial and idle. When the factory is expanding and building components for new cells, you can see the spike in assembler power, but because growth is linear while factory component production capacity expands, these spikes grow proportionately shorter and shorter relative to the resting power consumption of the skeletal (and semi-vestigial) roboports.


17. Cellular self-sufficiency is not efficient. It was never meant to be. It was meant to grow linearly to 100 cells, but alas, the framerate combined with the sand in my outposts has sapped me of the will to continue with this design. If the goal was to create a preposterously large factory, I believe I've accomplished it. The game is tracking a two million entities. The only real way for my computer to make a larger factory is to use larger components.


Epilogue. For my Mk. 4, I think I'd like to revisit the train-based transport design. I'd originally dismissed it because it was manual and didn't scale linearly - a train going back and forth on a supply rail would spend an exponential amount of time bringing materials to the latest cell/from the latest cell. The solution, in retrospect, is obvious - the supply rail should be a supply loop, with tracks for both incoming and outgoing trains. The train transport throughput can scale linearly by adding trains. The outbus transport could also be train-based, though the small-stack rocket components are actually really inventory-inefficient. One full rocket takes like 14 train cars to transport.

Also, since factory expansion is necessarily linear, I'd like to relegate the production of factory cell/outpost components to the root factory. Each cell can then be dedicated wholly to the production of rocket parts, minimizing the number of vestigial components in each cell.

To do this, though, I'd have to wait on a few things in the base game to change:
-Rail signals and stops would need to be controllable via circuit network. At any given moment, only one cell site should be active, and there's no automatic way to remove old cell sites or to send supply trains back. We would also need circuit logic to enable intelligent pickup of rocket materials for outbound transport to the root rocket array.
-Rail stop names would need to be blueprintable. I could get away with renaming the stops in each cell's grand central because they were centralized, but if a cell's supply and outbound transport is to be entirely rail based, I can't spend my time running across each plopped cell to rename each transport site's stops.
-Water needs to be barrel-able, or my boiling-oil water-less solution must be shown to be feasable (perhaps by aqueduct-ing acid instead of water?).
-I'd like to see roboports controllable via circuit network as well, to help isolate each factory's logistics network post-construction. This would make belt-less or mostly-belt-less factories appealing again, though I don't know how computationally taxing logistics robots are in the latest patch. It'd also be nice if construction robots prioritized electric/robo ghosts, to remove the need for skeleton blueprints.
-I might not need an outbus if it were possible to launch rockets remotely or via circuit network. Each cell could have its own rocket silo. I rather like the idea.

I've attached the save of the omnibus factory from just before the rocket launch, in case any of you wanted to push the button.

[GenericKen]

Comment reserved for save upload:

The save is 47 megs. Is that above the forum limit?

[ssilk]

No.

https://forums.factorio.com/forum/vie ... 55&t=16583

[GenericKen]

Hm. I can't seem to upload the save. Let me try an earlier, smaller save.

[GenericKen]

Let's try again w/ a 33mb save.

EDIT - that seems to be about the limit. Can't upload a 34mb file.

[Ackos]

I play the game as a minimalist. My poor brain is melting down looking at this. Will have to look at it more after lots of coffee.

[lyallp]

Far out!
Some people have way too much time on their hands!

[Bloodyaugust]

This is extremely impressive. I'd love to see a few features implemented to make this completely automated, namely:
*Ability to remove rocks via construction bots (or later mentioned combat bots)
*Ability to automate placement of blueprints (perhaps via a new building?) and removal area, with logic in place to handle invalid placement
*New type of combat-oriented bot, complete with its own functional operation area around roboports

It'd be amazing to get to a point where the game can essentially play itself, after a crazy amount of effort up-front.

[Ranakastrasz]

There are, or were mods for the second and third, and I am working on the first myself.

[m4ssl4gg]

Could you share the save through Dropbox or Google Drive, or is that forbidden by rules? I know there is an option in Dropbox to create a link to shared files, and probably there is one in Google Drive too.