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

[bobucles]

Same as with any length of it.

Belt length is not free. More belts cost resources and more belts take up more land space. This land space could instead have been used for trains or roboports.

Logistic power is an excellent way to compare the opportunity cost of belts vs. bots in terms of land space. Packing a lot of logistic power into a small land space is the secret to making beacon builds work because beacon builds give a limited amount of land space to supply your items. It isn't very good for comparing resource costs because yellow belts and trains are the cheapest way to move items by far. However just because a yellow belt is cheap doesn't mean it's the best way to move items.

[Aeternus]

Underground belts tend to consume a minor amount of land however. And for excessive optimization you'd need to triple-braid the belts (underground blue, yellow, red braiding). Should bring the total transport capacity to 80/s/row. But that's hell on the exit node, as you'll have to merge red and yellow for the second blue at the end. But that doesn't solve the problem that belts simply will not scale, whereas bots can scale if needed, especially over short distances.

Problem remains: Belts -suck- for high speed bulk transport (at unit speeds over 40 units/s), which is their primary function. THAT is why bots feel overpowered, and THAT is the issue that needs to be fixed. Bots have the infinite speed research which allows them to scale, basically, into infinity. Belts do not. Which brings me to:

Another suggestion, this one may be a bit crazy: Add a research option that allows for belt compression - reducing the distance between units on a belt so that the individual belt sections can hold more units. If at current belt sections hold 8 units max, and you can squash that to 12, you'll now have the same speed belt capable of moving 60 units per second instead of 40. Added advantage is that it'll take less time for a stack inserter or inserter with multiple pickup to fill it's arm, thus making the inserter-delay-while-grabbing-from-belt disadvantage of belts reduced as well. Disadvantage is UPS - you'll have more units on the belt, so more entities for the game to track.

It's similar to stacking I suppose. Squashing items onto a belt is already being done, so the item spacing on the belt apparantly can be overridden in some cases. Technically I don't see why this couldn't be done with only minor alterations.

[dood]

Now at 50 tiles, you cut the distance of that 100 tile bus in half and put the belts you don't use anymore next to the part still being used and look at the throughput at 50 tiles.
now you have a 8 belt bus

320 items per second

For fucks sake, belts don't magically rebuild themselves if you make use of a fraction of their length, bots do exactly that and because of that dynamic application of their throughput it is as silly to compare them in a "x tiles of bot" to "x tiles of belt" kind of way as it is to slap a fixed "throughput" number onto them.
That's all I was saying.

[dragontamer5788]

- If a bot carries an item from point A to point B, it must return to point A empty handed to do the trip again. This type of bot is only working half the time, thus it's wasting half of its potential logistic power. The bot pathing only does useful work some percentage of their time.

You can do better than 50% btw with a simple tip: move bots back to "source" roboports, and away from "destination" roboports.

For example, a steel production base may have an iron ore train station (lets call this north) -> production area -> steel plate ouput train station (lets call this south). 5 bots travel from north to south, but only 1 bot travels from south to north. Lets fix that: Remove bots from the southern roboport, and then insert them (by inserter) into the northern roboport. Bam: your bots are now working 100% of the time, using no energy on their return trip.

You can move 4-robots at a time using logistic chests, or you can move 40-robots per second using a blue belt. Yes, logistic bots can carry 4-logistic bots as cargo.

[ratchetfreak]

Now at 50 tiles, you cut the distance of that 100 tile bus in half and put the belts you don't use anymore next to the part still being used and look at the throughput at 50 tiles.
now you have a 8 belt bus

320 items per second

For fucks sake, belts don't magically rebuild themselves if you make use of a fraction of their length, bots do exactly that and because of that dynamic application of their throughput it is as silly to compare them in a "x tiles of bot" to "x tiles of belt" kind of way as it is to slap a fixed "throughput" number onto them.
That's all I was saying.

but as a player you are not going to leave hundreds or thousands of blue belt lying on the ground being useless, instead you are going to reuse them, very likely to improve throughput by adding extra lanes to existing busses.

[bobucles]

Underground belts tend to consume a minor amount of land however

This is indeed true. Underground belts make incredibly efficient use of land space to move lots of stuff in a tiny footprint. Of course you can't just throw more underground belts in the empty space! They'll end up linking together. Belt weaving will work but it is a pretty strange setup and I can understand if players refuse to use it.

You can (in theory) increase your logistic throughput by using a combination of long blue undergrounds with roboports tucked between them. Blue undergrounds have 8 tiles of empty space between them, which means 2 roboports can be tucked in there. The underground belts can move 40 items across 10 tiles while only consuming 2 tiles of land space. Those undergrounds max out at an item moving capability of (40 items/sec x 10 distance / 2 space) => 200 logistic power/tile, which is a big step up compared to the super roboport's theoretical item locomotion capability of (1300 power / (4x4 footprint) => 81 logistic power/tile. Not too shabby! I shall call this newfound process "bot weaving".

bot weaved belts.jpg (670.88 KiB) Viewed 8264 times

Even though the belts are very efficient in terms of land space, they aren't the dominant force of the build. The 16 lanes of undergrounds(ignoring the flat belts) total around (200/tile * 16 lanes * 6 tiles) => 19K logistic throughput, while the 4 lanes of roboports(ignoring the sides) are cranking (1300/robport* 4 wide * 6long)=> 31K logistic power. A real world test will likely prove that the roboports do more of work here and it may slant even further in favor with roboports over more distance. Even with the increased throughput I don't think it has any practical real world value. If you need to move a lot of stuff such a long distance, why not move your trains a bit closer! Also it's very difficult to both saturate a belt AND keep bots busy off of the same train station. You'd need a very strange and creative setup to really make use of it.

Edit: A few more maths theorize that, if the undergrounds were not used and instead replaced with a solid brick of roboports (4 x 8) then the build would move 17% less items over the horizontal distance (Try the math yourself!). Of course that's some garbage frictionless vacuum math. Belts really do lose efficiency from all the balancers/inserters/flat belts/etc. that you need to saturate them in the first place. Roboports work at full potential much more easily.

[Aeternus]

Roboports have their own issues however. Bot distribution across the network tends to be an issue if a large wad of cargo is suddenly available and 2000+ bots pile up at the same dozen or so roboports. Expect delays...

Belts are at least consistent in their throughput and have an easier stop/start. 's just that there's no endgame way to scale up the amount of cargo transported by them.

[dragontamer5788]

Bot distribution across the network tends to be an issue if a large wad of cargo is suddenly available and 2000+ bots pile up at the same dozen or so roboports.

Build more roboports in those areas to provide more charging space. Alternatively, use filter-inserters to remove logistic bots from "inactive" roboports and insert them into "active" roboports.

These bot-problems can be fixed rather simply in my experience.

[McDuff]

TLDR;

The real problem with bots isn't that they are too powerful, it's that they aren't as fun as they should be.

I think this is a good take on it. I had a similar conception of the problem, and landed on a couple of very similar solutions, in this post in the original FFF thread.

Idea #1: Roboport extensions

<snip>

• Antennas would increase the coverage area.
• Charging pads would increase the number of robots that can charge at the roboport.
• Bot Chests would increase the number of bots of a type can can be stored at a roboport.

Idea #2: Isolated Roboports

Make bots only work in the area of the roboport that they are stationed at, as if each roboport was it's own network. <snip>

Isolated roboports is the same idea I had. I didn't cover extensions but I can absolutely see how that would add more flexibility to such a system. (I haven't used Bob's Mods so I don't know how some of those things work but I like the concepts).

Idea #3: Transporter Bots

Add a new class of bots that would transport items between roboports. This would allow optimizing speed vs quantity, as well as optimizing how items get moved over longer distances.
There would be 2 types of transporter bots:

• Transport bots: Small and very fast bots, but with a small stack size, designed for moving small quantities of items around the base as quickly as possible. (Great for supplying a field of assemblers.)
• Cargo bots: Large and very slow bots, but with a very large capacity of several stacks, designed for moving large quantities of a single item moderate distances very efficiently. (Great for supplying robotic smelting setups, or for chests that fill belts for production blocks.)

Interesting, but an issue with this is that it seems to seek to replicate belts and trains in bot form, which sort of works around the limitations you just put in place. I think bots as a design aren't for, and shouldn't try to be for, shifting large quantities of items over large distances. They're for shuttling things flexibly over a smaller area.

Idea #4: Shipping Lanes

<snip>

Again, this seems like the kind of thing you shouldn't want to be using bots for? This is a train solution, surely?

Idea #5: Robot Docking Railcar

Ideally, bots shouldn't take the place of trains for long distance moving, they should enhance a rail network. A bot platform would contain a beacon, and could sit next to the tracks and request empty cargo bots or cargo bots carrying certain supplies, then place the bots loaded with their cargo on a docking railcar (Similar to an Intermodal railcar.) that is over the platform. This would allow a lot of problem solving to figure out the best way to get the items you need on the right train, without it being an exercise in optimizing belt and inserter configurations, since there are a lot of other places to do that...

This is an interesting idea. I am not sure how it would work with the isolated roboport idea, though? I guess this is maybe where you need the "transporter" bots, those being bots that can only operate between but not within logistic subnetworks? Otherwise the bot addressing just gets too confusing.

So, overall, I like it! I think isolating roboports is a really interesting idea (obviously, since I also had it) and it's a nicely orthagonal approach to a solution which is about making robots fun and an interesting puzzle to solve rather than just spam that takes the job of organising your factory away.

[Sir3n]

Like some others, i think bots should be a form of flexible transport you use only if you cannot figure out an elegant way of doing it with belts and only if you do not need high throughput. I think the infinite scaling of bots should be heavily nerfed or removed completely.

An idea I have is to completely leave roboports exclusively for housing construction robots and rework logistic bots entirely.
Construction robots can remain the same as far as i'm concerned.

1) A logistic bot will always have 1 "home" requester chest. 1 requester chest can only have 1 logistic bot attached to it.
No other logistic bot can interact with that specific requester chest.
Requester chests can allow only 1 logistic bot to dock inside it.
The requester chest can draw power directly from the logistic network / nearby roboport and feed it to the logistic bot wirelessly.
That bot can then find whatever is requested by the requester chest from provider chests as per usual.

2) Logistic bots can carry (1 + logistic cargo size research level * stack size / 100)
cargo research 0 ==> 1 + 0% stack size ==> 1 coal or 1 iron plate cargo size
cargo research 10 ==> 1 + 10% stack size ==> 6 coal or 11 iron plate cargo size
cargo research 100 ==> 1 + 100% stack size ==> 51 coal or 101 iron plate cargo size

Worker robot speed applies as usual. No changes here.

3) The logistic bot recipe can also be adjusted to make it more expensive. Maybe a logistic bot mk 2 that requires fusion reactors or something and does not consume power which would have a default cargo size of 5 instead of 1.

4) The only chests can can act as "home" chests for logistic bots are active providers and requesters.
I'm not sure about buffer chests since i haven't used them ever.
Bots attached to an active provider can't interact with requester chests and bots attached to requesters can't interact with active providers either. They can only interact indirectly through storage chests (maybe buffer chests? i'm not sure how those work).

So, Active provider <--- Bot ---> Storage chest <--- Bot ---> Requester
This isn't allowed: Active provider <-- Bot --> Requester

-----

The values can obviously can adjusted but the core of the idea is to heavily nerf the infinite scaling of robot transfer speeds, at least until you get to like research level 100 and such. Limiting requester chests to interacting with only 1 robot would also allow belts to be competitive.

blue belt => 40 items /s,

At lvl 39 research, 3 seconds to travel from source to destination, carry iron plate (stack size 100)
cargo size = 1 + 39*100/100 = 40 items
bot speed = 40/3 = 13.3 item/s === yellow belt speed

In those situations, red belt would often end up simpler to build with higher throughput. Even with increased flexibility of being able to surround an assembling maching completely with requesters and active providers, you wouldn't beat belt speeds until you get a decent amount of research into cargo size.

So for a lot of the game, you'd mostly just use bots as a way to get tricky items over from some weird place into your spaghetti system. As long as you don't need a lot of throughput, like in a shopping mall district type of thing, bots would work just fine if you figure out you can't make the build work with belts.

Even later on in the game, at research level 500 or so, belt would still have its uses for mass carrying items for mid range distances. You can stack 32 belts side by side but you are limited with this type of logistic bot.
e.g.
If you are moving iron plates, and you surround an assembling maching with 6 requester chests for iron input
cargo size = 501
6 logistic bot => 501 * 6 = 3006 items per trip
10 seconds for round trip = 300.6 item/s

300.6 items/sec ==> 7.515 blue belts

Over longer distances the item transfer speed of bots would drop quite fast while belts maintain a constant throughput no matter how long the bus lane is.

The clear advantage of belts would be constant throughput no matter the situation.
Bots would become the clear winner in short distance item movement / compact builds like beaconed setups as long as you have enough research done.

So you can't just spam bots brainlessly even in end game. For the mid-late transition, there is no way you would have those item speeds with bots. Research level 500 takes quite a long time to get to.

---

As a side note, you can probably bring requesters feeding into other requesters through inserters but at least that would lead to more interesting looking bot builds instead of the plain old same boring build. And it wouldn't guarantee that a belt build wouldn't be straight up better either, it would depend on your research level and the specific items / build in question. Would involve more decision making and thought process since the throughput of bots would change based on your current tech level, distance the items need to be moved and the stack size of the item in question.
Personally, i think requesters feeding other requesters through inserters would look hilarious.

I believe that is what is missing with bot builds. With belts, you always have to adjust your build based on what items are being fed into your machines so each time you create a new build, you have to think a bit. Bots are just, stamp more of the same basic build down and it's guaranteed to work. Not much of a difference between having to feed in 3 types of items into the assembling machine vs 4 types. Having bot efficiency change based on various factors would give it a step in the right direction imo.

If different materials have different distances to the requesting machine, the basic ratio of the build will change too unless you always guarantee equal distance from the machine to source chests, which in itself requires planning.
If iron is 2x further away from the machine than copper,
the round trip for iron would end up 2x longer which means you need to multiply iron by 2 in the standard ratio.
It will definitely be a lot harder to achieve perfect ratios.

To help with that, maybe we should get a new tool for measuring distances or time needed for a round trip for logistic bots.

Having a cap on cargo size research at level 200 might not be a bad idea either.
That way you always know what the cap on cargo capacity is and the only variable in building things would be distance travelled. Unlike the current implementation where bots can travel huge distances without any penalty whatsoever, you would have to think more about where you place things.

If there is no cap on bot cargo size research then belts and trains might need a slight buff.
- blue belt speed should go up by a bit or have higher tiers of belts
- train top speeds might need a buff.

Conceptually, this makes a lot of sense to me:
bots == forklifts
belts == trucks carrying containers
trains == cargo ships

[Nel]

After pondering this for a while, I have come to the following conclusions:

• Belts and inserters are a design flaw
• The issue is not only caused by belt throughput, but also by recipes and assembly machine dimensions
• No amount of band aid will fix the situation

How can one of the core mechanics be a design flaw? By actually interfering with the rest of the mechanics. Let us take a step back: What do you do in Factorio? Usually, people answer "building a factory", which is imho is wrong and one of the sources of the frustration with belts. The thing is, the player is not building a factory, but an industrial area. The factories are the assembly machines (and chemical plants), which are basically a black box. So why are belts flawed? Because in reality, they are used to transport items INSIDE a factory, not between them. They carry the intermediate products, which is of no use anywhere else, to or even through the production lines (like a baking station, or through a freezer to cool them). Or they transport parts (gears, handles etc) to the station where they added to the intermediate product. Compared to the factory, the belts are usually tiny in their spatial requirement. But all items are transported to a factory in another way, e.g. by train or lorry.

But in Factorio, all items are required to be put into a 3x3 entitity (no restriction on the place), all at once. Not to a specific input of the machine, at a specific place, just anywhere at all using an inserter. Further, belts have a size of 1, meaning that a max of 3 belts fit to a side of the factory (front loaded), severely limiting possible designs. A single assembly machine can take hundreds of bricks, iron plates and other stuff, and spit out a nuclear reactor. The same machine can also be used to turn one iron plate into one iron pipe. A single requester chest is a much simpler and a lot more flexible option. This goes for research as well, which is probably why the option for them to cascade using inserters was implemented in the first place (belts are huge compared to the facility that they service).

Another problematic design choice is the fact, that everything is a single entity, taking a single place on a belt. A blue belt full of iron plates is nothing, a blue belt full of nuclear reactors represent a huge resource throughput. Basically, compared to end-products, the necessary ores, plates and intermediate products are worthless, yet take the same space (even though in the inventory, they have different stack sizes to accomodate this discrepancy).

So, is there nothing that can be done? Imho, to really solve this, would require a significant overhaul of the game. Production machines would should output automatically, without inserters, allowing for the construction of proper production lines, where belts transport items into specified shoots. To accomocate, machines need to be made larg enough. Instead of beacons, production machines should simply be able to get cranked up, i.e. production speed up 300%, energy requirement up 900%.

The problem could be significantly aleviated by changing the mechanics for raw / intermediate products, i.e. everything that is not a placable / equippable entity. Instead of 1 ore making 1 plate and 3 plates being consumed to produce 1 intermediate, all these products should be percentage based. Meaning, instead of producing 1 ore, a miner would produce 15% of an ore (similar to ammo), but this can be placed on a belt. A smelter would take 3% of the ore, and turn it into 1% of iron coil. Instead of plates, recipes would use a percentage of the coil. So instead of inserters having to shove items into assemblers like crazy, the coils would allow multiple crafts before depleting. Basically, instead of crafting single gears, one would craft a bag of gears. Instead of circuits, a bag of circuits. Later research would unlock more effective / higher throughput recipes. This would be similar to packing / unpacking, or stacking on belts, but without the overhead. Furthermore, bots can be limited by being able to carry a max of 10% (numbers are suggestions, further balancing required). The effect would be, that item transport not only scaled by belt speed, but also by making the raw items on it worth more.

[redis]

Here is an idea: Restrict roboports to be placed disallowing overlap of their range! You would not be able to place 2 or more roboports close to each other because of "interference".

This will nerf bots by reducing number of charging stations and lower throughput. Bots should have the lowest throughput because of their other abilities. They are meant to be used for "expensive" items. This will also cause a player to plan better how/where to place roboports to cover all squares bringing back some logistical challenge to the game with bots. Some research upgrades to roboport entities could be added to allow moderate increases in bots throughput.

I believe this should have been done originally to the game to prevent roboports spamming strategies. To solve the problem with large existing robo megabases you can add a menu option to enable placing roboports withing each other range or allow to create an easy mod.

[foamy]

I'd start with the simplest option of forcing a timing restriction on chest access; bots would have to queue, as they do for charging, to go in or out of any of the logistics chests. See what happens if you do that before trying more extreme manouvers.

[Adamo]

They are meant to be used for "expensive" items.

Everything else you said depends on this statement, but what makes you confident in this statement? As far as I can tell, robots are perfectly well-suited to moving either expensive or cheap items, in two cases: the case where you need extremely high throughput; and the case where you need to traverse obstacles that are not easily traversed using a belt. What does this have to do with item expense, and why it is only for expensive items?

[redis]

They are meant to be used for "expensive" items.

Everything else you said depends on this statement, but what makes you confident in this statement? As far as I can tell, robots are perfectly well-suited to moving either expensive or cheap items, in two cases: the case where you need extremely high throughput; and the case where you need to traverse obstacles that are not easily traversed using a belt. What does this have to do with item expense, and why it is only for expensive items?

Ok. Sure you can use bots to transport ANY items. The idea to reduce allowed roboports density does not imply you can not transfer ore with bots. It would just be less efficient than using other ways. Bots have huge advantage over belts in other areas. The fact is that bots have nearly infinite throughput compared to belts and trains is very OP. What makes me confident in this statement is common sense of balancing different ways of transportation in the game. Everyone is free to play the game the way the want and there are mods for it. I suggest my change can be optionally disabled because of the existing bases.

Adding timing for chest access does not completely solve the issue because it encourages to create more chests around assemblers. This is of course still better than no timing at all. It would be very difficult to balance the timing value. I think roboports number/density should be addressed to limit number of operating bots per area.

[Adamo]

Personally, I don't think it's OP because they use so much power, and the power scales with the distance. Maybe they could use more power -- even in huge setups, my beacons seem to easily use more, although I also like to use belts. I would never get behind a solution that puts a hard limit on my ability to add more robots to a situation (essentially, changing them from bosons to fermions), but I could possibly agree they should be more expensive.

[redis]

Personally, I don't think it's OP because they use so much power, and the power scales with the distance. Maybe they could use more power -- even in huge setups, my beacons seem to easily use more, although I also like to use belts. I would never get behind a solution that puts a hard limit on my ability to add more robots to a situation (essentially, changing them from bosons to fermions), but I could possibly agree they should be more expensive.

Power is unlimited in the game because space is unlimited (solar panels?, but even nuclear is unlimited it just ups heavy). So it does not matter they use more power. You can power any number of bots. Both trains and belts have throughput limits and space constraints. Bots have no constraints and will teleport all your items anywhere, just spam roboports everywhere where you do not have assemblers or beacons. If you think bots are not OP then this thread is not for you. You will still be able to play the game with very strong bots.

[Adamo]

THe real issue here is that solar panels are OP. You should try Adamo Physics! It nerfs solar to an amount roughly based on the maximum theoretical throughput of a solar panel that size. It's still possible to make giant solar fields that work, but much more expensive. If you're powering your massive bot collections on nuclear power, then, what's the problem? You've won. Enjoy. Nuclear power is that awesome, even in real life: what's the issue? It's not infinite. You will run it down faster by using bots. But isn't that the point?

Sorry, but I will strongly reiterate that we should not be considering a hard limit on the density of bots. We need an option in this game that allows you to have infinite density of throughput, and the cost of massive electricity is a fair trade. Solar is OP, though, for sure.

[quyxkh]

THe real issue here is that solar panels are OP. You should try Adamo Physics! It nerfs solar to an amount roughly based on the maximum theoretical throughput of a solar panel that size. It's still possible to make giant solar fields that work, but much more expensive. If you're powering your massive bot collections on nuclear power, then, what's the problem? You've won. Enjoy. Nuclear power is that awesome, even in real life: what's the issue? It's not infinite. You will run it down faster by using bots. But isn't that the point?

Sorry, but I will strongly reiterate that we should not be considering a hard limit on the density of bots. We need an option in this game that allows you to have infinite density of throughput, and the cost of massive electricity is a fair trade. Solar is OP, though, for sure.

I kinda agree with this except it'd wreck early-solar layouts, where you can build pleasing solar outposts, the panels to power most E1'd layouts don't take much more space than the layouts. As "realism" goes, it's pretty absurd, yes, but realism arguments in a game that just for starters on a long, long list lets you carry more firepower in your pockets than the Seventh Fleet are too. I like it that so much of the mechanics in this game are somewhere in the realism ballpark's neighborhood, a lot, and wherever they can introduce the good-parts versions of interesting design puzzles taken from real life, bring it on. But if they were going to nerf solar for realism they'd have to add wind and hydro and geo to make up for it, and (a) the game's not about power generation and (b) none of the interesting parts of any of those are modeled at all, so they'd either be boring or an added cpu drain.

Maybe bots could eat power based on the square of their speed?

Or maybe the people who're so, sooo anti-bot could just ... not use them.

[Adamo]

Maybe bots could eat power based on the square of their speed?

Or maybe the people who're so, sooo anti-bot could just ... not use them.

The square of speed is an interesting idea, I suppose. I think it simply means that energy usage scales up with technology instead of down. Even just scaling it linearly with speed should have this effect, as long as the energy use scales faster than the speed increase. With the squared dependency, it's a bit more complicated, because whether or not it's a true energy increase depends on the amount of power and speed the baseline unit takes and has. But at some level it still becomes an overall loss and scales further with more tech. At very high tech, of course, the squared dependency will scale up faster than the linear dependency.

Regarding the the people who're so anti-bot, I totally agree with you. After all, solar being OP bugs the shit out of me. So I made my mod for my server network. I'm not out there advocating that they get nerfed in the base game. I get that vanilla wants a certain gameplay balance. In my game, for the record, it does become a bit more about power generation, since you can't rely on solar: but I think we find that fun. And there's the point, yeah? We added a few new, cool ways to make power, too.