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

[Rhamphoryncus]

I like it. I'll be able to sanely build a large bus without pulling my hair out over trying to make a balancer/tap/priority splitter that's actually reliable. Just need to back it up with a hard line over splitter decompression bugs and similar weirdness.

Not sure about bot nerfing. I agree with the sentiment but I don't think anything you can do will have an effect besides "build a few more roboports? Okay." Then again if only logistic bots get that nerf and construction bots don't we'd have a defacto buff to construction bot charging. I'd be happy with that.

[Kewlhotrod]

I do see how you guys are between a rock and a hard place with this decision, but saying you're going to remove a well used feature of your game was obviously going to garner some negative attention don't play coy

btw nobody enjoys using bots so obviously just make bot bases more fun, explore the ideas of an rts branch of the game, thats pretty much where the idea of bots came from ..

[admo]

While considering splitter improvements perhaps variable lane-width splitters could become a thing. Though it would probably over-simplify belt-balancer designs.

[OrigamiGuru]

I would want a technology to turn belts into stack belts, with a repeatable research to increase the max stack size. For the visual solution, I think stacks should have a number in the corner similar to how items look in the player's inventory.

[SeigneurAo]

Thank you so much for this FFF, one of the bests so far.
Answers most of the accusations/reproaches, as well as many suggestions.

I'll only repost a very interesting idea I've read in the gazillion-posts flame war the last FFF started :
Why not reduce the chests "concurrent access"? Like, allowing the chests to be accessed by bots once every second, half second, idk the correct delay, but you get the point.
This would reduce raw throughput while leaving other areas intact.

Just my 2 cents.

[Caine]

Twinsen certainly trolled the community with success. Well played

I like the new splitter, it looks interesting and it certainly makes more sense than the old one.
The old one still allowed some esoteric use cases that seem hard to do with this one. Hopefully the new filter can be circuit controlled.

[JCav]

Figuratively, bots are 'infinitely" better than belts.

Such a fact is all that should be necessary to facilitate change. As sad as I'll be to redo things with belts instead of bots, it cannot be argued that they aren't flat-out better.

Based on such, I support a reasonable change to bring belts back in-line with bot throughput.

[marginoferror]

I'm strongly in favor of a bot nerf. I think the game is vastly more fun when played primarily with belts, and I'd like bots to be as a low-throughput convenience over medium distances or a powerful way to cram complex movement with decent throughput into small distances.

[tarou00]

What about adding a limit on the number of bots that can load/unload a specific container at the same time?
It will add contention points, like belts do.

[Ecu]

https://www.factorio.com/blog/post/fff-225

In response to this, I would have a suggestion. As nerfing bots too heavily would likely invoke a highly negative response from the community, perhaps implementing new content that is belt focused would be a means to keep them involved. My current thought would be to create a structure (or multiple structures) akin to those in the mod Factorissimo 2. Bots could then be denied within these structures. Additionally, if belts (for items) and pipes (for liquids/gas) are the only connection for resource input/output to said structures, it creates some incentive to use belts between them. These could potentially assist with UPS optimization of belts as well as they could be very self-contained and contained in their own world effectively.

Just a thought of a different way to tackle a balance between belts and bots...and a fun way to organize your factories.

[3trip]

Can't you just solve the issue with a general belt speed research, general inserter speed research?



Also someone mentioned fixing effect transmitters to allow belt usage in high throughput designs, just stop multiple towers effects from overlapping/stacking, and buff their slots to compensate, that way you have more room for belts as everything isn't surrounded by transmitters.

[Masterfox]

All I ask if you do choose to debuff something you don't like - *please* ensure we can reverse that decision via the mod API to restore the game to how a large part of the community thinks it should be without having to sacrifice things like game performance.

That is the main point. As long as you only choose to change things modders can overwrite easily, it is fine. There will be some Mega-Mod that just reverts all your changes and have a config to decide which one to keep. That's all right. It is how Classical Combat emerged after Minecraft 1.8: The majority hated a decision of the devs, so it was reverted. And when it is possible to do the same with Factorio, it is great. If not... well, see your active players shrink by 60%, many with negative reviews. Not sure that is your best interest though.

In the end: Do what you like. But live with the consequences.

[Jarin]

A very minor "interaction time" penalty on bots dropping items in chests might help? Instead of infinite bots interacting simultaneously, limit it by game update tick or something. So it doesn't have to be a drastic reduction, just moving bots back down closer to max belt throughput.

[Waity5]

i think belt buttons would be a good idea, so you could have a strait belt, then when a batch of items gets to the end, it allows all the inserters to take from the belt
if any of the people who are reading this are redstoners, this is a way of showing it

in factorio, the commparator would be the belt button

[Yehn]

Love the splitter buff.

A very minor "interaction time" penalty on bots dropping items in chests might help? Instead of infinite bots interacting simultaneously, limit it by game update tick or something. So it doesn't have to be a drastic reduction, just moving bots back down closer to max belt throughput.

This would just put us right back to "nothing can keep up with highly beaconed setups".

[cpw]

I find belts to be tedious. I massively enjoyed building my "bot cell" system for my "megabase", solving the problems of moving items quickly enough to get to ~2k sci/min was quite the challenge. It was so much fun that every subsequent restart has seen me get bored of the fiddling around with belts in the early game, so I've never gotten to even blue science, let alone bots again. I think that you need to counterbalance this discussion quite a bit with the fact that a large minority do really enjoy bot based play. It's not the zeitgeist on this forum, that's for certain, which is why I rarely contribute here, but things already feel drastically nerfed since the 15 change to logistics system research. You have a difficult challenge ahead - it feels like there's two games in development here, and you're focusing on one, and ignoring/actively nerfing the other. Ultimately it's your choice, but I'm probably just going to go back to playing not-factorio for now.

[Zeblote]

While considering splitter improvements perhaps variable lane-width splitters could become a thing. Though it would probably over-simplify belt-balancer designs.

That'd be nice. Having everyone stamp down the same set of unnecessary belt balancing blueprints surely isn't fun or interesting, and neither is trying to come up with one...

[quyxkh]

I think the splitter buff goes a long way on the right track. I think (restoring) per-item alternation is also necessary: just as implementing priority splitters with circuitry is simply ungodly awkward/inefficient, so is evenly distributing input items across output belts. It'd take eight fully-upgraded stack inserters and a chest and two of the 16.16 splitters and probably some circuitry per belt just to maintain item ratios on the outputs.

I don't think it's possible to simultaneously maintain item ratios and throughput and lane occupancy with a single splitter design. The usual example is splitting a red belt to two yellow belts: any alternating sequence in a lane that sometimes doubles up an item will stall: one lane alternating iron-copper-iron-copper-iron-copper-iron-copper could produce two full-speed iron-copper/copper-iron lanes but the instant one of the items doubles up item alternation would force the next item pair onto the same output belt (and lane).

So, how about making (edit: advanced splitters that give) the choice of what to sacrifice configurable? If an item shows up on an input lane and item alternation would select an output lane that's not ready yet, wait, or try the other output belt first, or try the other output lane first.

[Tinyboss]

I have three pieces of feedback:

1. The new splitter changes--hooray!

2. If you're going to increase charging times, or do bot debuffs in general, please only do it to logistic bots and not construction bots.

3. I noticed that beacon layouts came up a couple of times. After the last FFF I made a Reddit post [1] suggesting a change to the way beacons work, hoping to introduce more flexibility in endgame layouts and specifically to make belts and potentially loaders usable. Any possibility of revisiting beacons so that the most optimal layout is not endless alternating rows of beacons and assemblers?

[1] https://www.reddit.com/r/factorio/comme ... uce_tiers/

[AgentPaper]

I think that you guys are over-thinking the bot vs belt thing too much. I know it's appealing as a designer to strike the "perfect balance", and have bots and belts co-exist with their own niche, but I suspect that you will find that that compromise will end up just making both belts and bots end up feeling less interesting. Belts will become too powerful, too easy to use, to the point that much of the game becomes trivial (the splitter buff comes to mind). And in return, bots will become so weak and useless that they are very un-satisfying to use.

Instead, I suggest a much more direct approach. Instead of trying to balance bots vs belts, attack the problem directly by restricting the number of active bots that you can have at any given time. For example, at the start you might be limited to 100 bots total flying at one time. This could represent the "CPU capacity" of whatever system is managing all the bots and the logistics network as a whole. As you research tech, that number would grow, but not by enough to enable a pure-bot factory, at least not one of the scale we're seeing now.

This change would mean that bots can remain strictly better than belts, which I think they need to be in order for them to be fun to use. It would also turn the "belts vs bots" problem into an interesting optimization problem for the player. On the surface, the simple answer is "use bots for as much as you can", but with the hard limit on how many bots can be in the air, now you have to weigh each use case carefully. Is it really worth using the limited resources of your logistics network to have bots supply this factory? Or would you be better off laying down a belt-line, using up valuable floor space?