Friday Facts #225 - Bots versus belts (part 2)

[Jap2.0]

Yeah! When you want to build a belt megabase, you need spaghetti!

In case you don't give a shit, then none of this matters since it is a sandbox game which you can play in any way you like. However, to me, the main bus is the most boring and brain-dead way possible to play Factorio.

Which is why we should use spaghetti.

[5thHorseman]

Yeah! When you want to build a belt megabase, you need spaghetti!

No you need trains, modular factory complexes and local minimum distance belt transport (ignoring bots for the moments since this is a belt vs bots topic).

I snipped all the talk on buffers because while I did find it very interesting (really! I'm not being condescending here) I couldn't find a good little snippet and didn't want to quote the whole thing.

However, what of the buffers inherent in train use? My railworld base performed just fine when I was transporting ores, plates, green circuits and gears around, but when I started moving red circuits and engines I started having problems, and at purple circuits I gave up on the concept. Does a (well-constructed) main bus really have more buffering than the chests that - as far as I know - must be at every train station and full enough to never run out when a train arrives or leaves?

EDIT: I must stress that this is an honest question. I've gone back and forth between rails and a bus a couple times this month and really don't know which has less buffering, but strongly suspect that it's the bus.

[Alice3173]

I snipped all the talk on buffers because while I did find it very interesting (really! I'm not being condescending here) I couldn't find a good little snippet and didn't want to quote the whole thing.

However, what of the buffers inherent in train use? My railworld base performed just fine when I was transporting ores, plates, green circuits and gears around, but when I started moving red circuits and engines I started having problems, and at purple circuits I gave up on the concept. Does a (well-constructed) main bus really have more buffering than the chests that - as far as I know - must be at every train station and full enough to never run out when a train arrives or leaves?

EDIT: I must stress that this is an honest question. I've gone back and forth between rails and a bus a couple times this month and really don't know which has less buffering, but strongly suspect that it's the bus.

This is just a guess at what Caine was getting at but I think the difference between a main bus and chest buffers is that the chest buffers, albeit having a higher capacity, are actually actively used while the main bus concept has a lot of product not being actively used due to its massive sprawling size.

[Caine]

This is just a guess at what Caine was getting at but I think the difference between a main bus and chest buffers is that the chest buffers, albeit having a higher capacity, are actually actively used while the main bus concept has a lot of product not being actively used due to its massive sprawling size.

Yes, the challenge is to get a JIT delivery of your goods to the station chests. I.e. just before they run out you want a train to arrive. You can measure demand by filling the train station buffers, time when a train arrives and check how much is consumed. Ideally the circuit network will take care of that, but that is whole challenge by itself. Trains give you a lot of knobs to play around with to configure the delivery timing and throughput. E.g. train size, dedicated inventory slots, number of trains, fuel types, etc. The tighter your configuration, the less you buffer.

Another thing to consider is what to produce remote and what locally. If you go back to the discussion and videos about the main bus vs the production bus (see reddit, youtube, etc.) , you will see that the latter adds more focus to what should and should not be on the bus. I.e. produce locally what you can. Keep producers and consumers of intermediate products close.

I do not have a ready made, general purpose solution for you and am still puzzling on many parts myself. But for me this is the logistic puzzle which makes Factorio so much fun. Balancing supply and demand as good as possible. The bus is a general purpose solution for producing anything you want and eliminates the whole logistic puzzle (by massive overproduction such that demand is always satisfied). However, the bus struggles with throughput and is more costly than trains. This is good, otherwise there would be no challenge at all.

[bobucles]

> Repostan from reddit.

The sustained throughput of a bot network is fundamentally linked to the charging rate of the roboports. When bots stop getting charged the whole system backs up and must wait, after all. A roboport's charging rate is up to 4MJ/s. Bots consume 5kj per tile. That means a roboport's "perfect sphere in a frictionless vacuum" charging rate is equivalent to moving 800 items, a distance of 1 tile, every second. A single blue belt moves 40 items across 1 tile every second. A vanilla roboport occupies 16 tiles, and its charging power has the same item moving potential as 20 blue belts. This value gets multiplied by 4x with cargo upgrades, so the same roboport ends up matching 80 tiles of blue belt, roughly 5 times as efficient per tile of territory.

Of course a robot doesn't turn its energy into item motion with 100% efficiency. That's a foolish assumption. Robots lose efficiency in a number of ways:

- The percentage of energy spent crossing tiles vs. idle energy loss. This value is initially low as bots move slow and lose a lot of time on the field. It'll approach 90%+ with extensive speed upgrades.
- The percentage of time bots are being useful. A bot moving items one way is at best doing work 50% of the time, since it has to return empty handed. A complex network gives bots plenty of work and plenty of opportunity to move items both ways. This value is the hardest to predict and will change for everyone. It goes down any time a bot veers off course to recharge or return to storage and goes up when bots do their job. If bots have to run half a screen away to recharge or cross a large U shaped network then this value can get disastrously low indeed.
- The efficiency of recharging bays. Those roboport slots aren't working 100% of the time. This value increases with robot speed as they can queue up faster, and drops dramatically if the bots wait too long and switch to low speed mode. A worst case efficiency rating can be 30% or worse when working with over taxed, low tech bots or it can be over 80% easily with full speed high tech bots. Not letting your bots run out of energy is thus VERY important to maintaining throughput.

So, does the theory match the practice? Dev testing concluded:

With this in mind, we can safely say, that robots are at least 2 times stronger then express belts, but in real factories, it is much more as belts need lot of other parts and are rarely used as ideally as robots would be, so my private guess would be that robots are currently around 5+ times stronger compared to belts.

The dev test compared 4 lanes of belts vs. a solid line of roboports (also 4 lanes) across some distance. The test was item transfer in one direction, which automatically cuts efficiency by 50% since bots make the return trip empty handed.

Code: Select all

assuming roboports have 5x blue belt potential 
x 50% efficiency from moving 1 way, nearly perfect path with no detours
x >90% movement efficiency with high tech bots (low idle drain)
x >90% recharge efficiency (bots recharging healthily)

Yielding a theoretical result of bots being... 2x as good. Just like the test. The theory seems to check out!


No other factors really affect the efficiency of a robot network. Storage doesn't matter and a healthy network layout isn't terribly important. Everything about robot throughput is all about that CHARGE rate and how EFFICIENT they are with energy.

One last thing. Roboports have a geometric advantage over belts because they can be placed anywhere while belts have to weave into their designs. This advantage is very important with modular bases. A small factory unit can lean and mean, and the logistic support can simply surround it. That same advantage is hard to duplicate with belts and is a key reason behind the strength of the bot mining base.

[Aeternus]

Hrn. Might just be me, but I don't bother with bots in my own megabase - tho it's still a fledgeling one. There are always at least 2 ways to solve a bottleneck:
- Increase throughput (the bot way)
- Parallelize the entire production facility.

Yea, people beaconize a lot to get a huge production in a teeny tiny area, but isn't the point of a megabase to have a huge, sprawling behemoth of a factory that has loads of activity in a wide area? It's orange over blue for me with the modules!

[Treahblade]

After reading this and considering it I think there are some rather simple fixes here and highlights why bots are better.

Belts cant move bots can.
Bots are instant when transferring goods to and from a container, and only have to consider travel times which can be researched to be increased.
Bots have a unlimited range as long as you have towers to recharge them along the way.

I think the simplest fix here is to do some or all of the following.

1. Make bots take up space in each tower limiting the number of bots you can have per tower. ( only works with not allowing 2 towers within each logistics area.
2. Require they have load and unloading times comparable or more then inserters. Maybe have tiers bots ( yellow, red, and blue ) logistic bots that have improved times. ( adds fun and complexity to that system )
3. Limit each container to only allow one bot ( could be overcome by players just building more which is not a solution)

[Pascali]

Bots vs. Fun

The goal must be that the most setups are only or much better working with (complicate and fun to build) belt-setups. There must be an reward for doing time(think)-intensiv belt-setups.

Alternatively make an research-upgrade for bots - where 1 bot can destroy all enemies in 1 second and launch 56535 rockets after 1,5 seconds. Or leave bots powerful like theay are. It´s not a huge difference.

[ske]

Bots, belts, beltbots, botbelts, in what shape do their souls meet? Flying carpets!

Let me explain.

On the ground it's a belt, a botbelt. The items move with it. As it reaches the takeoff location it transforms into a beltbot that flies liek a flying carpet to the next touchdown location where it turns into a botbelt again.

Building takeoff and touchdown locations is similar to building underground things. You build one and then the other and things move from one end to the other. Different from underground things is that the flying path can be crisscrossing other things diagonally and cover larger distances.

Botbelts always form a closed circle.

Beltbots need no dedicated charging stations like ordinary bots since they recharge when on ground.

This would be our reality if bots had never been invented.

[Durabys]

The issue is not bots. The issue is that people do not want the SIZE of their FACTORIES getting a hit by a Nerf Bat.

In other words: You can nerf bots all you want...but you must preserve the levels of ease of planning, building, managing and upgrading a factory...at the same level the game currently supports.

Anything else causes an uproar because, for people, the game is not about the ability to have a typical Bot'd Beacon'd Gigafactory. No. The game for them is about the ability to have a Gigafactory itself. People who like to build Mega- and Giga-factories are throughput obsessed. Take the possibility away from them in the form of making it outright impossible to build one or just make it horrendously unfeasible (the game becoming an even greater time hog), or just suggest it, and they will revolt, as has happened.

[Darthlawsuit]

Belts can only input so much into a factory at once. Bots can do infinite. Make it so only X number of bots can input/output from objects. Containers can allow a lot of input/output while factories can only do so many at a time.

[Durabys]

Belts can only input so much into a factory at once. Bots can do infinite. Make it so only X number of bots can input/output from objects. Containers can allow a lot of input/output while factories can only do so many at a time.

Also, allow Belt Loaders for the game.

[Lastmerlin]

The issue is not bots. The issue is that people do not want the SIZE of their FACTORIES getting a hit by a Nerf Bat.

In other words: You can nerf bots all you want...but you must preserve the levels of ease of planning, building, managing and upgrading a factory...at the same level the game currently supports.

Anything else causes an uproar because, for people, the game is not about the ability to have a typical Bot'd Beacon'd Gigafactory. No. The game for them is about the ability to have a Gigafactory itself. People who like to build Mega- and Giga-factories are throughput obsessed. Take the possibility away from them in the form of making it outright impossible to build one or just make it horrendously unfeasible (the game becoming an even greater time hog), or just suggest it, and they will revolt, as has happened.

Quoted for truth.

I am working on another megabase right now and realized: Its not that I am very keen on using bots. They are just the easiest and most UPS-efficient way of implementing the subfactories at the moments. If you do not want any UPS-hits at a certain size they are the only way. (By the way: I am not very keen on designing belt-based subfactories either. I have already created hundreds of belt-based designs, with and without beacons. Nothing new.) . I am keen on the pure size, the grand layout, the train network. If you provide a different way to implement the subfactories, that is as least as UPS-efficient, I would not object any bot-nerf. However, If the maximal factory size (for a given hardware and tolerated UPS) is reduced, I would be very sad and outrage is more or less guaranteed.

[darthtuttle]

So here's an idea for bots to nerf them a bit but still make them useful. Adjust the power needed by roboports so that the power usage scales differently. right now each roboport takes some amount of base power (50 kw?) and so your power scales linearly with the number of ports. You can just plop down ports with some power as you go.

Now consider this, let the base power consumption be x but make the actual consumption grow exponentially with the number of roboports based on how many logistics chests you have in it's logistics network, so each port takes

x(1+k*r)^n

where n is the number of roboports in the network, k is the number of logistics chests and r is some constant. This makes every roboport and every chest matter.

What does this do to game play? It lets roboports work just like they do now for people who like to use them but makes the player consider the value of expanding the network at will. A player might want to make more networks with fewer roboports. Making a new factory and just plopping down a couple of logistic chests for input/output can get expensive.

Let's look at how power usage grows; total power consumption for a network is

nx(1+k*r)^n

This grows at least exponentially in n but it also grows by r^(n-1) in r (the number of chests). So the power cost of adding a chest is determined by the number of roboports.

Alternatively you could switch the roles of chests and ports to encourage larger networks but less chests. Either way, the idea is that the more ports and chests you have the more work the roboports have to do to figure out the best way to respond to requests by chests and so each port needs more power.

Obviously other formula could be used if these limit the scale too much.

[fiery_salmon]

They are just the easiest and most UPS-efficient way of implementing the subfactories at the moments. If you do not want any UPS-hits at a certain size they are the only way.

Has anybody tested is it still true after belt performance fixes?

[Jap2.0]

They are just the easiest and most UPS-efficient way of implementing the subfactories at the moments. If you do not want any UPS-hits at a certain size they are the only way.

Has anybody tested is it still true after belt performance fixes?

The gap is far smaller, but I don't know if there is any conclusive evidence either way. Most of the community still says bots, although that may just be because that's what they're used to saying. Your implementation in a factory can also affect it a lot as well.

[Pod]

I used to play Factorio back in 2014, but stopped after I had grown dissatisfied with the belt mechanics and the way the splitters worked. It seems like belts and splitters should have been a core part of the game, but were entirely neglected. I used to use a mod to make the game feel like it wasn't neglecting belts as much, and after reading through the thread I'm fairly sure it was gotlag's one!


I came back for 0.16.x as I heard you guys "fixed splitters". Well, it seems like you both did and didn't. Yes, the merge/splitter behaviour is now intuitive and you can actually figure out which items will go where, rather than there being some random internal state counter. But the splitters are still an insane part that I feel should be done away with, or at least relegated to "early game" status. As evidence I present to you this wiki page.

Splitters, and their weird design, lead to the concept of belt balancers. When playing 0.16.x I often thought "hey, I'd like to merge/split these two lanes evenly", or "hey, I'd like to merge/split these belts evenly" or most often "hey, I'd like my iron belt to move both lanes evenly". Yet I found that to do so I'd need to plonk down an 6x12 chunk or random splitters sideloading into undergroundies that go nowhere. I would call this kind of behaviour demented, but the devs call it "emergent" (according to FFF #225).

I think you just need a 1-belt wide part that splits lanes [with options choose which L/R input lane goes to which L/R output lane, including "nowhere" as an option], a 1x1->2x1 part that splits belts and a 2x1->1 part that merges them. They could both have an option to ENFORCE left/right alternation, even if it means the merger part backs up one lane etc.

I think that would cause a lot of these "belt balancers" to be only a few parts wide and be easily useable. And this would really help belts become less of a hassle in large factories. Bots would still have the edge, but this change would at least be a positive one for belts rather than a negative one for bots.

[fiery_salmon]

Note that belt balancers are generally no longer needed thanks to splutter priority.

[daera]

My sugguestion how to make belt stack items and be somewhat readable and useful only for belt delivery.
What if stacking worked like train block signals. So each underground belt or splitter made a block, and exit of splitter or underground belt defined general stack size of items on belt, up to researched max. (Even though it is nothing but depiction shown as higher border over the belt)
The stacked items are not drawn any special and look the same.
Now how it works.
Items on belt don't stack or unstack
Underground belts:

• underground belt stack items inside up to max by default, but can be set up like inserter stack size.
• If stack with more items enters underground belt, rest go to storage inside belt and used to stack new stacks of sizes

[*]As effect underground belts would compress items into stacks, so if you don't like your belt compressed you don't use those or use only few to set stack size to one (and lock it)

Splitters:
They can be set one side as side to unstack to single items, other side would pass stacked unhindered.

Inserters:

• Inserters treat stacks as one item, so do take amount of stacks up to their stack size.
• Items inside containers are unstacked( so if inserter has stack size of 5 and belt passes stack of 2 inserter would put into box 10 items)
• Inserters putting into other producers(furnaces, boilers, assemblers and such) do unstack items in same way as they do with boxes.
• Inserters putting items on the belt decide how much items to stack, based on stack size of belt block they are in.
• Inserters would wait to have enough items to put on belt (aka if they output on belt of stack size of 2 the inserter would wait until it is able to grab 2 items)
• But inserters not wait for multiple stacks(in same way as factorio now doesn't wait for items now to fill inserter fully, there is small waiting period but it is mostly to provide efficiency) Inserter would wait to take 2 items to put on on belt of stack size 2, but wouldn't wait to put 4 items. (inserter can't put 3 on stack size 2)
• Inserters putting from one stack size belt to another, just put stack as is. (yeah it is only place where stack size of item is inconsistent with belt, but only until it reaches splitter or underground belt. Alternative inserters can't put on different stack size belt and require restacking. But even if it is more intuitive in terms of common idea, it might cause confusion of players not knowing how stacking works.

This way stacking may work automatic, and for most people fairly seamless, while leaving enough control when lower throughput or belt storage is required. It also allows easier depicting how much of items are on the belt (Can be higher borders, or different color sides, or anything really. it is better then make stacking image for every item)

[Oktokolo]

I would prefer something similar to this palletizing mod instead of stacking. Palletizing needs pallets and dedicated machines (in the linked mod this are regular assemblers set to [de-]palletizing recipes). It adds to the logistic challenges.

Empty pallets might be transportable by bots. Filled pallets would need to first get emptied by the bots before they finally can take the pallet.
Players should be able to pick up full pallets instantly decomposing them into the contained items and the pallet so there are never filled pallets in player inventories.
Assemblers schould not accept filled pallets except when configured to a depalletization recipe.

Trains, other Vehicles and chests may or may not be able to contain non-empty pallets. Not sure about that.

There definitely should be a whitelist of items that are palletizable. The list could initially include bulk materials like stone, coal, ore, plates, wires, gears, pipes, bricks, slabs, circuits, solid/rocket fuel, ammunitions, maybe barrels (not sure about them as they already represent a tier of compression).
For most items the pallet capacity should probably be less than a fourth of the stack size (except for the buggily stacksized artillery shell).