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

[Inglonias]

...
So the first thing I would break however, is bots scaling linear. The most gentle sollution in my eyes is just having diminishing returns on all bots speed within one logistics network. The more bots are in the network, the slower they fly. This would make bots better at smaller segregated networks for production facilities, or larger radius lower volume supply.
...

I really like this idea a lot, and would absolutely love to see the devs at least try it. The only problem I see with this plan is that at face value, it removes all bot scaling. Unless you can raise that limit somehow, it feels kind of arbitrary. The most intuitive way to do this would be to scale by how many roboports are in the network, but that doesn't actually fix the problem. An infinite tech might do the trick.

[Caine]

(PS ~ to the moderators: Great job moderating the last FFF thread, letting the discussions run & only stepping in when necessary. Bravo!
You guys don't receive enough praise for the job you do, so: Thank You from me.)

This needs to be said every once in a while. I will gladly add my gratitude to that. Great job, thanks for the dedication.

[Ahry]

The splitters is really good improve.

And i thing that plates is not soo bad idea... but yes it is not soo interesting. But it can be made like trains can not take them and also robots can not take them. So it make blue belts like 4000/s throught put and it is something.

And thank you to inspire me to make belt only mega base... i really accept that chalange... but it will be really hard, because everyone want modular (easily extensible) layouts and it is really easy to achieve by robots.
But when i make belt only sollution for furnace with 2 blue belts output I feel like master . But when I want to build green circuit i feel frustraiting. Maybe i will try palets mod and then throughtput 4000/s will be enought also for green circuits .


Btw. delete recharge for cargo is ineffective i think, because you only buil 4 times more bot, and thats hard at the middle but really easy at the end of geme.

[Meddleman]

The filter-splitter buff is amazing and I love it. Can't wait to see it in the next update!

This opens up many new ways to use belts not just within factories, but on mixed mining fields too.

Love the changes to splitters especially the priority functions. TBH I'd rather have a filter on electric mining drills than splitters though.

A tree of such filter-splitters could be used to instantly sort that which has otherwise required large convoluted filter-arm setups prone to backing-up if a particular resource is not consumed quickly enough, or "Black Magic" exploits that take unintended advantage of the inherent "splitting logic" of regular splitters.
If this future splitter buff could send and read from the circuit network I see a future explosion of designs as we attempt to stretch the limits of what this new toy can do.
I even see mixed-item belts becoming a viable option once again as the ability to quickly sort objects into and out of a belt becomes a simple affair. Even filter inserters do not lose usability to this as they fulfull the purpose of being both an inserter that can filter.

...

I realize this is a reversal of my previous comment in #244, but reading 45 pages of comments did open my mind a little to better opinions.
To reference Extra Credit's video on Power Creep, sure we can buff belts to make them a more competitive choice but it will not solve another potential looming issue:

Let us take kovarex's little experiment and imagine a world where both results were the same.
Game's balanced now, right? Belts and bots are equally powerful and its up to the player to use what they want? Perfect world and everyone happy? I doubt it, because from this point onwards, every subsequent change or update or addition to the game would require a finely tuned finger to not disturb this delicate balance. You've also created a much deeper rift between Bot, and Belt players as they simply find smaller anomalies in the other's gameplay to bicker about. In the end, both options become more alike when in fact they should become more radically different, and not in the strict numerical "I am better than you in everything" sense.
Side note: Yes, I get the fact that Factorio is at its heart a "resource manipulation & transport" game, so being able to move more items at a faster pace is a core element not to be ignored.

Perhaps this is not about a war of "what provides the best throughput", but rather "what advantages and solutions do belts provide that a bot cannot", and of course vice-versa. For/Against playstyle-arguments aside, it's what always made Factorio fun whether you're a Timmy or Spike. What the devs are trying to achieve is an equilibrium of incomparables where the solution for a given issue is based on what you could build, not "should" or "must".

It is worth nothing that Bots feel cheaty because they fulfill the purpose of belt-, inserter-, and filter-in-one with the scale of this ability being only limited by the size of a given swarm.
But give a new usability dimension to ground-based logistics and suddenly everyone salivates like Pavlov's dogs ^^

Some of us drive from A to B and others just want to drive around. Those same people may want to do it quickly or slowly. In the end we all still use the same road.

[_alphaBeta_]

The problem isn't so much that existing factories will be broken (as far as I can tell) as it is that if you remove or significantly nerf bots, then the next version of factorio will support only smaller factories than the current version.
That seems like an obvious step back, and I think that is what many people are complaining about. Also the fact that to me and some others messing around with belts for untold hours gets old quick, and there is no real difference between blueprinting belts or robots.

A fair comment. This is probably the crux of the argument. I wouldn't measure "next version success" from the size of factories alone. Also to consider, albeit much less tangible and quantifiable, is the depth of game-play. Seems like we're sacrificing the latter for the former, which on the long term scale, seems unfortunate.

[kingoftheinternet]

Something that sounds great to me, given all the constraints mentioned here, would be to give logistic bots diminishing (but probably never zero) marginal returns as you have more of them. E.g., maybe all the bots become very slightly slower as the number of bots in a network increases according to some carefully-tuned function, which means your optimal-ish choices (depending on your goals) are:

1. have lots of small, isolated networks (which I guess would reward very careful factory design that optimizes for this; maybe that's not a bad thing),
2. have one big network but only use bots for situations where you have a good reason to not use belts (what I imagine most people would do), or
3. still use bots for everything in large networks but require, say, one or even two orders of magnitude more bots (and roboports, i.e. that much more space) to attain throughput competitive with belts.

This even has some "real world" justification; coordination costs for systems of actors tend to increase superlinearly with the number of actors. Not that that should be a significant factor... but it's aesthetically appealing.

[psychogears]

Can't say I'm a fan of the Splitter tweak coming up in the next patch. One can already build a similarly-functioning solution to the problem which the new splitter would address using circuits. I would think that a more powerful building block would trivialize the circuit building game.

[Vader]

I understand your point, and it is legitimate. The splitter ability is great and that is the right direction!
Buff the belts utility:

• Fix the compression
  Any perfect balancer above 4 lane is unbuildable by the 99.9% of the playerbase
  Give us a 3 or 3+ way splitter or some other way so we could make sensible lane groups other than just 4.

And please don't nerf the bots.

[Yinan]

Can't say I'm a fan of the Splitter tweak coming up in the next patch. One can already build a similarly-functioning solution to the problem which the new splitter would address using circuits. I would think that a more powerful building block would trivialize the circuit building game.

He did exactly adress that in the text...

[AutomationIsFun]

About splitter functions: In my opinion it is OP for the early to mid game. If you make only higher tiers of splitters do this im okay with that.
About staked belts: I think it i altogether a wierd idea. I don't think how it'll work neatly and intuitively.
Wanna make bets better - start with making compression easy.

[Bertus]

In this FFF you explore all the things you could do to make bets better. How about leaving belts as they are and adding a third transportation mechanism that is related to belts?

I am thinking of a new entity that teleports a set number of items per second over a set distance (with an entry and an exit). This teleporter can be fed by an inserter or maybe can be loaded directly by attaching a belt. You can have research to enable it, etc.

This would probably not be too difficult to make as "undergroundies" (underground belts) already do a kind of teleporting in practice.

You can think of having some restrictions to these teleporters like allow them only in certain directions (but better than underground belts, so maybe allow diagonal directions of teleporting) or something else.

So I am thinking teleporters that tie into belts that are better than bots (because bots still take time to travel so teleporting could be faster).

Let me know what you think.

Cheers!

[motox]

Just leave the bots alone. They are the solution to the problem, not the problem. The problem is throughput of belts. The only solution to that is speed or stacking for the belts. Make a super express lane. That can turn 4 lane express belt into 1 That's covered. Would imagine that would help with ups also. Or stacking just research it. Leave the same graphics just change recipes. 6 ore equals 1 plate. But each plate equals 6 plates in the machines. The only question is What to do with items already created before the research was completed.

[Sonik-HSC]

Hello... Well, probably is better you dont touch ín logistic bots... your talk something about change the tech tree ! Just see trought my eyes... If you change something about logistic speed or cargo in bots you will put an CURSE on every player that use this feature....

This is what hapens literaly !!!1

""" When a player request at long range for a lot of items to build, the players will have time during the complete requested time to go on bathroom and then go to the kitchen to take a snack! and then they go to the computer screen and see the requested items is almost complete! """

The system to serve logistc players will be flushed in toilet !!! Sorry but is True because you change the system!!! Just tink in that! ((( Time to complete requested items for player ))).



Now for the splitters one question! The splitters will divide for the two belts is content, When 1 output belt is full they will seend all the items for the second exit belt? For example im talking about bus system ( iron plate, Copper plates )?

Don´t forget this game is extremly fun because of infinite capabilites of buildind, its suposed to add features and not remove them!!!!

[tazdu29]

I'm a great belt user (nothing is more reliable than belts for turret's ammo delivery, in case of power failure ). That's why upgrading the belts seems, to me, an awesome idea ! Still, I consider the bots complementary: it's way easier to put a few provider chests, roboports, and requester chests around mining sites, or use robots for low-count items than need to be moved at the other side of the factory, where long runs of belts are just insane.

Anyways, a small belt improvement would be nice, as I find the T3 belt system still.. missing something ? That's why I absolutely looove Kovarex's flter splitter idea ! It'd be such a great addition ! As kovarex said, filter inserters aren't fast enough. But, in the meantime, why not re-thinking the whole inserters behavior ? Here are some idea that came in my mind (sometimes after reading some other posts, I have to say). So here is what I came up with :

• Different tier inserters : Why not having two types of inserters (normal, long-handed), each one with two tiers (normal and fast speed), maybe three (programmable inserter), and a "module slot" ?
• Inserter's module slot : This single slot will make any inserter (normal or long-handed) a filter or stack inserter, by adding modules (like the speed, efficiency and productivity ones).
• Programmable inserter : I saw this idea in a previous postOnce upgraded to T3, the inserter could be programmed so it can do 90° movements !

Also, to go with V453000's idea of using barrels/pellets seems fine, but the stacks seems better. It can't be carried by bots, and goes along with the ideas I provided above : a "stack" inserter is meant to make "stacks", right ? I agree it leads to problems like rendering icons, or to "what happens when belt breaks ?". Can't you use a part of the item's texture, drawn under, to make a pile effect ? Let's say a 2 or 3 items stack corresponds to, e.g, 5 or 10 items, respectively. For the second problem, why don't you make the "stack" an entity ? It stays a stack unless a stack inserter un-stacks it, or the player picks it up.

Glad you readed until here !

To the devs : whatever you choice could be, your game will still be awesome to my eyes (unless you remove something reaaally critical, like coal ), so keep going and do what seems, to you, to be the best.

[Caine]

About splitter functions: In my opinion it is OP for the early to mid game. If you make only higher tiers of splitters do this im okay with that.

First time I read it I thought it only applied to blue splitters, but that is actually not explicitly mentioned.

[madeof_tin]

This last week I have reflected on the Bots Vs Belts and I appreciate the Devs taking the time to consider this. After reading the post about having a research that upgrades belts I had an idea that may be even simpler.

Add a research that allows Stack Inserters to place Stacks on Belts.

Key points that would make this work effectively.

Only Stack Inserters can place a stack on a belt

• Stack size is decided by the limit placed on the Stack Inserter(this being decided by the user gives them control) simplifying working with Stacks on belts and compressing stacks.
• Normal Inserters would not be able to place onto existing stacks, only next to open spaces on the belts. Normal inserters can take from a stack.
• Stacks would work on any speed belt once researched.

Stacks would work on any speed of belt once researched.

• solves the problems of stacks un-stacking if moved to an "unstackable" belt.
• Doesn't break any builds that already exist on your map.
• Doesn't change interactions that already exist in game.

Visually differentiate stacks and single items in one consistent way between all items.

This could be done with a "pallet" sprite that goes under any sprite that is tagged as a stack. Stacks are as big as the user expects them to be so they only really need to know the difference between a stacked and non stacked item. When you hover over a square it can tell you the number of items in a stack in the "more info" window.


This is a really rough sketch, but it gets the point across. These would have pallet sprites under them.


Target the balance to be the best for throughput at endgame.

The test belt build that kovarax posted performed at 9.6k throughput. If you kept stack size max at being 12 than that jumps to 115.2k a minute. That is more than 7 times greater than bot based throughput. There exists some balance where bots can be as koverax envisions. Using the research cost to gate the implementation, changing the stack size to target some X times better then Bot throughput, and whatever Bot nerfs that complement.

Thoughts on why this would be a good idea.

• It fits naturally with how one thinks a stack inserter would work if you have no factorio experience. My first thought was that a stack inserter would place a stack on a belt. I then had to learn that stack inserters only insert stacks if you are inserting into a chest.
• The idea of "pallets of things" is universal. Most have experienced a forklift lifting a pallet of a stack of something.
• The endgame becomes a choice of "I can do a build with bots as the easy way with sacrificed output", or "I can get better throughput if I introduced fully stacked belts somewhere."

Outstanding Questions
A stack inserter could pull a stack off of a belt and then grab more from another stack or base item if the stack inserter size was larger then the stack it picked up. I don't know if it would be a good idea for a stack inserter to be able to place on top of a stack up to its stack size limit. Having this or limiting it could be helpful for hurtful depending on how you look at it.

*edit
Was pointed out on twitch that one issue is that stack inserters inserting from a factory or furnace place one item at a time. A fix for this would be box you can check for "wait until full stack to place".

[Cipri]

Loving the new splitter. One thing that's not directly clear from the UI though; Are these /belt/ based, or /side/ based. Perhaps adding the word 'belt' in there somewhere would make it easier for new players to grasp it right away.

[earthmonkey0]

I love using belt as opposed to bot dues to the lost of complexity, which is the reason I love factorio. If we want to ensure that bots remain useful I agree we should add some late game novel belt tools like the splitter change. One way to even the playing ground be that bots have a durability based on how man recharges they go through, after this durability is lost they need to be "refurbished" which can cost 1 red circuit and some copper wire. Also lets increase the cost of logistic and construction bots to include 10x battery. I think by making them more expensive there will still be bot based parts of the base but it would be unlikely to be used for everything.

[nakran]

I didn't reply in the last FFF. In fact I was just waiting to see if I could think of something to provide my 2cents.

On the «Bots vs. Belts aftermath» of Twinsen:

I'm a bit surprised about some of the reactions of the last FFF because, at least for me, it was clear that the bots would stay. I mean, who would remove them from the game at this point?
I think that some people need to put themselves in the shoes of the others before saying anything.

On the «Bots vs Belts aftermath» of Kovarex

Its true that after setting up the bots you have like a «strong spell» that you can use but I think that the costs are in a different dimension.
Just from the example provided with the express belts its clear that you need an incredible amount of bots (and that's also a lot of resources).
I would prefer the belt over the bot because is cheaper, easy to set up and it does its job.
Setting up the bots in this situation requires lots of resources and power and quite frankly it looks bad compared to belts.

In paper the bots are overpowered, so what?
Belts and bots are two different systems with different mechanics and different limitations. Both can carry items around and do it well.
In terms of cost the belts win and you can lay them down fast and don't need electricity.
In terms of throughput the bots win, the reason is that you can have an incredible amount of it and they work well in relatively short distances it cannot go long distances without recharging, it costs more resources to set it up, etc. It also gives you simpler factory designs.
Two systems, same purpose, different limitations, pros and cons.

On the «Belt throughput improvements» of V453000

From the list of seven options I only see a few that could work out and I'm not quite sure either. Maybe the problem requires a new option for transporting items with different characteristics than the belt so instead of trying to force a solution maybe the solution is to not touch the belt itself.

I wouldn't mind having a belt transporting containers full of items really (I assume the container will occupy the two belt lanes). The container management will be part of setting it up.
I would limit it making that the inserter wouldn't be able to transfer the containers from the belt and use an assembler machine to do the loading/unloading process connecting a belt directly into the assembler machine.

If we want to go further we could make a new entity to be a «plastic tube» that would be able to transport containers (or a new type of container) through it at incredible speeds (greater than the trains).
Limitations:
- Can only go straight
- Cannot have underground versions (so they block paths)
- Need an assembler machine at each end (which sends/receives the container)
- The assembler can «route» the container to another tube connected to it or can load it through a belt (directly) or unload it to a belt (directly with full compression) (assembler 1 can compress to yellow belt, assembler 2 to fast belt and assembler 3 to express belt)
- The assembler must be supplied with the container through an inserter (the sender) and the receiver must take care of the container too. (and the bots could get the empty containers and put them back into the sender container of containers so it can be reused)

On the «Belt buff» of Kovarex

Awesome, now I feel more confident that I can try to do belt mixing. It simplifies some designs that I would rather maintain but I think that the change is really good.
Could it be possible to configure the splitter through the circuit network?
So you can configure when you can make those priorities and supply a list of items to be filtered?

You know, asking is free so... just giving ideas

[dgw]

On the one hand, splitters gaining the ability to prioritize sides and filter items on their own is exciting and makes sense given the (admittedly assumed) in-universe internal mechanics that make them function (not the actual code mechanics).

But I can't help but feel a little frustrated, again, that this came on the heels of fluid wagons losing their GUI. Partly, that feature was removed to avoid maintaining the code and GUI related to it:

We won't have to keep the code alive, we won't have to update the UI of it (in the upcoming GUI update) and fix the bugs related to it.

The fluid wagon capacity nerf, I can't argue with—a train with 75k fluid wagons takes forever to consume at anything less than megabase scale. But the nature of "never realizing what you have until you don't have it" means I keep seeing opportunities to use the now-removed feature of splitting fluid wagons into sections now that I know it's gone.