Factorio Forums

TL;DR

Balance bots by reducing the throughput of chest->bot by only allowing 1-2 bots to use a chest in parallel, and make each chest interaction take ~0.5 second fixed.
Numbers can be tweaked until balance is achieved.

Why ?

Latest FFF has shown that bots have superior throughput over belts by a factor of at least 5. But bots are not supposed to beat belts in throughput, they should only trivialise low throughput setups. This ease of use should come at a price.

What ?

If you allow only a small fixed amount of bots to use a chest at the same time, while using chests also takes a fixed time, the throughput of chest->bot can be reduced to be more in line to that of chest->inserter->belt. Building massive bot factories would require spreading items out over multiple chests instead of just using more bots. High throughput would literally require
- assembler -> inserter(s) -> belt -> many provider chests
- many requester chests -> belt -> assembler
This would put the logistical challenge back into bot factories while not affecting the bot convenience for low throughput usage.

I fully agree that the throughput of bots should be limited in some way. However, I'm afraid that your suggestion is not an ideal solution to the problem, because the throughput limit you impose can somewhat easily be circumvented by placing additional chests.

My solution to the problem of overpowered bots is to introduce an additional cost for using bots, in the form of maintenance, which costs actual resources. That way, it would be too expensive to use bots for large amounts of items such as iron plates, but only for small amounts of items such as science packs. Here is a link to my dedicated suggestion thread:

viewtopic.php?f=6&t=56505 nerf bots with additional maintenance costs

However, my solution has its own disadvantages, as pointed out in my thread.

Suggestion: Only one bot can interact with a chest at the time, and it takes a small amount of time for the bot to pick up / drop of item(s).

I think that the balance problem with bots vs belts come down to the "unlimited" throughput of bots.
One way to balance this would be to limit bot interaction with chests.

It could work like bot changing do, bots would hang around waiting for their turn before picking up / dropping of items.

Preferably throughput should be lower than what an inserter can put on a belt.

I agree with this in principle, but make it so that as many bots can interact with the chest as inserters.
Also make it so the bots add/remove stuff from the chests at the same speed as a top tier inserter, maybe marginally less, because bots can fly diagonally to their destination, belts cannot.
Also, when laying out construction, it takes 'time' to drop the item rather than suddenly 'appearing'.
These changes would certainly make the 'robot swarm' less effective, not having whole swathes of blueprint construction suddenly 'appear' instantaneously, but more 'organically'.

I also think it's the source of the "OP" problem with bots. All their action are instant!

It take me like 5 sec to mine a freaking rock while the rock remove it instantly!

To bring that idea further, I suggested in the FFF that all logistic chest be removed from the game and be replaced by the robotport itself :

- All logistic chest are removed
- The Robotport now have storage (similar to a logistic chest)
- Every Slot can be either a "Buffer", a "Provider" or a "Requester" item.
- Only a limited number of bot can be loaded at the same time (4 for instance) and it take a few seconds to Load/unload it
- To hinder the scalability of the bot network the "loading/unloading" could require some additional power

What you think?

The OP's suggestion already has its own suggestion thread, which was opened two days beforehand:

viewtopic.php?f=6&t=56556 Balance bots by limiting throughput per chest

@Moderators: I believe it would be appropriate to merge both threads.

EDIT: Now that the threads have been merged, I would like to point out that my post above was referring to the post by forum user "Nefrums", who was the OP (original poster) in the duplicate thread before it got merged. It was not referring to the post by forum user "DrChack", which is now the first post of the thread.

Agreed.
[Koub] Merged into existing same suggestion