Factorio Forums

Bots are amazing and give you so much power, but they take puzzles away and they are too simple to use.

I think the single most broken thing is how you can get infinite throughput to/from a single chest. My proposal:

- Rate limit bots visiting a chest at 1 visit per second, scaling with bot speed.

This would make bots infeasible for high-throughput tasks, unless you parallelize using multiple chests or something clever. And they'd still be good at all the low-throughput stuff like your mall.

And a bonus:

- Add a congestion mechanism of some sort. Maybe just the bots slowing down based on how many other bots are on top of them. That wouldn't be very CPU intensive. Ideally you'd want them to behave more organically and push each other away, but that would change their pathing drastically.


Another idea is inspired by this fantastic mod: https://mods.factorio.com/mod/Construction_Drones

What if our logistic/construction bots were GROUND based? What if they were kinda big and clunky, and you had to make kind of a road network for them so they could get everywhere? What if there could be congestion here? Maybe they can only drive on paved surfaces?


The challenges opened up by these kinds of ideas are really fun!

This has been discussed several years. I agree with you that the bot system is overwhelmingly overpowered no brainer which destroys the most interesting part of the game, but unfortunately huge megabases are very famous and whole game development has been made prioritizing possibility of huge bot bases (many interesting ideas have been rejected because they would decrease production of extreme megabases). It will never change.

Fortunately there is always possibility is to set personal restrictions of modify things with mods. For example I never use bots in main material flows except satellite transport. I mean material flow from raw resources to research. But I use bots for mall and distribute ammo from defense stations to gun turrets or solid fuel to locomotives at stations. In my opinion bots should be throughput limited method for such complex side flows but not for heavy throughput main flow. Also it would look very beautiful if bots followed flock dynamics instead of noisy mess of straight moving non material bots. Flock dynamics is not very demanding computationally, but of course it could not handle 100000 bots needed for very large base.

The penalty for using excessive amounts is the ever increasing number of roboports required.

Sure, you can have an infinite amount of bot traffic in a given area. But each of those bots uses some amount of energy for every tile of distance traveled. Bot speed upgrades doesn't decrease that amount of energy used either. So as the number of bots grows, the amount of roboports needed to recharge all those bots will grow as well. The more roboports there are, the more space they take and the further robots needs to travel which just compounds the problem.

And then there's the UPS costs. Robot megabases will just grind your PC to a crawl.

Yoyobuae wrote: ↑Wed Sep 02, 2020 6:49 am The penalty for using excessive amounts is the ever increasing number of roboports required.

At megabase level such costs are theoretical and negligible. In practice you just blueprint couple of nuclear plants or square kilometer of solar panels and problem is solved in short time. In that phase only limit is computer's speed and players ability to play with low fps. All game resources are free. Such base produce and build infrastructure needed to overload computer in no time.

Also in normal endgame it is easy and fast to build 8 reactor nuclear plant or enough solar panels and accumulators when you see high load on electric production. Power consumption is not real limit so that player should think is it possible to expand or wait until needed resources are gathered ans built. Just put blueprint down and let bots solve the issue.

And then there's the UPS costs. Robot megabases will just grind your PC to a crawl.

Of course there are always limits, but robot's throughput to UPS ratio is overwhelming compared to belts. Belt megabases are completely different class than bot bases and I do not even know how much higher throughputs optimized bot bases achieve in last versions of the game. Order of magnitude? Even in worst case several times higher. Decision to use belts in end game is always personal restriction, bots are clearly better in all technical aspects.

joakimar wrote: ↑Tue Sep 01, 2020 10:09 pm Another idea is inspired by this fantastic mod: https://mods.factorio.com/mod/Construction_Drones

What if our logistic/construction bots were GROUND based? What if they were kinda big and clunky, and you had to make kind of a road network for them so they could get everywhere? What if there could be congestion here? Maybe they can only drive on paved surfaces?


The challenges opened up by these kinds of ideas are really fun!

How are construction bots overpowered? Compared to what, building by hand?

If bots can visit chests only 1 per second I simply build more chests. How is that more fun?

- Add a congestion mechanism of some sort. Maybe just the bots slowing down based on how many other bots are on top of them. That wouldn't be very CPU intensive.

Yes, it would be. Very much so. The game would have to check for every single flying bot, if there are other bots nearby, every single game tick and adjust the speed.

It is not a challenge if you break or limit other people's games, it is a challenge if you set a challenge for yourself. You can build a base without logi bots. People have done it before and they had fun. Other people use bots, they have fun, too.

DerGraue wrote: ↑Wed Sep 02, 2020 2:08 pm If bots can visit chests only 1 per second I simply build more chests. How is that more fun?

I think the point is that it nerfs bots by making them requiring more space. You don't have unlimited space (close to factory), so it would rate limit bots for factories and make belts more competetive. You can build more chests. But if you make fields of more chests then it's pointless because you don't have assemblers there. It would make bots unable to keep up with beaconed assemblers, because you can't build more chests around assemblers.

Why this is suggested for construction bots though is beyond my understanding. I guess OP wants belts to be better at contructing factories as well?

Yoyobuae wrote: ↑Wed Sep 02, 2020 6:49 am And then there's the UPS costs. Robot megabases will just grind your PC to a crawl.

That is only true when using bots wrong, for long distance transport.
For short to mid range bots have the best ups performance.

Optera wrote: ↑Wed Sep 02, 2020 2:30 pm That is only true when using bots wrong, for long distance transport.
For short to mid range bots have the best ups performance.

Exactly. Each logistic option has their uses.

joakimar wrote: ↑Tue Sep 01, 2020 10:09 pmMy proposal:

- Rate limit bots visiting a chest at 1 visit per second, scaling with bot speed.

I have some questions:
1) How exactly are you adding this limit? Is the proposed to add a timer to every chest? A flag that some process needs to cycle through? When are bots supposed to check this timer?
2) Does this apply to all logistical chests?
3) What is supposed to happen when a chest has a request for more than the number of items a bot can carry? Does the next bot supposed to schedule item pickup based on these delays?
4) How is this supposed to scale with bot speed? If you are reducing the wait time; at what percentage at each level? Since bot speed bonus is one of the infinite techs, aren't we just adding an unnecessary performance hit by adding a metric that can eventually no longer have any significant effect?
5) on storage chests that have a filter item set, what are bots with the item supposed to do when it can't deliver the item to the chest?

Normally I dislike the "make it optional" argument for things..... but wouldn't this be a prime candidate for a map setting at creation, like the biter values?

Knowing the insanity this might cause the Devs..... Bot Collision? Holding patterns (on open tiles) around chests would seriously kill their throughput to a max of 8 per.... crap..... I forgot about the logic for making an exit path. So it'd be a queue length 7 deep, plus one space so they can exit. The idea gets worse the more I think about it.....

starlinvf wrote: ↑Wed Sep 02, 2020 6:37 pm Normally I dislike the "make it optional" argument for things..... but wouldn't this be a prime candidate for a map setting at creation, like the biter values?

But @OP wants to ruin it for everyone not just themselfs. It's amazing how these "please nerf all playstyles except my own" threads never stop.

Optera wrote: ↑Wed Sep 02, 2020 2:30 pm

Yoyobuae wrote: ↑Wed Sep 02, 2020 6:49 am And then there's the UPS costs. Robot megabases will just grind your PC to a crawl.

That is only true when using bots wrong, for long distance transport.
For short to mid range bots have the best ups performance.

After some actual testing I found bots are just terrible for UPS performance. They are around one order of magnitude slower for UPS compared to belts when transporting the same throughput of items. And this is for short distance transportation (around one chunk). And the further the bots need to travel the worse they become for UPS. Doubling the travel distance requires roughly doubling the number of bots in order to maintain the same throughput which then doubles the UPS impact.

On the other hand belts don't increase all that much in UPS impact the further they need to transport items. Long belts are just excellent for UPS.

My tests where done with bots counts ranging from 104k (UPS=75) up to 345k (UPS=25) logistic bots with all of them working at the same time. The only thing on the map for each test were the bots, roboports, logistic chests. For much lower amounts of logistic bots the effects on UPS would not be as bad, of course.

eradicator wrote: ↑Wed Sep 02, 2020 7:02 pm ...It's amazing how these "please nerf all playstyles except my own" threads never stop.

I guess, that's because new players arrive after launch

jodokus31 wrote: ↑Wed Sep 02, 2020 10:26 pm

eradicator wrote: ↑Wed Sep 02, 2020 7:02 pm ...It's amazing how these "please nerf all playstyles except my own" threads never stop.

I guess, that's because new players arrive after launch

I've started referring to it as "litigating game design". Because they remind me of what many frivolous law suits sound like,when read out loud.

Actually what we need is to not limit the number of items on a belt.

5thHorseman wrote: ↑Thu Sep 03, 2020 1:33 am Actually what we need is to not limit the number of items on a belt.

Would be kind of funny to see items spill off the belt at the end, or if it stalls they'll randomly get pushed off the sides. Maybe a future suggestion for a "Murphy Mode".

starlinvf wrote: ↑Fri Sep 04, 2020 12:23 pm Would be kind of funny to see items spill off the belt at the end

In much earlier Factorio versions the items did fall off the end of belts and ended on the next ground tile, but they didn't spill any further. In old screenshots you'd see belts end up one tile sooner and the final inserter in the line picking up items from the ground instead of belt.

5thHorseman wrote: ↑Thu Sep 03, 2020 1:33 am Actually what we need is to not limit the number of items on a belt.

I think it'd be cool if we could treat items like fluids; pipe items directly into assemblers and move them around by the 100s through pipes.

netmand wrote: ↑Fri Sep 04, 2020 3:14 pm

5thHorseman wrote: ↑Thu Sep 03, 2020 1:33 am Actually what we need is to not limit the number of items on a belt.

I think it'd be cool if we could treat items like fluids; pipe items directly into assemblers and move them around by the 100s through pipes.

https://mods.factorio.com/mod/LiquifyIntermediates
https://mods.factorio.com/mod/LiquifyRawMaterials
https://mods.factorio.com/mod/LiquifyScienceandLab

Though those don't make assemblers take liquid input. That would b a bit of a pain to implement with more than two inputs.