So... Let's talk about bots, and how to fix them properly...

[Jap2.0]

For everyone who is complaining about busses: I agree.

That's why you use spaghetti.

[wvlad]

+1 for limiting robots that accessing chest at the same time

Also I would make underground belts x1.5 longer to make belts easier a bit (there are mods already).

[Aeternus]

Main two problems of belts remain though:
- Hard limit to throughput due to max belt speed capping transfer rate. A fully compressed belt has a hard limit, bots have a practical limit too but it is much higher. You can go parallel and make a huge 8, 16 or 32 lane bus, but that will take gobs of useful space and leads to the next problem:
- Overuse of belts will tank your UPS. I attempted a cargo transfer station using belts, using a roundabout to move items around. Trains coming from mining outposts unload (2-4-0, iron and copper pre-smelted at the mines for better compression) and trains going to my factory load (4-12-0). There are 24 unloading bays that get disabled once they are not ready to receive another cargo (thus having some storage as well). I noticed a significant slowdown if there was a lot of metal on the belts there. Right now I'm testing an alternate configuration using bots - 3 unloading stations and 6 loading stations, with storage chests as a buffer. Seems to be working much better performance wise. But bulk cargo transfer is where belts -should- shine.

Loaders/unloaders (belt directly into a wagon or storage) could help by eliminating the inserter as a bottleneck and/or additional moving part that adds to the UPS hog. Being able to dump 40 items per second to/from wagons would make belts a more enticing choice for high speed cargo transfer stations.

[MeduSalem]

+1 for limiting robots that accessing chest at the same time

Which is effectively a Nerf... and Nerfs are usually hated upon by at least half the community as can be seen in other games as well. Wouldn't even be surprised if a lot of people would stop playing the game if Bots are nerfed this way because of how it renders their bases useless. So nerfing them is pretty much out of question.


The only way limiting chest access can go through is if each bot becomes more meaningful... meaning that the cargo size would need to be increased to make up for it. Less bots, but same throughput.

But that would make them even more UPS friendly because even less bots to update... meaning you can build even bigger bases.

Also I would make underground belts x1.5 longer to make belts easier a bit (there are mods already).

The red and blue underground belts already have been made much longer and it didn't change much.

What would increasing the underground belt length change anyway?

Doesn't solve any of the problems belts are suffering from.




So here is my updated list of problems:

• Item Transport/Distribution
  
  • Belt: Bus constructions just suck. Exactly for the reason that they don't scale well. If it becomes the bottleneck it usually means tearing down the entire damn factory because of how one couldn't expand otherwise.
  • Bots: Don't have that limitation with the Logistic Network. Just slap more roboports there to deal with an increasing amount of recharging robots.
  • Trains: Using a railnetwork for delivering items between departments and only using belts/bots locally has its own disadvantages.
• UPS problem
  
  • Belts: A real sucker due to the amount of moving items.
  • Bots: Scale much further before UPS becomes a problem.
• Inserter input to machines/chests
  
  • Belts: Even Stack Inserters are too slow when picking up from a belt since they need to wait for items to be moved into the inserter reach. Having multiple Inserters grabbing from the same belt results in them getting in each others way.
  • Bots: Inserters don't have that problem at all because they benefit from the inventory-to-inventory movement.
• Inserter output from machines/chests
  
  • Belts: Inserters can only put stuff to the far side lane of the belt, decreasing their efficiency by half. Changing lanes is usually an ugly contraption and doesn't always work in confined spaces (like between beacons). Also having multiple Inserters putting to the same belt results in them getting in each others way.
  • Bots: Don't have that problem at all, because again they benefit from the inventory-to-inventory movement.
• Recipe Complexity, Crafting Speed and Ingredient demand
  
  • Belts: Complex, Fast or Demanding recipes require more than 1 or 2 belts to be fed. Becomes a problem in confined spaces (like between beacons). Workarounds are Sushi Belt (which is throughput limited) or Belt Braiding using Fast/Express Underground Belts (which some consider a hack).
  • Bots: Don't have that problem at all. Everything can be done with one Requester Chest and Inserter... and for high volume throughput maybe a second Requester Chest/Inserter.

Since nerfing bots is controversial at best, I think it should be about dealing with the restrictions of belts.

I think the devs have brought up some interesting concepts themselves to solve the belt problems back in the FFF-225



In my opinion they should probably give all belts the abillity to carry stacked items (with each stack consisting only of the same item type though)... and give inserters the abillity to unload a stack directly onto a single belt position (to a certain height).

That alone would already increase the item density on the belt and with it the throughput... and solve several problems of the above list at once, without having to invest in further infrastructure or having to tear down stuff.

The only thing would be the visual part, but I think that it could just be "implied" to be a stack by using a single sprite that looks like it has a height/thickness.

1 Iron Plate sprite:

Iron Plate.png (24.55 KiB) Viewed 6159 times

5 Iron Plates sprite:

Iron Plate Stack.png (28.25 KiB) Viewed 6159 times

Something like so. But then again I don't know how much of a problem it would be for the draw order of sprites, especially performance wise.

One could also discuss that the stacking mechanic only works on certain item types (especially high demand intermediate items like ore, plates, circuits, etc, everything that makes sense to be stacked). But then I am also willing to to discuss that it might be an idea to force the same limitation on bots as well. The latter isn't even that bad because usually you need finished products only in low quantities anyway, so nothing would be lost if the carryable stack size for bots would get reduced for finished items.

Also what I would do is give an inserter the option to either unload to the far side or near side of the belt.

[Aeternus]

Why not use the item's natural stack size instead? A crate with the sprite of the item overtop of it, indicating a full stack of whatever item it is from. That kind of mechanic should be compatible with any modded in items and eliminates the need for sprite stacking.

IE a special "Boxer" container that you dump for instance 280 metal into... outputs 2 "crates" of metal that represent a full stack of the stuff, leaving 80 behind in the boxing structure since it can't make a full stack out of it. You would not be able to load these boxes directly into assemblers, first unbox them.

Advantages:
- Extreme compression especially on high-stack items (those going to 200 especially).
- Unloading trains directly into boxing structures could allow for very high throughput through belts, especially for high-stack items
- Fewer moving units, helps with UPS
- Stuffing a box into an unboxer basically equates to the "inventory to inventory" you mentioned earlier. It'll allow stack inserters to be used to their fullest capacity.

[MeduSalem]

Why not use the item's natural stack size instead? A crate with the sprite of the item overtop of it, indicating a full stack of whatever item it is from. That kind of mechanic should be compatible with any modded in items and eliminates the need for sprite stacking.

IE a special "Boxer" container that you dump for instance 280 metal into... outputs 2 "crates" of metal that represent a full stack of the stuff, leaving 80 behind in the boxing structure since it can't make a full stack out of it. You would not be able to load these boxes directly into assemblers, first unbox them.

Advantages:
- Extreme compression especially on high-stack items (those going to 200 especially).
- Unloading trains directly into boxing structures could allow for very high throughput through belts, especially for high-stack items
- Fewer moving units, helps with UPS
- Stuffing a box into an unboxer basically equates to the "inventory to inventory" you mentioned earlier. It'll allow stack inserters to be used to their fullest capacity.

You mean like the boxing/unboxing mod stuff where you require an assembler or other additional item to box/unbox everything? Pretty much like barreling... just for every item type?

I think it would become mandatory to place the boxing/unboxing machine everywhere, hence why the boxing/unboxing mechanic could be integrated inside the various machines themself already.

Would it require boxes to be crafted and dealt with, just like you have to deal with empty barrels? :S


Also when such a thing would be done the "belt vs bot" situation reverses... Bots would get curbstomped by belts using boxes... and people would start complaining and arguing all over again that bots are worse off as calculations further below will show ... So what that means is... the boxes would eventually have to work for bots as well... and each bot can only ever transport 1 such box.


I actually think that it might end up quite fair if both belts and bots could do it. The amount of moving items would be the same... either 1 box on the belt... or 1 bot carrying 1 box. Both would probably have about the same UPS... and both would have the same benefit of inventory-to-inventory movements bypassing absolutely all limitations/restrictions. Logistic Chests could then also be changed to only serve 1 bot at a time, which would be fair, even though it wouldn't really matter much anyway because transport wouldn't be the limiting factor but rather machine speed.


But if you ask me that leads to further thoughts... why not abandon "single item transport" for the game entirely because it is only a throughput and UPS problem anyway... and instead just use boxes everywhere for item transfer between all the entity inventories like machines, trains, chests, player, etc

Let assemblers/furnaces etc directly output only full boxes (removes the boxing/unboxing intermediate step altogether as it is integrated into the assembler itself)... and as input they directly take boxes as well which they slowly consume as the recipe crafts away. The Assembler/machines could only ever hold 1 box of each recipe ingredient type at a time so it doesn't overcommit.

Inserters would be able to move an entire box at once. The fun part would be that it removes the need for Fast inserters and Stack inserters altogether because a regular inserter would then be fast enough to load/unload the boxes into/from the assembler even if the setup is speed beaconized to hell.

It even removes the need for Fast and Express belts... because a single tile regular belt would then have what... 6 boxes on it each with 100 Iron plates? ... like 600 items on a single belt tile... with a belt speed of ~2 tiles/sec that would make a throughput of 1200 items/sec... for a hypothetical total of 72000 items/min... all of that on a shitty-ass yellow belt? A 30 parallel Express belts bus compressed to a single yellow belt. Hell yeah... why not. You would never see backed up belts again... Ever!

But to balance it somewhat the size of the boxes itself could then be something that is researchable... so your Iron Plate box at the start of the game would first have like 1 plate... and at the end of the game 100 plates. Or even infinite which means it scales beyond ridiculousness allowing for bases the size one cannot even imagine.

At least it would bring belts and bots to equal throughput/UPS levels... and it would then be just a matter of preference if one likes to use belts or bots.



Oh wait... the core essence of Factorio might be gone.

That isn't even considering the effects it would have on Trains since they wouldn't be able to compete at all anymore when a yellow belt can do 36 times as good as a single cargo wagon. Or the effects it would have on Circuit Networks... would probably also be rather interesting.



Hence why I think it might be better to just have 4-5 items per stack on a belt and not more. Everything else would possibly render the game a mess.

The 4-5 items per stack on a belt would deliver similar UPS as bots. Think about it... 1 bot corresponds to 4 items at best. Meaning 1 stack on a belt would also correspond to 4 items. The same amount of moving entities.

The throughput should also be roughly equal... 4 items delivered by bot... or 1 stack consisting of 4 items delivered by belt.

[HurkWurk]

if we are going to go the stacking route, why not just add stack recipes to replace older single input recipes.
IE instead of a furnace using 5 iron plate to make 1 steel, it uses 5 crate iron (and X amount extra time) to make 1 crate steel.
each other recipie could also have crated versions.

[MeduSalem]

if we are going to go the stacking route, why not just add stack recipes to replace older single input recipes.
IE instead of a furnace using 5 iron plate to make 1 steel, it uses 5 crate iron (and X amount extra time) to make 1 crate steel.
each other recipie could also have crated versions.

Why would you ever NOT want to stack items once you are able to stack them?

Also it would be an absolute hell of a nightmare of a clusterfuck if there is a specific boxing/unboxing/stacked recipe for every single item ontop of the usual recipes. Double/Triple all the selectible assembler recipes. There is no way I would ever support that.

I already hate that the Fill Barrel and Empty Barrel recipes aren't dynamic/generic so that it adapts and takes a barrel and outputs whatever fluid is in that barrel OR whatever fluid is in the fluid input of the assembler and puts that into a barrel. I already hate that there are 14 recipes for what could effectively be done with 2 recipes... "Fill Barrel" and "Empty Barrel". In my opinion the way it is now is among of the most fucked up things currently in the game where instead of making one generic solution that works with any fluid/filled barrel (including modded ones) ... the devs rather went for a stupid bandaid.


Boxing/Unboxing has to be done either with following:

• Dedicated boxing/unboxing recipe using an assembler ... which is a no-go due to increased amount of needed space and overall infrastructure. No one would like that. Ontop of that it would have to be a generic/dynamic recipe that works on whatever item it gets fed and puts it into a box/takes it out of the box to avoid the duplicate recipe nightmare again.
• Dedicated boxing/unboxing machine ... which also requires an additional item which would have to be placed everywhere, and even if it is only 1x1... there is often just not enough space to even place it. Imagine it... you have an inserter take items out of an assembler put it into the boxing machine and the box then being put onto the belt by another inserter... UGLY. It is a huge problem, especially between beacons.
• Automatic Boxing/Unboxing within Assembler/Furnace ... where assemblers automatically create a filled box as output and take boxes as input ingredients. Like I wrote in my previous post. It is the most realistic possibility of the three because it requires no additional items or recipes.

Belt-Stacks on the other hand would be done by inserters anyway, hence no need for any specific boxing/unboxing recipes.

[bobucles]

Item crating doesn't tilt the balance between belts vs. bots. It only buffs both of them to absurd levels. If anything it ends up ruining trains! Why use a train when you can get even better throughput by belts? I like trains! I don't want to see them become second class logistics.

What if Bots can't carry crates?

No. That's a baaaaaad idea. If bots can't move crates, then you have no way of dealing with a crate spill that drops them all over the place. They can only be picked up by hand? That defeats the automation aspect of Factorio. Don't use solutions that make strange, scary problems.

You put them on the belt.Then you put more on the belt

This so far remains the coolest solution to belts vs. bots. Item stacking presents a few new inserter functions and puzzles for players to deal with. If I designed it I'd go for
* only matching items stack
* only stack inserters(and maybe ore mines) can make stacks
* any type of inserter can grab from a stack
* Only the bottom item is tracked for belt compression (items don't magically slide across the top to compress)
The visual aspect stays simple. If you see a really thick item then you easily know it means multiple copies of that item. It simplifies things code wise as belt slots can be stored as "iron x 3" instead of "iron + iron + iron". The inserter rules mean that players have fine control over how they want to fill a belt, without presenting any problems when using resources from a belt. Stack inserters may also gain an extra option to control how high they want to stack. Stack inserters move 12 items per swing, so items should stack up to a nice multiple like 4 or 6.

In truth many items don't ever need the higher throughput of stacking. A fat lot of raw materials transform into a tiny amount of high tech items which are pretty easy to move by belt. The only items that truly benefit from stacking would be ultra low tech raw materials such as ore, plates, gears and green circuits. These types of belts add up very quickly and can dominate a player's designs before higher tech items even even reach a belt's capacity. I do think that ore mines should benefit from stacking, because super high mining productivity will fill a belt insanely fast.

[dragontamer5788]

I apparently missed the debate. So I apologize if this has already been brought up before.

But Bots have a hard-cap on the bandwidth they can accomplish, determined by the charging time from each Roboport. I've written this up on Reddit.

Logistic Bots : The Charging Network is the limitation. Assuming infinite speed (aka, literally infinite infinity research), Bots will still use 5.0kJ per meter. 4-bots per Roboport, each roboport is a 4x4 building with 1MW per bot recharge rate.

That's: 200 meters of charge per second, x4 bots per 4-squares of linear distance, with a cargo-size of 4 per Logistic Bot. I estimate a theoretical limit of ~800 items per second sustained per "lane" of Roboports. Having less than infinite research or having fewer than infinite roboports will lower the bandwidth. (ex: 10% roboport coverage, which is a Roboport every 40-tiles, would only sustain 80 items per second per roboport lane). "Bursting" bandwidth is strong due to the battery-packs of Logistic bots. A train-station may only be served every 15 seconds, giving more time for the roboports to charge more robots.

This is a slightly optimistic assumption: because the bots only traverse one way. In reality, bots need to travel every distance twice (once to pick up something, and once to return to the starting location). So maybe 400-items per second is closer to the theoretical limit of bots (after infinite speed + infinite roboports).

In short, a space with one-roboport every 40-tiles will only have the capacity of 2-blue belts due to the charging limitation. A dedicated line of Roboports would be 800-items per second (400-per-second, if you account for the return trip). Basically, if you want to "buff belts" so that they can compete with Roboports, simply make a belt that handles 100-items per second (to tie Roboports), or go higher if you wish for Belts to be superior. Maybe a 4x4 "Super-express Belt" system which can handle 500-items per second, or maybe 1200-items per second (+50% faster than what Roboports can currently accomplish) would be ideal. For proper balance, it should cost roughly the same as a Roboport (405 iron, 225 copper) per 4x4 unit.

Trains still win in theoretical bandwidth by an order of magnitude btw. I estimate a rail-line filled with 33% engines and 66% wagons would have a maximum bandwidth of 15773 items/sec (assuming an infinitely long train of 33% engines and 66% wagons). Reality has traffic, signals, and other such issues that would drop the efficiency by huge margins. But a well-designed rail-system realistically handles something on the order of 5000+ items per second. Not bad for a 2x2 unit that only costs 1 stone ore and 5.5 iron.

Ultimately, Roboports are actually in a cool position at ~400 items/sec (for a 4-wide design). Pure Roboports are still too slow to handle the output of a well designed train station (!!!). Consider a 4x station connected to a 2-4 wagon train system offloading Green Electric Circuits. To offload 4-trains would require movement of 128000 items, roughly at a rate of 1280 items/sec. It would require something on the order of 3x "lanes" of Roboports to handle this level of traffic.

I guess Roboports can be slightly nerfed, but the general feel of the game IMO benefits from making sure things don't get too good compared to trains. So I'd be wary of making any item in the game able to handle more than 400-items per second over 4-wide squares. Nothing should be faster than that IMO.

[MeduSalem]

You put them on the belt.Then you put more on the belt

This so far remains the coolest solution to belts vs. bots. Item stacking presents a few new inserter functions and puzzles for players to deal with. If I designed it I'd go for
* only matching items stack
* only stack inserters(and maybe ore mines) can make stacks
* any type of inserter can grab from a stack
* Only the bottom item is tracked for belt compression (items don't magically slide across the top to compress)
The visual aspect stays simple. If you see a really thick item then you easily know it means multiple copies of that item. It simplifies things code wise as belt slots can be stored as "iron x 3" instead of "iron + iron + iron". The inserter rules mean that players have fine control over how they want to fill a belt, without presenting any problems when using resources from a belt. Stack inserters may also gain an extra option to control how high they want to stack. Stack inserters move 12 items per swing, so items should stack up to a nice multiple like 4 or 6.

I agree... That is how it should look like more or less summed up. Stacks on the belt seems like the best solution dealing with most belt problems without introducing another load of problems.


About the Stack Height:

The height of the Stack is something that would need some careful balancing. The problem there is... if you make it too low (<=3 or something) then it doesn't solve Throughput/UPS/Inserter Problems enough. If you make it too high (>=10) the belts start to outperform Bots by a lot. The thing is rather delicate I would say and requires more in-depth thought.

While 4 items per stack would hypothetically be enough to compete with the 4 items carried by a single bot, the problem is that the bots benefit from inserter inventory-to-inventory movement as a Stack Inserter moves 12 items in one swing from the Assembler to a Logistic Chest and vice versa. Even if a single bot can only carry 4 items at once... the parallel access is unlimited so if a Stack Inserter moves 12 items to the chest 3 bots come up and take it.

If the Inserter can't do the same to the belt in just one swing... then you become inserter-bottlenecked with belts, requiring more than 1 inserter to output to the belt to achieve the same performance... so you'd still be unbalanced because of additional infrastructure needed to make up for that downside, which is already largely the reason for why people abandon belts.

To counteract that I say that if one goes for Stacks on the belts it either requires belt-stacks with the height of 12 (which is ridiculously high) or also requires some nerfs to the maximum amount of items per swing for Stack Inserters.

If the maximum Stack Size on the belt would be for example 4 and the Stack Inserters can also move only a maximum of 4 items from inventory-to-belt or from inventory-to-inventory (chest-to-chest/chest-to-assembler) then we have eliminated the inserter bottleneck and made belts competitive to bot throughput wise and UPS wise since a bot can also only carry 4 items.

Whatever the Stack Size on the belts is... the following rule should be applied:

Code: Select all

Belt Stack Max Size == Stack Inserter Max Size == Bot Cargo Max Size

If you change one of them... the others need to be changed with it.

Not sticking to that rule would result in giving either belts or bots an advantage or a disadvantage over the other.

[HurkWurk]

Item crating doesn't tilt the balance between belts vs. bots. It only buffs both of them to absurd levels. If anything it ends up ruining trains! Why use a train when you can get even better throughput by belts? I like trains! I don't want to see them become second class logistics.

What if Bots can't carry crates?

No. That's a baaaaaad idea. If bots can't move crates, then you have no way of dealing with a crate spill that drops them all over the place. They can only be picked up by hand? That defeats the automation aspect of Factorio. Don't use solutions that make strange, scary problems.

thats the whole point of this discussion though.. that somehow bots are strange and scary and need to be "delt with" in a way to make belts more capable.
I for one, do not see bots that way. but im also not against making changes either, especially if those changes help the whole game. .

and yes, cleaning up a spill by hand is perfectly acceptable for using a non-bot compatible solution to me. if the goal is some sort of "separate but equal" solution as seems to be the theme of the discussion.
in my mind simply adding crating or stacking does NOT give belts any advantage because bots can use it too. there has to be something that breaks the solution to NOT work with bots. otherwise you just make bots more powerful.

I already play with mods that double the speed of belts and inserters, etc, so that they are competitive with bots, however they still are not as space competitive as dual beacon row factories still out produce anything that belts can do in a similar footprint by a large margin.

So unless someone is going to solve the issue of space use, the only place belts and bots can logically compete is power space requirements, which means non-beaconed vs beaconed layouts, and using efficiency + productivity and reducing the space use by solar farms instead.


to me, the real issue with bots is being able to beacon speed modules. this allows for a massive density increase that belts cannot compete with.
**IF** i wanted to make belts compete with bots, then the starting point would be to remove/alter beaconing. being based on space is too powerful. instead, i would make it so beaconing is a 1 to 1 ratio and that a dedicated wire between the beacon and target is needed, but having the standard wire range. in that way spaghetti belts could work around a new, smaller beacon device and only need a single (pink/purple/some other color) wire to connect to it.
personally i would do away with beacons and add another layer of machines. (machine 1 2 and 3 with more module slots, IE built in beacons)

Even with that, there is still no real way for belts to make up for the space they use. bots are always a better solution until there is something specifically that bots cannot do (like crating)


the other thing you could do to cripple limit bots would be to limit the things they are allowed to transport. if logistic bots can only move intermediate goods, and all finished goods had to instead move by belts, then you force the use of both. in that scenario, only construction bots would be able to place finished goods, but not to transport them. (makes little sense, but there you go)
to me, the solution would be that nothing is ever a finished good until its assembled on the map... IE instead of placing a "machine 1", we place 9 components. and once they are all in place, then it becomes a machine 1. to upgrade to a machine 2, we replace 1-3 components.
IE nothing would be bigger than a single square on the map. to build a machine would take 9 bots or 1 bot nine trips.

[MeduSalem]

to me, the real issue with bots is being able to beacon speed modules. this allows for a massive density increase that belts cannot compete with.
**IF** i wanted to make belts compete with bots, then the starting point would be to remove/alter beaconing. being based on space is too powerful. instead, i would make it so beaconing is a 1 to 1 ratio and that a dedicated wire between the beacon and target is needed, but having the standard wire range. in that way spaghetti belts could work around a new, smaller beacon device and only need a single (pink/purple/some other color) wire to connect to it.
personally i would do away with beacons and add another layer of machines. (machine 1 2 and 3 with more module slots, IE built in beacons)

I agree on that. Beaconized setups are mainly the source of the problem of why we see so many bot based factories. I even have pointed it out in this thread already, and even on the controversial Friday Facts thread. I know it first hand because I am one of the bot-base guys who abandoned belts simply because they largely suck with Beaconized setups.

The crafting speed and resulting resources/second demand of beaconized setups are the death to classic belt mechanics and everything else related to belts.

The belts can't keep up throughput wise and UPS wise.
The inserters can't keep up throughput wise (even stack inserters take too long to pick up from a belt since they always have to wait for the items to come in reach even if the belt is fully compressed)
Recipe complexity becomes a problem between beacons... not enough room for all the belts/inserters required to feed all the ingredients required by certain recipes.



Maybe Beacons and Modules should be removed from the game altogether... or completely reworked in how they work.

Currently the only viable solution to play is PM3 in machines and SM3 in beacons anyway. Anything else is a waste of resources, a waste of space, a waste of time. It is like you are forced to do it if you want to achieve high Science/Minute output... which also is the only real goal beyond the first rocket launch.

I can't remember when I last used Efficiency Modules anywhere except Miners once your infinite productivity research is high enough that additional PM3s inside miners don't make any noticable difference. But on intermediate items anything but PM3s is a waste of resources... and finished products aren't required in large quantities... and mostly 1 single assembler is sufficient to deal with the demand of that item type.

The way beacons effect machines, the way it limits building space and forces specific layouts is just ugly.

But you are also right when you say that even if beacons wouldn't be in the way of more belts... the bots still would win space wise because all you need is 2 damn inserters and 2 chests per assembler... while belts require multiple inserters and multiple belts for many but the most simple recipes.

the other thing you could do to cripple limit bots would be to limit the things they are allowed to transport. if logistic bots can only move intermediate goods, and all finished goods had to instead move by belts, then you force the use of both.

That is exactly the opposite way of which belts and bots where initially intended. Back when the game started out it was intended that belts do the bulk transport and bots the low demand items.

Nowadays it is more about that belts and bots should be both equally capable, like you wrote yourself, but just different methods/approaches to the problem.

No matter what, limiting one or the other to only be able to transport a certain type of item is not going to work because the community would surely ragequit, so it is not a viable solution.

[bobucles]

Code: Select all

Belt Stack Max Size == Stack Inserter Max Size == Bot Cargo Max Size

If you change one of them... the others need to be changed with it.

I don't follow. These things are not equal and they're the wrong comparisons to begin with. Inserters simply transfer items between sources and are not a (useful) method of long distance travel. Belts are a challenging method of moving items around. Bots are a simplified method of moving items around. A fair design ensures that easy solutions suffer some kind of downside over challenging solutions. Otherwise the latter becomes obsolete and that's a sad thing.

Not sticking to that rule would result in giving either belts or bots an advantage or a disadvantage over the other.

But they're not equal. It's completely unfair to treat all stack sizes as equal because not all stacks process at the same rate. Bot stacks pile up in huge numbers and belt stacks would build up pretty quickly as well. Stack inserters utterly sluggish by comparison. Making all their cargo capacities equal "because same numbers are Equal" is a disaster in the making.

Bots have an item routing advantage that belts will NEVER have. Their current setup ALSO gives them some niche throughput advantages that belts struggle to compete against. Having one advantage but not another is a tradeoff. Having both advantages makes them flat out superior.

Beaconized setups are mainly the source of the problem of why we see so many bot based factories.

I can't say I agree on this point. Beaconed productivity actually creates a huge REDUCTION in the need for item transport. Why?
1) Speed Beacon setups are physically more compact so that either belts or bots have less distance to travel. The same goal gets solved with fewer belts or bots overall.
2) Free item production reduces the number of raw materials a base needs. Thus fewer belts and bots are needed to meet the same goal.

A full prod3 chain cuts the cost of a rocket down to a third of its original cost, easily. It doesn't matter if your base is running 10 belts of ore or using 1000 bots to process an ore base. Without that productivity doing its thing, those numbers are automatically tripled. Instead of 10 short belts you now need 30 long belts, and instead of 1000 bots you need 3000 bots times a land multiplier to cover the extra real estate. The prod3 beacon base not only shrinks your base vertically(throughput) but horizontally (distance covered) as well, creating a power of 2 reduction in total amount of item movement your base requires.

I currently run a full prod3 beacon base off of a set of 40 iron and 40 copper lines. If I removed all the prod3 steps I would need over 120 iron and 120 copper lines to get the same number of rockets! It doesn't matter if bots or belts are stronger at that point, because either solution will struggle to move all those raw resources.

TLDR: Beacons aren't to blame for bots. If anything, a base without beacons is so logistically demanding that they can't be satisfied with either bots OR belts.

[MeduSalem]

I don't follow. These things are not equal and they're the wrong comparisons to begin with. Inserters simply transfer items between sources and are not a (useful) method of long distance travel. Belts are a challenging method of moving items around. Bots are a simplified method of moving items around. A fair design ensures that easy solutions suffer some kind of downside over challenging solutions. Otherwise the latter becomes obsolete and that's a sad thing

[..]

But they're not equal. It's completely unfair to treat all stack sizes as equal because not all stacks process at the same rate. Bot stacks pile up in huge numbers and belt stacks would build up pretty quickly as well. Stack inserters utterly sluggish by comparison. Making all their cargo capacities equal "because same numbers are Equal" is a disaster in the making.

Bots have an item routing advantage that belts will NEVER have. Their current setup ALSO gives them some niche throughput advantages that belts struggle to compete against. Having one advantage but not another is a tradeoff. Having both advantages makes them flat out superior.

You completely failed to see my point.


The problem is that belts not only suck because of their own throughput limitations. They also suck because of inserter limitations due to inventory-to-belt transfer. That is something most people seem to ignore and forget completely.


Bots are not only far superior because of their masses... they are also superior because they don't suffer from inserter limitations as much as belts do. A Stack Inserter can move 13 items in one swing from Assembler to Chest and vice versa effectively allowing 3 bots to pick up items in parallel.


Inserters outputting to belts suck completely and they would continue to do so even with belt stacks if the belt stack size isn't adjusted to exactly the same value as the inserter stack size. If the belt stack size is only a little amount smaller you already need 2 or more inserters to output the assembler contents to 2 or 3 stacks... or 1 Inserter that has to wait for the damn stack to move along the belt to be able to put the next stack on it, which requires more time and that is what is also hurting throughput. So:

Belt Stack Size = Inserter Stack Size


The reason why Bot Cargo Size is also important because of UPS concerns many players raise all the time. If you want belt stacks to have about the same performance as bots then 1 stack of the belt must correspond to 1 bot on the map or otherwise people will continue to use whatever requires less moving items to be calculated. So:

Bot Cargo Size = Belt Stack Size


Now hopfully you should understand why those three are in a fragile correlation.

I can't say I agree on this point. Beaconed productivity actually creates a huge REDUCTION in the need for item transport. Why?
1) Speed Beacon setups are physically more compact so that either belts or bots have less distance to travel. The same goal gets solved with fewer belts or bots overall.
2) Free item production reduces the number of raw materials a base needs. Thus fewer belts and bots are needed to meet the same goal.

A full prod3 chain cuts the cost of a rocket down to a third of its original cost, easily. It doesn't matter if your base is running 10 belts of ore or using 1000 bots to process an ore base. Without that productivity doing its thing, those numbers are automatically tripled. Instead of 10 short belts you now need 30 long belts, and instead of 1000 bots you need 3000 bots times a land multiplier to cover the extra real estate. The prod3 beacon base not only shrinks your base vertically(throughput) but horizontally (distance covered) as well, creating a power of 2 reduction in total amount of item movement your base requires.

I currently run a full prod3 beacon base off of a set of 40 iron and 40 copper lines. If I removed all the prod3 steps I would need over 120 iron and 120 copper lines to get the same number of rockets! It doesn't matter if bots or belts are stronger at that point, because either solution will struggle to move all those raw resources.

TLDR: Beacons aren't to blame for bots. If anything, a base without beacons is so logistically demanding that they can't be satisfied with either bots OR belts.

You are coming from the typical "theorycrafting" side of Beaconized PM3/SM3 setups... "PM3s reduce the amount required items etc"... yeah they do, and I am completely aware of all of that because I am using it myself and have even developed my own spreadsheets.


The problem starts when you try to implement that stuff with belts and find out that most of the belt related setups are for the garbage can because they just don't work at all because of how belts are too slow, because of how inserters are too slow, because of how you can't fit all the belts and inserters and electric poles between the beacons due to space restriction and whatnot... and all of that requiring massive amounts of hacks and workarounds to overcome, if even possible at all.

So yes. Beaconized setups are part of the problem since it is where most of the throughput and space restrictions people are constantly complaining about originate from.

And that is like that because of how Beaconized Setups have become mandatory if you want to build a megabase. Without it the UPS would probably take a nosedive long before that due to the amount of entities in need of being updated.


Also beaconized setups allowed people to push the limits of the game to where it is now in the first place where people all of a sudden require 200k Iron Ore/Minute and whatnot with like 80 belts in parallel just for one item type and crazy stuff like it. Without ridiculous megabases like those people wouldn't even be complaining about the gap between Belts and Bots.

[dog80]

So limit the amount of items bots can take out of chests? Like bots waiting for recharge - bots wait to pickup items.

+1 for limiting robots that accessing chest at the same time

Which is effectively a Nerf... and Nerfs are usually hated upon by at least half the community as can be seen in other games as well. Wouldn't even be surprised if a lot of people would stop playing the game if Bots are nerfed this way because of how it renders their bases useless. So nerfing them is pretty much out of question.

maybe its a nerf for bots but its a buff for realism.

and for the 2. part - there is(will be) a mod for that

[ratchetfreak]

I apparently missed the debate. So I apologize if this has already been brought up before.

But Bots have a hard-cap on the bandwidth they can accomplish, determined by the charging time from each Roboport. I've written this up on Reddit.

Logistic Bots : The Charging Network is the limitation. Assuming infinite speed (aka, literally infinite infinity research), Bots will still use 5.0kJ per meter. 4-bots per Roboport, each roboport is a 4x4 building with 1MW per bot recharge rate.

That's: 200 meters of charge per second, x4 bots per 4-squares of linear distance, with a cargo-size of 4 per Logistic Bot. I estimate a theoretical limit of ~800 items per second sustained per "lane" of Roboports. Having less than infinite research or having fewer than infinite roboports will lower the bandwidth. (ex: 10% roboport coverage, which is a Roboport every 40-tiles, would only sustain 80 items per second per roboport lane). "Bursting" bandwidth is strong due to the battery-packs of Logistic bots. A train-station may only be served every 15 seconds, giving more time for the roboports to charge more robots.

This is a slightly optimistic assumption: because the bots only traverse one way. In reality, bots need to travel every distance twice (once to pick up something, and once to return to the starting location). So maybe 400-items per second is closer to the theoretical limit of bots (after infinite speed + infinite roboports).

In short, a space with one-roboport every 40-tiles will only have the capacity of 2-blue belts due to the charging limitation. A dedicated line of Roboports would be 800-items per second (400-per-second, if you account for the return trip). Basically, if you want to "buff belts" so that they can compete with Roboports, simply make a belt that handles 100-items per second (to tie Roboports), or go higher if you wish for Belts to be superior. Maybe a 4x4 "Super-express Belt" system which can handle 500-items per second, or maybe 1200-items per second (+50% faster than what Roboports can currently accomplish) would be ideal. For proper balance, it should cost roughly the same as a Roboport (405 iron, 225 copper) per 4x4 unit.

Trains still win in theoretical bandwidth by an order of magnitude btw. I estimate a rail-line filled with 33% engines and 66% wagons would have a maximum bandwidth of 15773 items/sec (assuming an infinitely long train of 33% engines and 66% wagons). Reality has traffic, signals, and other such issues that would drop the efficiency by huge margins. But a well-designed rail-system realistically handles something on the order of 5000+ items per second. Not bad for a 2x2 unit that only costs 1 stone ore and 5.5 iron.

Ultimately, Roboports are actually in a cool position at ~400 items/sec (for a 4-wide design). Pure Roboports are still too slow to handle the output of a well designed train station (!!!). Consider a 4x station connected to a 2-4 wagon train system offloading Green Electric Circuits. To offload 4-trains would require movement of 128000 items, roughly at a rate of 1280 items/sec. It would require something on the order of 3x "lanes" of Roboports to handle this level of traffic.

I guess Roboports can be slightly nerfed, but the general feel of the game IMO benefits from making sure things don't get too good compared to trains. So I'd be wary of making any item in the game able to handle more than 400-items per second over 4-wide squares. Nothing should be faster than that IMO.

There are a few other niggles here that help put roboports as superiour,

belts have to be (nearly) continuous from source to destination, while roboports can have big gaps,

roboports are helped by other ports that get put near the destination or a bit off the side to the main thoroughfare

Also it takes a long time before roboport network reaches saturation steadystate after the initial burst and it is not always obvious that the limitation is charging rather than number of bots like most players assume when bot throughput drops.We have a clear readout of how many bots are available (aka stored in roboports) but in saturated state all bots will be waiting in queue for a charging spot and the solution is to add more roboports instead of adding robots.

It also takes a very long time for the backup to clear once you do have enough charging spots

[bobucles]

The problem is that belts not only suck because of their own throughput limitations. They also suck because of inserter limitations due to inventory-to-belt transfer. That is something most people seem to ignore and forget completely.
Therefore =>
Belt Stack Size = Inserter Stack Size

No, that still doesn't follow. There's nothing wrong with a belt stack size not being equal to inserter size. The only reason they should even share a common divisor is because it looks pretty. If a stack inserter dunks 12 items, it looks nice for it to drop 2x6 complete stacks or 3 stacks of 4 or 4 stacks of 3. It looks silly to dunk a stack of 10 and then a stack of 2. That's the only reason behind it.

But inserters struggle to fill belts!

Yeah, well. Just like. Big deal. Regular inserters struggle to fill belts. We still use them. If stack inserters do 3 stacks of 4, that means you need the same number of stack inserters to stack-saturate a belt as it takes fast inserters to flat-saturate a belt. Using 5-6 inserters per side to saturate a belt is not a game breaker. Granted it would be nice if there was a higher throughput way to somehow load a belt (hinthint), but that is by no means an absolute requirement. It would simply be a convenient way to deal with full stack-saturated belts without pulling out a dozen stack inserters every time.

The reason why Bot Cargo Size is also important because of UPS concerns many players raise all the time. If you want belt stacks to have about the same performance as bots then 1 stack of the belt must correspond to 1 bot on the map or otherwise people will continue to use whatever requires less moving items to be calculated. So:

Bot Cargo Size = Belt Stack Size

False equivalence. Bot CPU and belt CPU are not equal. This is especially true with the new belt update, which allows large sections of belts to be processed as a single entity. Every bot increments every tick and while this is a fast process there is no real testing to compare them against belts. Don't make a demand for reasons that haven't even been tested.

The problem starts when you try to implement that stuff with belts and find out that most of the belt related setups are for the garbage can because they just don't work at all because of how belts are too slow, because of how inserters are too slow, because of how you can't fit all the belts and inserters and electric poles between the beacons due to space restriction and whatnot... and all of that requiring massive amounts of hacks and workarounds to overcome, if even possible at all.

Belt setups don't fail because of space restrictions. It's easy to fit 2 belts into a sandwich of beacons/assemblers and 3 or even 4 belts is possible with some clever spaghetti. They fail because those belts reach saturation almost immediately. By the time the beacon line just gets warmed up the belts are already at capacity and it's time to move to the next row. That's not a fault of beacons, that's a fault of belts failing to keep up. If you were to decompress that build into a much larger batch of slower prod3 assemblers in longer lines, those same belts will STILL fail to keep up because they didn't have the throughput to begin with.

Belt inserters only struggle to keep pace with a handful of low tech recipes operating at FTL speed. Belt stacking ALSO addresses those problems because inserters can work the belts more quickly. A stack inserter no longer needs to wait for 12 items to pass by before it can dunk the inserter. It can instead grab 3 stacks of 4 items and thus transfer items much more quickly. But since this problem exists for only a handful of ultra fast recipes, there is a simpler solution to tweak those recipes so the problem doesn't happen in the first place.

Beacon builds do benefit bots more than belts because long linear belt lines don't incur any extra cost or penalties. Extra distance is extremely punishing to bots for obvious reasons and thus roboports simply like tight builds. A beacon base can be surrounded by layers of roboports to give the logistic throughput it needs but it's not always obvious how belts surrounding a beacon build can help the pieces inside.

A base without prod3 is a logistic nightmare. There's absolutely no chance a player can achieve similar rates of SPM without using productivity modules. The amount of extra mines, furnaces and low tech assemblers needed to get the same high tech output is simply too much, and neither belts nor bots have what it takes to keep up.

[Aeternus]

The reason why Bot Cargo Size is also important because of UPS concerns many players raise all the time. If you want belt stacks to have about the same performance as bots then 1 stack of the belt must correspond to 1 bot on the map or otherwise people will continue to use whatever requires less moving items to be calculated.

And that ratio would still favor bots. Because you have extra Inserters picking from the belt and dropping onto the belt, and travel time on the belt is longer then bots (bots are faster then even blue belts). That is why I advised a small 1x2 "loader" like structure that ejects not just a stack of max 13, but item stack size, with a chest/inventory on one side and a belt in/out on the other. Call it a pallet, crate or whatever - point is to compress a stack of something onto a belt. Which is a common thing to do in industry actually...
See: https://en.wikipedia.org/wiki/Palletizer

This will:
- Reduce the amount of items moving on the map by moving an entire stack in a single entity.
- Omit one inserter at the loading/unloading end.
- Allow for trunklines that exceed the maximum capabilities of bots, even if you line the entire path with roboports.
- Add slightly more complexity since you'll have to de-palletize and load the individual items into structures and/or onto belts again. An assembler-sized structure is too big for this purpose, but a Pump-sized structure in my opinion would be perfect.

Also beaconized setups allowed people to push the limits of the game to where it is now in the first place where people all of a sudden require 200k Iron Ore/Minute and whatnot with like 80 belts in parallel just for one item type and crazy stuff like it. Without ridiculous megabases like those people wouldn't even be complaining about the gap between Belts and Bots.

Even before megabases, bots in their current form just... destroy the logistics complexity. Output? To yellow chest. Input? Blue chest. Done! With lower volumes pre-megabase, going full bot simplifies things. Which can be good, if you're still learning the intricacies of the game, and are figuring out what's what. Hells... when I first tried a Bobs mod game and tried expanding and setting up a chemical industry... I was blown away by the complexity of the production chains. It. Was. Insane. And without bots I'd have never figured everything out. Then you tear your initial stuff down (or leave it as a legacy to baby's first production chain) and set up bigger chains with mainly belts and local production.

My main gripe with bots remains the excessive volume they can move, insane across short distances, significant across large distances. Fix that, and bots are balanced.

[MeduSalem]

From my point of view... implement stack belts or item crates or 10 times as fast belts or even all at once.

On their own it won't be enough to deal with belt problems and if at all cause another bunch of problems elsewhere (like I wrote inventory-to-belt transfer speed of Inserters are also a main source of the limitations at hand even with Stack Inserters) or in the extreme case only reverse the situation that bots become worse off (like would be the case with crates/boxes).


Somehow I am also slowly losing my interest further discussing on this topic because of circling around the same crappy problems for 2 pages now, which obviously have no agreeable solution anyway because we cannot even agree on all the possible problems that proposed solutions might have and what is even worse for the entire stupid artificially made up belt vs bots dilemma... we cannot even agree on what is causing some people to abandon belts in late game in the first place. I say artificially made up because in the course of the normal game belt vs bots aren't even a problem anyway, as it only becomes one once targeting Rockets/min or Science/min becomes the main goal and people start to aim for throughput/UPS/space efficient setups to push the limits of what their computers can handle. Before that nobody gives a shit at all about any balancing issues, just like is the case with all other major balancing issues the game is suffering from and which have been pointed out throughout the last 2-3 years.