Friday Facts #225 - Bots versus belts (part 2)

[tmx]

The reason bots are OP is because they have no collision. Make one bot only occupy one tile at a time at most and it would nerf bots significantly without nerfing them for small conevnience only uses, as was intended

[tmx]

Also, add trucks

[Klonan]

Allowing for multiple starting areas and separate research without being enemies/neutral would also be nice. There is no way to play with separate research and still see each other/be able to use each others doors and trains (or even trade without using some clunky mod which might not be very ups-friendly). And no simple way to have multiple starting areas (I'm aware RSO has a feature like that but it's clunky as fuck).

The PvP scenario has the option of playing as friendly teams, you can see their base, open their doors, chests, hop on their trains etc, and the multiple starting areas is handled too

[SHiRKiT]

The main thing about Factorio is that there are two separated games:

- Modded games with lots of items
- Vanilla like game

What many of the older players have tried or started playing is a playthrough with many additional items. Once you go into a game that's heavily modded, things are exponentially different from a vanilla game.

You have as much as three times more intermediate products from vanilla, which makes belts much more confusing to create a proper designed base to be fully operational. Bots are superior as they should be, because that's the goal of having them, to be able to upgrade the factory.

What I think you could upgrade is how belts works a bit. If you could create some way that belts are similar to how Escalators (electrical escalators for humans to walk) work would be great. I don't know if you guys have seen, but there's on in the Toronto airport (https://www.youtube.com/watch?v=RsyC8HRFkrY). Over there they have the two types of escalators. One that's really, really long and really fast, but only have one entrance/exit every a few hundred meters, and the regular ones, which can be used by everyone and has many entrances/exits.

I think that would makes things better, along with the much needed buff to the splitters as you guys just announced.

[factorio_player487]

The best solution is to give players the choice in the initial options whether or not bots can be overpowered. Some people like to play with biters off, some people like to play death worlds, some people like infinite non-depleting resources, some people like more scarce resources, some people like playing with cliffs, others do not. Debuff, nerf bots as you see fit but include the option to play the game without these changes. The best game is that where the player can choose the type of game they want to play.

[huhn]

i feel like you have overseen something important about bots: https://abload.de/img/power5qqt2.png
maybe make power harder to get. i always have a feeling power get's ignored.

and another thing bots are hard to use efficiently you need thousand of them so they can be spread evenly and over the base to lower delays. the screen is from a save with 100000 bots and only a couple thousands are active at any given time but i still need atleast 20000 with no question.
you need >a lot< of roboports to recharge them.
they don't work over long distances and most important you have to make sure they are not trying to go long distances. belts and trains always work no matter how long the the distance is.

not saying they are not op or better than belt but i have a feeling you are looking mainly at the sunny side of bots.

[Jürgen Erhard]

One idea to fixing bots v belts is to give bots a pickup and drop-off time, during which other bots are unable to interact with the chest. This limits the throughput of them without ending up with the situation where you "just build more bots" because that doesn't work without adding more chests (which depending on the design may be impossible). Making so that chests have a 0.25 second pickup/drop-off time (for example) still leaves bots useful for constructing blueprints, providing the player with resources and moving modest quantities of goods around (for example for late game automation of construction of barely used buildings such as pumps and tanks or similar) but limits their ability to render belts obsolete for moving vast quantities of goods around.

You can still work around this (for example, by having multiple logistics chests fed from splitters, or similar) for those who demand to use bots for everything, and it would still be effective depending on the design, but it would severely limit the ability of bots to be competitive with belts in situations where belts should be the logical choice (mid-range, bulk movement of goods)

"It would severly limit" Yay, great! Force people to play our way! Make it moddable, and I'm game. Hardcode it, and I'm out. Maybe I'll be a tiny minority… maybe I'm not? Remember that the forum posters are a teensy tiny minority. Always, no matter the game.

[TheRaph]

My opinion to nerf the bots and raise the belts is this:

1. I think any nerf to bots itself should have a "technical reason", anything other will look and feel artificially and therefore is not fun. I think one way is to prevent bots from insert in a chest at SAME time. As I see the network - chests have something like a port on top, so may the bots only connect one by one to this port to fill and empty. So you can leave all types of research as it is, (and item number per bots will then be more worth fully than add more bots). So the throughput is limited by a technical reason and can be expanded by using more chest or shot belt lanes attached to that network chests.

2. It may also thinkable to have a limited amount of bots per network (this may be explained by every bot needs it own frequency for control ... frequencies are limited ). So the player will be forced to think about different networks an how to link them (by belts, trains etc.).

3. Splitters: Nice work so fahr, but there should be an advanced type of splitter with an option to set the split ratio. So you can cascading 2 splitters so, that the first one splits in 1:2 ratio an dthe second one connected to the 2-lane splits 1:1. Overall you have then a 1:3 splitter.

4. Stacking belts: please don't stack items on belts. Stack the belts instead. So after some research you may use a second and a third layer of belts on top of existing belts. So you may use up to 6 lanes per belt. (I've seen a photo of real live stacked belts earlier in this thread). The should be ramps to side-load every row of belts and also there should be vertical splitters. (I'll explain this later in suggestions section ).

5. Last but not least, I like the idea of having pressure tubes with capsules for short range operations.

[MeduSalem]

That's funny, I might be wrong, but I get the feeling that most people who ask for a bot debuff actually mostly play without them (or with very little of them).
So basically, it's a "bots should be nerfed because I don't use them, so it won't change my playstyle, while hindering the pleasure of those who do like them".
I understand there are some extreme people who made 100% full bot megabases, and also people who did something close with belts only, but let's face it, these cases are surely a minority.
Most people happily mix both, and have fun with that. Nerfing bots will not make belts more enjoyable, and it's not a necessity.

I'd also like to point a comment made one week ago on another topic :

I think Twinsen has his head stuck in postgame land. He's seeing players finally reaching Factorio's breaking points in the post post post game, but treating it like a flaw in the main campaign. It's not. Players are reaching those breaking points because their objective is to literally break the game. The distance they have to go to reach those breaking points is nothing short of ridiculous, and the devs should be proud that players have to try so damn hard to finally break something. But step back and put things into perspective. Any balance discussion outside the game's main objective is literally, LITERALLY beyond the scope of Factorio. It's fun to see how far the post game can go, and if you have crazy new tools that help players to go even further beyond that's great. However, game balance in the post game is ultimately not that important. It's certainly not worth game sweeping changes that compromise the enjoyment of the main game.

This expresses very much how I feel about the idea of nerfing bots.

Now I'm very much in favor of making belts more fun. Not necessarily buffing them in terms of performance, but in term of flexibility and usability. What's been shown on the splitters is a perfect example of that.

After sleeping a night over it I have to agree with both Koub and bobucles. I have nothing more to add to the discussion.

[kisss256]

I understand it could be a serious computational issue, but why not have robots physically collide with each other?
Overuse of robots becomes difficult, but could be managed with good design of flight paths (up to a point, easily controlled with payload capacity).
I find the current overlaying of robots (with cumulative shadows) quite disgusting in any case; just a few layers of aerospace (research to gain higher altitudes) would not only make a more complex system, but also make it nicer to look at.

This *should* make robots equally powerful at small scales, and add complexity at larger scales.

[Alice3173]

The reason bots are OP is because they have no collision. Make one bot only occupy one tile at a time at most and it would nerf bots significantly without nerfing them for small conevnience only uses, as was intended

This has been repeatedly addressed. It would negatively impact performance quite badly.

[bNarFProfCrazy]

I really like the idea of "filtering splitters", but please only for the highest tier (otherwise you make the early game to boring.)

If you need a way to debuf robots, make them gain less speed per research level or make research more expensive.
(Keep it the same for the first few research levels, but after that make a steep drop.)
That way you could easily control the initial price for bot based bases.

If the cost for a robot based setup is X times higher than using belts than no one will use them.
But bots would still be a good help for products you only need once in a while.
That way the smeltry or other high throughput systems would end up, belt based and the main supply base robot based.

As an alternative you could add a min distance betwen robo ports that way the base setup would get more complex, as you need a lot of more space for all recharging stations.

[AlmightyJu]

I don't think nerfing bots will solve anything, all that will happen is people will place more roboports, use more bots and build more power. To those saying to limit how many bots can pull from a chest I say the solution is simple, more chests and inserters between them, it doesn't solve anything, just makes bases bigger.

Once you get bots automated to be made and put into roboports it doesn't matter how you nerf them they will still be more flexible and easier than belts.

I think the big issue is that belts don't scale, bots have research that makes them better (carry and speed) but belts have nothing, once you've got blue belts all you can do is add more belts and fitting them into designs can be hard work and time consuming (although I find that the most fun way to play).

What I would want is tiered research to buff belts beyond blue, I'd be happy to just buff the base speed of belts, to resolve the issue with inserter speeds (because buffing that would be bad since that would be another buff for bots) there should be another entity like a loader which can pull things from a belt at infinite speed or put things on a belt at infinite speed but only be usable to/from assembly machines and trains, not chests, it would have to be 1x1 as a direct upgrade from inserters tho.

[tmx]

The reason bots are OP is because they have no collision. Make one bot only occupy one tile at a time at most and it would nerf bots significantly without nerfing them for small conevnience only uses, as was intended

This has been repeatedly addressed. It would negatively impact performance quite badly.

I'm not saying implement collision, I'm saying make a grid and allow only one bot in a grid cell, that wouldn't impact performance at all

[Pascali]

i actually think weight would be a fantastic idea. cargo size AND maximum weight research (to a limit).

yes, so belts can transport everything, but bots not. And al lot off goods can be transportet by bots, but not so effective like belts can do(because of the most interesting way to play has to be the most effective way to play). So bot-only factories are possible - but not the most effective ones. And at some ponts bots are more effective then belt - for leightweightet goods.

I really like the idea of "filtering splitters", but please only for the highest tier (otherwise you make the early game to boring.)

yes, and better don´t to this at all. Better make bots being bad for the most setups.

Its funny to getting bigger and looging back. And gettings bots is a super feeling. But having bots not. Other games let you be killed an awaking without your BFG. Or getting better enemies like in Baldurs Gate. So factorio could bring in "better" goods. Good which can´t be used by bots or at least very inefficient(the existing good too, maye 10% can be effective with bots). Bots can bring in a new quality. The quality of beeing lazy or getting something quickly to run. But not beeing effective.
People need something to do. I watched some kids building a snowman these days. After the work they destroyed it. And they startet a new project. So getting the snow man(bots) is nice, but after that - its getting boring. You have no goal anymore - nothing really to do. Lets destory the bots. After getting them a countdonw starts - 100 playing hours.. after that they all crash down! Or let flying biters getting them attacked making them super ineffective.

[dstensnes]

My take on this problem: Don't worry too much about it. You have made a great game, and some aspects of it will always have stuff that you disagree with, but that you might have to leave in, because people have gotten used to it.

That being said, there are ways to extend the game while providing new challenges. Here is my suggestion: After you are able to launch rockets, you could implement a new world in space, which is basically a void world. In this world, different rules could apply, because you are in space. Random ideas:
* tethered robots?
* no robots, because they don't work in space?
* slower acceleration and deceleration for robots, due to no atmosphere, lower friction caused by no gravity or whatever?
* tubes instead of belts, because no gravity, allowing an entirely different ruleset for moving stuff around?

Random ideas for to the current world, (might have different equivalents with different rules in space):
* rail mounted inserters for greater reachability. Rails could be deployed like belts are deployed today, but on a separate layer above the rest of the base. Inserters placed on these rails could move back and forth providing greater range and usability in tight spaces (to compete with a single requester chest)
* bigger modules (2x2, 4x4 or whatever) moved as a single visibly larger entity, unable to be moved by standard robots. A 2x2 furnace being moved by a tiny robot does not really make sense in the real world.
* larger inserters, like industrial size cranes, for moving larger entities (furnaces etc)
* welding required for some structures
* building, placing, welding from vehicles or special utility wagons as a moving platform you can build on. Potentially for placing larger structures.
* more specialized vehicles, like rail laying trains, building placement vehicles and building assembling for larger structures.
* robots require fuel instead of electricity. Requires liquid fuel piped to dedicated refueling stations.
* robots might have a chance to break down, and require regular maintenance with spare parts in a maintenance station and possibly lubrication piped in.

Much of this would nerf the robots by limiting what they can do, but a trick for further developing the game could be to provide more environments, where different rules applies:
* space environment
* under water world
* sub surface world with tunnels. Bots movement restricted by the walls. No solar power. Digging for oil or mineral deposits.
* dyson spheres without oil
etc.

Conclusion: I would bet that applying different rules in different worlds/environments is also easier to accept by the general player. You have made a solid game already, and using this as a base I would say that this game could be expanded on for years by introducing more environments as DLCs or expansions. Multi-world and multi-environment stuff would also require new mechanics for transporting resources and players between world, multi instances with players scattered across multiple world, between-world communication with circuit networks for requesting delivery via rockets (does not even have to be instant communication, but only updated every x minutes, or a delay based on distance between planets etc). Multi instance worlds with different environments could also help with UPS problems as they could run as separate processes in the operating system on the server, only occasionally exchanging messages about logged in players or exchange messages about requested resources via circuit networks etc. Players also only need to receive information from the instance they are in, and only keep stuff available in the current world in memory too.

Anyway, keep up the good work and thanks for an already great game. We absolutely love it! You are great!

[Avezo]

I think there exists yet unmentioned problem with belts that GREATLY encourages bots in early game, even before taking throughput into consideration.

Simply put, resource costs as you progress through research is too 'steppy'/'spikey'. At start you build relatively small base supporting small science needs, then you need some more so you build a bit more, the you try building more, but suddenly instead of needing a bit more of everything you need tons of one material, yet as base grows there is less and less space to deliver it via belts, so sphagetti begins, then in later game it only gets worse and you just give up with this 'puzzle', they become unsolvable, it's much easier to just say 'screw it, bots will carry it'. And it will remain the same, no matter how slow they are or how expensive their recharging is.

The most problematic parts of progression in this matter in my opinion are:
-Red circuits
Typical build for red circuits alone is huge, add refinery ontop of it... And then you will be lacking them anyway when you get to late game science packs, but there will be no room for it anywhere close to connect with belts properly.
-Blue circuits
They cost insane amounts of green circuits, try having just half a belt of it and boom! 10 green circuit belts gone. Good luck trying to resupply such huge amount via belts when 2/3 of your factory is already built
-Yellow science
That sudden spike of copper eater for 30 wires per pack???
-Light density structure
This is another sudden eater for steel and copper
-Steel and copper alone are problematic
On the entire production chain, copper is very spikey, you need tons at start for green circuits, then almost nothing, nothing, nothing, and BOOM! Suddennly tons of it for yellow science and LDS
It's similar with steel, which is even more important given how huge smelters for steel needs to be, you need almost nothing through the entire production chain except for the spike at the end - LDS
-Modules
They consume crazy amounts of circuits. While this might be intended, it just feels wrong that given they huge cost, they feel more like a true endgame item than the rocket itself.


So - you can't expect from begginer player to plan entire base ahead to have room for everything. You can't expect from experienced player to have fun in early/mid game having to walk huge distances without exoskeleton when they leave huge areas free for future expansions. In both cases it's easier to just rush bots so they overcome this issue.

General solution is to 'flatten' recipe costs increase through the progression - mostly reduce their costs or craft time at 'spikey' places - especially craft time of red circuits so build is smaller; and green circuit cost for blue circuits so they don't cause huge spike of green circuit consumption. But it also means that in some places it would be good to INCREASE costs and craft time to keep costs increase more linear (especially copper needs it IMO), so players upgrade their supply before it's too late and base is too packed to fit yet another belt.

That way players would stick to belts for longer. Unfortunatelly it might make general 'puzzle' part more boring, but that's why I think you should buff modules together with it (and buffed modules might go well with removal of becons) to keep more options open what to do after reaching the end of production chain progress.

[wwdragon]

I read todays FF and I think... you Factorio devs are completely clueless on this subject!
There's nothing wrong with bots being far more poweful then belts; they are a direct step up!

Stop trying to break what's not broken!

[Shados]

Preface

I thought it might be interesting to collect all of the sufficiently-specific suggestions made in the thread, and aggregate them into rough groupings, with references to the posts. So I went and did that, then thought I should go a bit further; prepare for giant wall of text.

Notes

Suggestions are numbered by appearance in the thread. If you see a post that wasn't included, it's because of one of the following reasons:

• I missed it
• It obviously wasn't intended as a suggestion in relation to the bot / belt discussion
• It wasn't specific enough to actually be implementable (e.g. 'you should focus on X instead of Y')
• It has blatant issues to the point where I don't think it's worth discussing. But I'm a random stranger on the internet, so feel free to ignore that judgement.

Notes on reading the list:

• 'bots' here refers to logistic bots, not construction. And possibly not applicable to logistic bots when they're supplying players, depending on the suggestion & the poster.
• References listed below a suggestion are links to comments in the thread where people have defined or expressed support for the idea. People may be listed more than once for a single suggestion if they later come back and add more details (or add a variation on the suggestion).
• I do not intend this list to imply that more popular suggestions should get implemented, so don't take it that way.
• If you feel I've misrepresented your suggestion in the process of aggregating it with similar ones, or otherwise misunderstood it, feel free to correct me with a post or PM and I'll get around to editing my post (at some point, probably). Or fite me IRL.
• You may note that simple 'reduce bot cargo size' and 'increase bot charging time' aren't on the list; as many commenters have pointed out, they would only result in building more bots and roboports, they don't deal with the underlying problems.

Suggestions List

• S1: Add belt un/loaders
  Zeblote, psihius, Sigma1, Omarflyjoemacky, TheBrain0110, Tomik, aequitas, alefu, Avezo, purdueme91, Visione, vyktor, ssilk, warlordship, mcvey, Zool, PacifyerGrey, Gemoron, wlfbck
• S2: Limit amount of bots that can interact with a container simultaneously / explicit bot/container congestion / limited speed of bot un/loading (e.g. by explicit queing with un/loading speeds, or by a token bucket queuing system)
  Zool, SeigneurAo, tarou00, Jarin, TheBrain0110, CremionisD, aelios, djtumolo, warlordship, Nick-Nack, ignatio, Antilope, Moin, Dranzer, vipm23, PacifyerGrey, Mestiff, Therax, vipm23 (again), kenken244, vorax, mavu, Iyallp, js1, Gendoh, Soloincognito, Reika, Optera, ttapada, Omez, PacifyerGrey, Brunel, Tomik, Drone, TheRaph
• S3: Add expandable splitters / balancer constructs (or at least some larger ones than 2-way)
  Ubertwink, admo, Zeblote, Whirlin, CmdrKeen, Vader, Esja
• S4: Restore underground belt compression
  Ubertwink
• S5: 'Belt stacking research' that makes all belts natively stack things
  OrigamiGuru, TheBrain0110, Yinan, Lubricus, Killcreek2, WIZ4 (may actually be S23), Tomik, quickshot0,
• S6: Implement nested/recursive factories (ala Factorissimo) that deny use of bots within them
  Ecu
• S7: Repeatable (possibly infinite) belt (and possibly inserter) speed research
  3trip, Visione, SHADOW13, giustizieri25, Durentis, Esja
• S8: Stop beacon space requirements heavily favoring bot designs (e.g. Stop or limit multiple beacons from stacking while adding another mechanic to ensure they remain effective, add smaller beacons with smaller AOEs, make beacons work by transmitting effects point-to-point over power or circuit or logstics networks)
  3trip, Tinyboss, 3trip, vipm23, stokan, PacifyerGrey
• S9: Make splitter behaviour even more configurable (e.g. per-lane controls, toggle for global vs. per-item alternation)
  quyxkh, Dranzer, GotLag, mergele
• S10: Network-wide restriction(s) on bots (e.g. hard cap on number, decreasing speed, increasing power cost)
  AgentPaper, Samlow, Inglonias, kingoftheinternet, Samlow (again), kenken244, hectar, Hakisak, TheRaph
• S11: Increase bot total power consumption (not charge rate)
  Ractaros96
• S12: Make one or more faster belt tiers
  Ractaros96, warlordship, yukkusu, Zool, Stevepunk
• S13: Nerf power production / power transmission / increase power consumption in general
  EntroperZero, psihius, purdueme91, DragonMudd, purdueme91 (again), Tinyboss, blueblue, huhn
• S14: After nerfing bots, include a way to keep the original bots around (e.g. ultra-late-game research, alternate game mode, configuration option, appropiate modding API)
  CremionisD, gerren, jodokus31 (except with nerfed bots as the alt. mode)
• S15: Implement 'covered belts' or similar (higher throughput, inserters can't interact with them, change over to normal belts via splitter or dedicated machine, may involve not visually rendering items on the belt)
  <NO_NAME>, warlordship, motox, Yarri, hansinator, stokan, Sogrog, quickshot0, promaty
• S16: Add a fourth item transport mode
  Samlow, warlordship, Mimos, sergey--05, tmx
• S17: Add side-inserters, or enable side-insertion functionality on existing inserters (possibly via research)
  alefu, Sigma1, warlordship, briezee, Dranzer, Tomik
• S18: Explicit per-area restriction(s) on bots (e.g. hard cap on number, decreasing speed, increasing power cost)
  Topher, ctrlaltdel02, Meister_Knobi, ssilk, Elecen
• S19: Split late-game recipe requirements into a couple of high-volume common resources plus a few low-volume rarer resources
  Topher
• S20: Reduce the production cost of belts
  Avezo, Redoneter
• S21: Nerf long-distance bot delivery times (e.g. by preventing bots from recharging before their delivery is done, by by increasing increasing charge costs for every roboport zone crossed, etc.)
  Avezo, yekkusu, ssilk, Avezo (again)
• S22: Have belts carry power and supply it to devices in a 1-tile radius
  aelios, scali
• S23: Make stack inserters natively un/stack items (possibly just on belts, possibly as a researched upgrade)
  CmdrKeen, Lubricus, warlordship, tazdu29, madeof_tin, BluetoothThePirate, PacifyerGrey, ili, PacifyerGrey (again)
• S24: Implicit restrictions on number of bots traveling in an area (e.g. by adding bot collisions, repulsion/avoidance fields around them, throughput-limited pre-determined flight paths)
  djtumolo, fallobst22, pleauser, vyktor, Meister_Knobi, Meister_Knobi (again), tmx, kisss256
• S25: Make inserter filtering functionality an option on all of them (possibly locked behind research or an insertable module
  warlordship, tazdu29, Dranzer, Tomik
• S26: Add a train loader machine which can load/unload trains from/to belts at full compression and full speed (restricted version of S1)
  warlordship
• S27: Remove request/provider/storage chests, add storage capacity to robo ports so all logistics movements are between roboports (and players)
  jeriktelorian, Elok
• S28: Pairs of machines that effectively 'teleport' items around a base
  Bertus, mOoEyThEcOw
• S29: Add an alternate bot charging mechanic that works by swapping their battery with a pre-charged replacement battery, if available in dock machine/roboport
  pleegwat
• S30: Making bots have an ongoing maintenance cost (resource cost over time, e.g. by batteries burning out, or needing replacement parts)
  Tekky, SilverWarrior, Mylon, mtilsted
• S31: Fix inconsistent inserter belt pickup behaviour
  Mimos, hansinator
• S32: Add inserters with multiple input and/or output directions (or allow existing to be configured that way, potentially with optional balancing)
  hansinator, Dranzer, devaking
• S33: Make bots explodey
  golfmiketango, Elecen
• S34: Make bots ability to carry / effectiveness in carrying a given type of item be dependent on its production complexity, such that bots can carry more high-complexity items (e.g. rocket parts) and less (or no) low-complexity ones (e.g. ore, plates)
  ssilk, scali, gerren, Llama (close enough)
• S35: Add more QoL de/construction tooling for belts
  ssilk, <NO_NAME>

Underlying Conflict

Is there a 'problem' in the balance between the gameplay effects of belts and bots? Well, to answer that, let's look at two other, related, similar balance questions: belts & trains, and bots & trains.

• There don't seem to be many strong opinions that either trains or belts/bots should be used instead of the other -- no one suggests that trains should be a straight upgrade to belts (even early ones) because they're further along in the tech tree, or that bots should be a straight upgrade to trains because they're further along in turn.
• Few if any people appear to be deliberately restricting themselves from making full use of either trains or belts/bots instead of the other (because they believe that relative to the other option they over-simplify the game, or believe they make things less interesting or visually/aesthetically appealing, etc.).
• Trains and belts/bots each over their own clearly-defined uses within the game, which are mostly separate from one another, even though you might be able to manage using the "wrong" one to perform a given function.

From this, I get: each of the three transport technologies (belts, trains, and bots) has a conceptual 'niche' in terms of what kind of tasks it is most suited for. The flaw lies in the fact that while the niche of trains does not have much overlap with that of belts and bots, the situation is different for the other two:

• I1: The niche of bots totally overlaps the niche of belts, and also covers extra things (that is, the bot niche is a superset of the belt niche)
• I2: Bots are better (more effective in terms of throughput, more convenient in terms of design and construction) at doing everything belts do (if you think this is a simplification, you're right, and I hopefully address your complaint later, so read on)

As a result, there's a tension between belts and bots that arises as a result of bots becoming progressively more of a replacement for (occupying more of the niche of) belts as they get upgraded and as your production facilities scale up. Meanwhile, trains with their mostly non-overlapping niche play very well with belts and bots.

The two issues immediately suggest a two-pronged approach: modify belts and/or bots to make their niches more distinct from one another, and mody belts and/or bots to make belts a (roughly) equally viable/'optimal' option in comparison to bots for the areas where their niches still overlap.

Additionally, part of "better at doing everything belts do" in I2 is that bots are significantly simpler and more convenient to use than belts are. Yes, they do get more complicated when you're building a megabase, but having built both a 'trains and bots' megabase and several 'trains and belts' megabases, I can confidently say that the latter is more complicated, and (to me) more interesting, engaging, rewarding, and aesthetically pleasing. I do think bots are a cool technology and I used them even in my 'trains and belts' megabases, but in a specific and limited fashion.

Caine proposed a similar model later in the thread, but I'd collapse space efficiency and flexibility together, personally. Space efficiency isn't really a direct concern; it only matters insofar as it impacts your ability to freely transport items within a factory module (a set of machines doing single task or set of related tasks and conceptually grouped together by the builder during design/construction), and freely place factory modules relative to one another.


Why should we care?
But, hey, why do we actually care about the options having different niches? Well, mostly because it means that more-optimal factory designs will tend to be the ones that leverage all three of the different transport options, to a large degree. This matters because the solutions that use more of the tools available tend to be the more interesting and fun ones. While it should generally be possible to do things in a simpler way using a restricted subset of the tools, so people have an easier time starting off, it should also be desirable to come up with more complicated designs in order to sustain players' interest and enjoyment over time.

There've been quite a few good arguments from people defending bots as-is, based on their experiences of the game. While they're no doubt enjoying how it is currently, I don't think that in itself is a great argument to keep things how they are, partly because they do not appear to be anywhere near a majority of current players (let alone future players), but mostly because it encourages less diverse gameplay. Additionally, at least part of why they enjoy bots so very much is likely because of how awkward belts can be to work with at scale; improve that and I suspect they'd have a better time with belts than they may expect.

There have also been a few ideas around making bots and belts capable of explicitly supporting/enhancing the other. These are somewhat attractive, but ultimately I think they'd lead to less novel and interesting designs than having bots and belts each occupy their own well-defined niches -- because the other proposals would lead to greater homogeniety by encouraging you to use both types of transport simultaneously for everything.

Lastly, there were a couple of arguments that bots are cheaper than belts, based primarily on the cost of their associated research. This is missing the point on a few fronts, because it's making an apples to oranges comparison: current bots do a lot more than belts do, are significantly more convenient, and significantly more effective at what belts do (provide throughput of items across a given space) item for item. Making the comparison also implies that a single blue belt tile is comparable to a single logistic robot; but when you look at that explicitly instead of implicitly, it's obviously ridiculous.

Suggestions Analysis

Given the framework described, I went back and re-read all the suggestions, including all the new ones that occurred while I was writing stuff / making coffee (no, really, all of them ._.) to analyze them from this perspective and determine their impact on the two issues.

Before starting, and based on my first reading, I thought it would make the most sense to attempt to restrict the scope of bots niche to mostly focus on lower-throughput delivery of items across long distances, over complicated factory setups, or to/from especially tightly-packed factory areas.

I've annotated individual sentences of analysis with things like (I1) to denote which of the two underlying issues they have an impact on.

Of course, if you don't happen to (at least mostly) agree with my model, then probably the rest of my thinly-veiled rant won't interest you much. orz

• S1: Quite a lot of people like the idea of loaders. Frankly, I think this is just an inferior version of S26 (train loaders), because un/loading trains is really the only point at which they'd be necessary (for some value of necessary); everywhere else they're just pointless power creep. But if you disagree, they have the extra benefit (beyond S26's) of making belt setups more convenient (I2). If you have examples of other situations in which they'd be useful to core belt-based design aspects, and that aren't better improved by stack inserters or insterters that can compress belts, please do let me know. I'd be interested to hear them.
• S2: Variations on this idea are crazy popular, and I can see why: it doesn't nerf bot usage for all cases, but instead largely restricts bot usage to low- and medium-throughput scenarios (I1). You can also still work around it for high-throughput, but doing so requires increased complexity and space usage, making it more comparable in effectiveness to a belt-based setup (I2). Also, would be pretty easy to make this configurable by mods, letting people who like old bots ease into the changes (or never change).
• S3: Properly setting up belt balancers and main-bus-branches are a major pain point with belt systems, and this would go a long way to alleviating that (I2).
• S4: I guess this would maybe help a little with belt convenience (I2), but honestly underground belt compression is quite a bit of a hack, and very unintuitive. Just adding back belt sideloading compression would likely be plenty.
• S5: While I like the idea of stacks or pallets of items, I don't think this is the best way to go about it. A research that makes all belts (or even just blue belts) natively stack things would be overly powerful, and would also require improvements to train cargo sizes in order to not unbalance the train/belt niches. Would improve belt throughput (I2). Would potentially also mess with many circuit-controlled belt designs.
• S6: Would expand the niche of belts (I1), and building a belt-only recursive factory might be more powerful than a non-recursive bot factory for some cases (I2). This idea has the unique downside in that you would no longer be able to see your entire factory on a single plane, which is a really powerful thing for design, analysis, debugging, and comprehension. Making elements of factory design/functionality "invisible" to the player runs fairly counter to Factorio's existing design (the devs have gone out of their way to make things visible).
• S7: Would increase belt throughput (I2). Somewhat interesting, has some issues: increasing belt speeds would (currently) require increasing inserter speeds, or something like loaders, and there's a more fundamental but subtle issue where it would break the possibility of many circuit-controlled belt-based designs if belt speeds were variable over time.
• S8: Affects belt-based factory performance (I2), doesn't involve a bot nerf, would result in prettier factory designs... looks good to me.
• S9: Affects belt convenience (I2), a little. Mostly unrelated to the issues, honestly. More generally, I'm not sure if these changes would be a good thing... I'd need to spend some time figuring out how difficult various things would be with/without these options.
• S10: This is an interesting one. Would promote building smaller, more isolated networks with medium-throughput bot usage and/or large networks with low-throughput both usage, and as such would alter the bot niche (I1). As some have suggested, would likely need to be paired with a mechanic for maintaining separate logistics networks with overlapping physical spaces (e.g. "coloured" logistics networks).
• S11: Wouldn't do much on its own, in concert with S13 it would affect the viability of mass-scale bot usage, while leaving the rest intact, changing their niche (I1).
• S12: Would improve belt throughput significantly (S2), has only some of the issues S7. I don't think it's a great approach, though; do we really need yet more tiers of belt that are just higher-throughput...?
• S13: I'm kind of in two minds over this, and on its own it isn't really relevant to the issues, although it could be if combined with S11. I think coal is well-balanced right now, solar maybe could use some changes, and nuclear may be OP. On the other hand, I'm not actually sure it's a problem if nuclear is OP -- it frees you up from having to worry about the problem of power supply, which isn't necessarily all that interesting. On the other hand, maybe this should be changed, and mechanics should be added to make power supply more of an interesting challenge... either way, it's kind of out of the scope of belts & bots.
• S14: Doesn't affect either I1 or I2, but on the social level it's probably a good idea, as it'd give players who like old bots a softer transition (or no transition, if they want), resulting in less salt.
• S15: Would improve belt throughput (I2), and the restrictions basically mean it's largely only suitable for acting as a 'main bus', kind of implicitly promoting that style of design. Which could be a good or a bad thing, depending on your perspective -- either the devs would be making solid design choices more discoverable/intuitive, or they'd be forcing a certain gameplay style.
• S16: ...This isn't so much 'out of the box' thinking as 'build a new box' thinking. I mean, it doesn't affect either of the two issues, and instead introduces an entirely new niche to think about. Additionally, none of the suggestions thus far are specific enough to be able to directly implement and thus actually determine out what that new niche would look like.
• S17: Would allow for more compact belt-based designs (I1) and also potentially allow for more effective/performant belt-based designs I2), although to relatively small degrees for both. I still think it's a good move, even more generally.
• S18: This is a variant of S10, and similarly would likely restrict the niche of bots somewhat (I1), but I'm not sure it'd be as effective in doing so, or provoke as much in the way of interesting design decisions. I could be wrong though.
• S19: Probably a good idea in general; would help to promote a split between high-volume and low-volume transport mechanisms, so might impact the niches of both belts and bots (I1), although probably only in concert with other changes.
• S20: plz yes. Yellow belts are fine, red belts feel like a huge jump up, blue belts to a somewhat lesser degree (because you've scaled your systems more by then). Making faster belts cheaper would make them a lot more viable to use in general (I2).
• S21: Nerfing long-distance delivery times would only increase the latency of bot transport, not the througput.
• S22: This is a pretty neat idea, it would enable some more compact belt-based factory designs (I1) and generally make belts more powerful and convenient (I2). I'm not certain it fits the game overall, but it's an option that should be considered
• S23: Another try at stacks/pellets, improving belt throughput (I2). I suspect this one would work better than S5, depending on the specifics. More on this option later.
• S24: A suggestion in a similar vein to S10 and S18, with similar likely effects, but would probably be more computational intensive to implement, depending on the specific variation. It's also less explicitly manageable by the player, which I don't like.
• S25: Makes belt-based designs a little more convenient (I2) but probably isn't actually that relevant to the issue. But: generally seems like a good idea. Filtering inserters as a separate item is a little weird given how infrequently they're useful.
• S26: This is a good one. As mentioned, I think general-purpose container/belt loaders are just a worse (overly powerful) version of these. These actually solve a specific issue: even though there are 6 tiles adjacent to a cargo wagon per side, you can't actually unload from those six tiles to six blue belts at full compression using only inserters. Adding these would mean belts are actually viable for train un/loading (I2), which is a big issue.
• S27: This would restrict the niche of bots (I1), but it wouldn't actually reduce the main overlap with belts niche much (high-throughput transport within short/medium distances) and would remove bots from the part of the niche they uniquely occupied (transport of low-throughput items into/out of really compact, physically constrained builds).
• S28: This is kind of a fourth item transport (like S16), but detailed enough to be implementable. Problematic in that the niche of these devices would overlap with bots a lot, although not much (if at all) with belts. Intriguingly, you might be able to argue for replacing bots with an idea along these lines, and it would admittedly be endlessly entertaining to see items being shot out of cannons and flying through the air all around your base (and into your face)... And a long-range version could potentially be an interesting option for low-volume, irregular supply of materials to outposts (e.g. repair packs, replacement set of bots).
• S29: This doesn't really affect either issue, although it does make the really-late-game complexity of bot charging slightly more obvious. It is a definite buff to bots, but I actually think bot charging mechanics do need a buff, so this isn't a bad idea in general, once the bot/belt issues are resolved.
• S30: If expensive enough, could impact the ability to use bots at mass-scale (I1), but would also negatively impact the use of bots in general (civilian casualties D:), so I'm not sure it's a great idea. Also introduces the problem that you'd almost certainly want to use the bots themselves to transport the maintenance material into the roboports, which could get awkward...
• S31: Doesn't really have a major impact on the issues (very very slightly on belt-based factory performance, so I2), but definitely an issue that should be fixed in general. Current behaviour is surprising, confusing, and the cause of subtle and aggravating performance issues in belt-based factories.
• S32: This would enable more compact belt-based factories with complex inputs/outputs (I1), and would make belt-based factory design somewhat more convenient (I2).
• S33: Well... This could somewhat make bots less powerful (I2), I guess, but seems a little too nutty. Honestly, I've only left it on the list because it's hilarious.
• S34: An interesting one. Would directly shift the niche of bots towards transporting low-volume items that need to be moved across long distances or over inconveniently full parts of a factory, as well as simply for moving low-volume items that are only needed or produced in very small amounts (I1). Making bots unable to carry really low-complexity items would be restricting their flexibility too far, I think, but maybe reducing the bot carrying capacity of things like ores and plates to just 1 would work well.
• S35: QoL/convenience additions to belt de/construction would make them more convenient to use (I2), and all of the suggestions mentioned seem like solid ideas in general, to me.

Synthesis

Well, it looks like there's a lot of options for the devs to play with in regards to dealing with the two underlying issues. I'm sure they'll eventually end up choosing some good ones that make the game more interesting, engaging, and visually appealing, as they are wont to do.

But while I'm writing this ungodly monstrosity of a post, I might as well put down what I think a really good set of selections could be. Obviously, high on opinion and speculation.


Logistic bot/container concurrency limits (S2)
Because it would have relatively low impact on existing bot designs before fairly late-game (so, most of them), and it would clearly shift the niche of bots toward supplying low-volume items across long distances or in tight spaces. Bots would still need to not have limits on supplying the player, to not kill QoL.

Downsides: would be slightly odd if construction bots still had instant access, but we really don't want them to be blocked by concurrency issues. Would also need to be able to supply the player without concurrency issues.

Might be able to deal with those issues by simply setting the concurrency limit high / un/loading time low enough. Possibly also suplementing with a limited version of S34 by making the cargo limit for ores, plates, and green circuits 1.

Overall, I think S2 is probably the best method of changing the niche of bots, and restricting their effectiveness where they still overlap with belts. It's also one of the most popular options, going by this thread, so implementing it would likely generate less salt.



Further Alter Belt & Bot Niches
I think a few further things should be done to more clearly define belts & bots separate niches. Specifically:

• S26: This is the most important one here. Trains have space for 6 belts on either side of them, but literally cannot be unloaded onto 6 express belts at full compression using only inserters, right now. Belts should at least be able to compete with bots in this regard, and given the way I've suggested their niches should be defined, belts should be the better option.
• S8: Change beacons to have roughly equivalent effects but without stacking mechanics, removing the space advantage of bots in beacon-enhanced factory modules. Also because the current setup is ugly as sin and has one obvious optimal configuration.
  Ideally, I think it'd be cooler to instead have some kind of 'effect generators' that are connected by electrical network (or a new wire type run over it) to target machines.
  Each would be able to affect several machines still, but with no stacking, and you'd be able to select which it affects from any connected the network. Would need some new interface mechanisms for easily (re)assigning groups of effect generators to groups of targets, and for identifying what affects what.
• S19: Designing high-tier input requirements like this generally seems like a minor but solid change to transport mechanism balance / niche separation.

Improve maximum belt throughput using item stacks
By making stack inserters inherently capable of creating stacks on belts (S23). Specific details:

• There should be a late-game research (around the same time you get the last few robot upgrades, or not long before) that enables all existing stack inserters to combine items into stacks (sized up to the stack size the stack inserter is currently set to).
• Stacks are formed of only 1 type of item
• Stacks can be placed onto all normal belts
• Stack inserters can place onto a stack that is smaller than the inserters set stack size to top it up, but cannot make it larger than their stack size
• Normal inserters cannot create stacks
• Normal inserters can skim items off the top of stacks (or pick up all the items in a stack, if it is small enough)
• Stacks don't exist anywhere but on belts
• Splitters can optionally break stacks into unstacked outputs on one or both of their outputs (or individual lanes, if per-lane controls become a thing)
• Stacks are created only by a stack inserter placing them onto a belt, or by a splitter (maybe an advanced/stacking splitter) set to output items as stacks

One of the consequences of this would be that train cargo sizes would need to be improved, as otherwise belts would be encroaching on more of their niche than ideal. Plus, they're kinda weeny as-is, I mean, they're 'physically' 6x2x2 chests in size at least, but don't carry anywhere near that amount of resources...

The main point of this is to enable belt throughput to be hugely increased without requiring ludicrously wide belt rows, nor the accompanying insane belt balancer and branch/feed arrangements. Main bus/tree design is a core element in belt-based systems, and this would enable that to scale much better than it currently does.


Expandable, flexible belt splitters (S3)
On one hand, I kind of quite like the giant belt balancer abominations we have right now; watching the items move through them is almost hypnotic. On the other hand, they're totally unintuitive, and the game doesn't mention them or otherwise expose the player to them at all, so learning about the issues behind and importance of belt balancing is non-trivial. Belt balancers and balanced extraction from a main bus are big pain points in build belt networks.

Given this, I think it would be a good idea to continue the splitter enhancements, and enable us to build much larger (but not arbitrarily) splitter constructs by placing down existing splitters. The simplest arrangement would probably be something like... any two or more splitters (up to some large maximum) physically adjacent and also connected via circuit wire (allow it to be run directly between them) form a single large splitter, which can be configured with all the same options that single splitters can.

Doing it this way allows for maximum flexibility in positioning/arrangement, at least, but doesn't preserve the aesthetic complexity of the older ones, sadly. I'd be interested in better suggestions for specific ways of implementing expandable splitters.


Minor belt-based factory improvements and QoL features

• S35: The QoL improvements from these two posts: 1, 2
• Make belt sideloading compression work again! This is basically the only one of the compression methods that is at all intuitive given the basic belt mechanics, and it also makes a lot of sense visually/physically. Watching side-loaded belts not compress just looks subtly wrong.
• S20: Make belts cheaper to construct. You need absolute shitloads of them.
• While you're at it, and on the same note, increase belt stack sizes, maybe? Say, double them?
• S17: Side-inserters, preferably not as separate items but a configurable option on them. With hotkeys. I'd say without even a research requirement; but if it has to have one, make it early.
• S25: Make inserter filtering an option on all inserters, instead of a dedicated item. Still locked behind the same research.
• S31: Fix the inconsistent behaviour re. inserters picking up items from belts in different orientations relative to them...
• I'd also suggest making it so that all inserters can pick up from belts of all speeds without issue. Conceptually, inserter 'claws' should really hover just above the line of moving products anyway, always ready to immediately grab one and jerk it back off the belt a bit before more slowly lifting it into place.

Possibly also:

• S32: Inserters with multiple, configurable input/output locations seems like an interesting option, although probably as a new inserter type? Might be a bit much.
• S9: Make splitter behaviour even more configurable, with ability to apply controls per-lane, and toggle between global and per-item alternation across lanes in an output
• S22: Have belts carry output and supply it to devices in a 1-tile radius. OK, so, totally unnecessary and I just want to see it happen because it'd be cool to play with it . I should probably just go mod this in, if possible.

Buff Bot Charging
Bot charging is gimped and awkward as hell right now. Slamming down a bunch of roboports looks shitty and is a boring way to solve the issue. There's no reason not to buff this once bots niche is more clearly defined. Some ideas on how to fix it up:

• S29: Add support for (nearly?) instantly recharging bots at a roboport by supplying them with pre-charged replacement batteries. Let the batteries be charged in the roboport, but also in dedicated machines for it (and then just belted/botted to the port).
• Add a kind of 'tesla tower' object that can wirelessly charge bots in range. Possibly with some loss in efficiency (maybe scaling with distance?), hopefully with some sort of awesome animation involving lightning, somehow. Bonus points if it can charge the modular armor gear of players in range of it.

TL;DR

It was Saturday and I was bored. Now it's like 4AM Sunday and I have a headache. This was a terrible idea.

[Uggeli]

can you hook splitters to circuit network now?