UPS-Friendly Bots vs. Belts fix

[NathanDsilva]

TL;DR - Make bots single use (returning frames), Solar panels occasionally break.

I've been playing Factorio for some time now, but one thing that continuously annoys me are the logistics bots. We all know what's wrong with them (If you don't, there are countless articles and several Friday Facts about it), but the general consensus is "If you don't like it don't play with them". I don't like this ideology, and I don't think that just gating bots behind end-game science is a solution. Many have suggested fixes, but some of these either require too many changes to the game or cost too drastic of a UPS hit to implement.

My suggestion is to remove bot recharging (for both logistic and construction bots) and change how roboports work. A bot will have a fixed distance it can fly (represented by a damage value like science packs or ammunition) and will return to the nearest roboport once it runs out of stamina. Once it gets there, it will return a flying robot frame if it has used up its charge, or wait for another delivery request if it hasn't.

[Note that this segment is optional, but I think it could help balance the bots even more] Roboports, instead of consuming power per robot charged, can have a production bar that makes "Deployments" - a number displayed on the roboport UI that acts as a counter for how many bots it can deploy at a time. This production bar will take 1(ish) seconds to fill, requires power, and can be affected by modules and beacons. The roboport will hold 10(ish) charges, and uses 1 charge every time a bot is deployed. Thus, you can still get that thrill of a swarm of bots instantly emerging to get a stack of iron, but roboports will not be able to sustain more than 1 bot per second in the long run. This provides an incentive to build many roboports in high-throughput areas, as bot recharging will no longer exist.

Secondly, I propose that solar panels occasionally (maybe influenced by global pollution?) take some amount of damage and stop functioning when they fall below a certain threshold. This, combined with the previous suggestion, will singlehandedly fix many of the issues with logistic bots and solar power. Here's why:

Challenges with setting up bots before:
1. Want bots -> Craft roboport
2. Need power -> More solar

Challenges with setting up bots after:
1. Want bots -> Craft roboport
2. Bots run out -> Assembling Machine next to roboport
3. Need advanced circuits -> Scale production etc. etc.
3.5 If used bots to solve above issue, now bots cannot manage enough circuit production to sustain themselves -> Downward spiral of doom and panic
4. Need power -> More solar
5. Solar keeps breaking -> Construction bots and automated repair packs
6. Construction bots run out -> Needs circuits -> Somehow need to get circuits and repair packs into solar field
7. Construction and Logistic bots on same network, but both return generic robot frames -> Circuit network shenanigans to manage the ratio of logistic to construction bots
8. Bot swarm now growing, 1 assembler per roboport no longer enough -> Multiple assemblers per roboport or belted supply chains
9. Single roboport cannot deploy bots quickly enough -> More roboports / Speed modules -> Back to step 2

As you can see, these two simple changes can result in some pretty interesting dynamics that will change how the late-game is played. This easy modification will help fix the issue that 90% of megabases use bot-based everything and solar grids that span half the map, as well as making the mid-game less of a grind to the previously overpowered bots and more about actually trying to solve the logistic problems associated with them. This is also a very UPS-safe modification, as bot pathing and solar panel tallies will still work after the fix, so it shouldn't cause any performance issues.

Let me know what you think!

[ssilk]

First in short how I understood this:
Instead of refueling the robots, they fly around as long as they have “power”, then they will target for the next roboport, and get deconstructed, and will be replaced with new robot.

What I didn’t understand: when the robot will transport with an item on board and need to target to a roboport, what should he do? Will he finish the current transport and then target a roboport?

Besides that, I think the developers will not replace the current behavior, nor this will be possible to mod.