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

[cvkurt]

As I noted in round one, nothing about nerfing bots will make belts more fun. Enhancements which make building and managing belt-based factories will make belts more fun.

While I enjoy toying with circuits networks to implement prioritizing splitter over the years, I welcome new prioritizing/filtering splitter. Too bad new players won't be able to experience the same joy with the old splitters, but overall, it's as win. There are plenty of other areas to toy with circuit networks... including possibly the new splitters. I hope priority and filter settings are circuit enabled (at least circuit controllable).

In belt buffs, I think it is important to note that with belts, one typically has more entities in existence than with bots... and this can have significant impact on UPS/FPS. Faster belts or stacked belts means more entities, which I think won't be good for megabases.

I think the best idea is actually "packed items" or "palleting" but with improvements to avoid the tediousness and complexity of managing them... and crafting menu hell. Palleting can significantly increase belt throughput while likely reducing UPS/FPS issues by reducing the number of entities the game has to deal with at any one time. But following the barreling model, as it seems suggested in the FFF (and as implemented in mods such as Universal Palleting) is less than ideal.

I think a better approach (most, if not all, has been suggested elsewhere in this thread) is have mk3 machines always support pallet inputs and have an option to either produce regular output or pallet output... but have no empty pallet entity. Empty pallets would be created/destroyed as needed. In addition to this, a 1x1 device for palleting/unpalleting would be needed... which could also act/be a belt buffer device.

To keep machine buffering and recipes basically as they are, the input pallet's contents would be immediately unpacked and stored in machines buffers and the pallet size for all entities would be the same (say 10). This avoids having to deal separately with pallet inputs from regular inputs within the machine. On the output side, if palleting is enabled, the system awaits production of a pallet's worth before kicking out a full pallet.

What if the stack size is smaller than the pallet size (say 10). For entities used in science production, there's only one which has a smaller size than 10, namely satellites. I think it reasonable to just say that items which have a smaller stack size than the pallet size cannot be palleted. Of course, one could increase the stack size of items if palleting of them is desired.

This sort of palleting, aside from increased throughput with decreased UPS/FPS issues, is crafting menu friendly. There's only new separately craftable entity type, the 1x1 palleting/unpalleting belt buffer device.

[meganothing]

Why are you rushing to 1.0 so much anyway? There is so much that could still be added to the game, but proposed bot nerf is like cutting corners in hardcore mode.

Probably Factorio is a game where the conrete has dryed on 99% of the game and all they can do is add less and less useful stuff, optimize and bugfix. Adding gets more difficult if you can't change underlying structures, optimizing/bug fixing is mostly done before release anyway. Wube (in a way) pampered their players (too much?) and painted themselves into a corner. I'll explain:

Non-Early-Access development of games often is very dynamic. Features get written, tested and changed or even deleted all the time. There is no negative connotation to the word "nerf", there are no holy cows developers can't touch.

Early-Access development is different. You have a community helping you but you also have to keep it happy. Wube seems, compared to other EA companies, especially intent on keeping the community happy but that hinders them to change already established features or violate backwards compatibility. At least one other Early-Access developer I know allows major releases to break backwards compatibility and often uses that to overhaul the game so much that you get the impression to play a different game after updating.

That is probably why they want to finish the game. If they do an extension of the game or Factorio2 or a completely different game they are free to change anything again.

[SHiRKiT]

Early-Access development is different. You have a community helping you but you also have to keep it happy. Wube seems, compared to other EA companies, especially intent on keeping the community happy but that hinders them to change already established features or violate backwards compatibility. At least one other Early-Access developer I know allows major releases to break backwards compatibility and often uses that to overhaul the game so much that you get the impression to play a different game after updating.

That is probably why they want to finish the game. If they do an extension of the game or Factorio2 or a completely different game they are free to change anything again.

That's a lousy and bad comparison. Wow, just wow at such a bad comment about Wube.

[meganothing]

That's a lousy and bad comparison. Wow, just wow at such a bad comment about Wube.

Huh, why?

[Lubricus]

What about let requester chests only be able to request one type of items. Would that only make them more annoying or making the bot logistics slightly more challenging?

[Ciizel]

It simply adjusts the number of bots that can be connected to the box.

There is a limit on the number of loads and unloads everywhere except bots

The fact that the bot is so powerful now is that it can ignore this and allow dozens or hundreds of bots to connect with just one box. If you adjust the maximum number of connections, you can naturally use large capacity cargo belts and small amounts of bots

Of course, there are ways of using bots by increasing the number of boxes, but it is also necessary to use a belt to create a load and unload system (ex: like a train station)

By increasing the number of bots that can be connected to the box through research, the bots will not be powerful from the beginning and become very powerful in the second half.

[Xecutor]

Hisashiburi-dana ssilk sama

My interests shifted a bit and I have a new team at work, which does much more interesting stuff (React, Typescript, Redux)...
But sometimes I still take time to read a bit in the forums.

Funny thing, I'm also dealing with react+typescript+redux.

So bots being 2 to 5 times more effective makes sense and actually points to them being underpowered. Couple this with the fact all those roboports alone would have paid for all the blue belts you used in the example, take how many bots you had times 3.4 to get how many blue belts all those bots could have been made into and you start to see that bots are not as overpowered or cheaty as your test makes them out to be. If bots are going to be no better than belts, then the research costs and the costs of bots & roboports needs to be cut down to match. They are overpriced for what they do.

This! Also, belts do not have any operating cost. Zero. They are working completely for free. While the network of roboports in the moderately complicated base consumes very noticeable amount of power.

The problem cannot be solved with more costs! When you are about to have bots researched you have in general more than enough resources (well, depends much on play-style, but I would say in most cases it is no problem to have 1000 instead of 100 robots. Which shows that this statement is more or less true).

And yet, logic behind comparison in FFF is broken. The fact, that at some point you do not care about resources required to build and energy required to maintain 1000 bots is completely different thing that have nothing to do with bots and belts.

Now that I think about it... When bots become really powerful, fight with aliens have no challenge. It's just a routine. As well as creation and connection of new outposts. In order to reduce amount of routine actions people have to use productivity modules as much as possible to increase gain - which require compact designs, and the same compact designs reduce amount of required space, and hence reduce amount of boring routine actions! Bingo! Nothing can beat bots at compactness!

Belts builds are not compact by their nature. And that's where something compact, but but not as cheaty as bots is required - pneumatic pipes (or something alike)!
The way to transport multiple products in the same space and at high speed. This also might, if properly designed and implemented, reduce CPU usage on gigabases.

[ratchetfreak]

one thing I've noticed is that the roboport performs 3 distinct functions:

1. define the area of the network
2. store and deploy robots
3. provide recharge points

IF you split them up in separate entities (maybe with tiers for a few of them) you could make robots more of a puzzle than the current spam-roboports-until-things-are-fast-again method.

[bobucles]

World bot limits
Network bot limits
Scaling bot costs
Long distance penalties
Bot Upkeep
etc.

Absolutely disgusting. Arbitrary rules like this don't help and only make the situation worse. The modular bot station is designed to minimize the number of bots that get used and minimize the distance they have to travel, maximizing each bot's potential. A mega super base might have over 30K bots in a monolothic death blob, while a module station is fully functional with only 500 or so in a small network. All this does is force players to DEFINITELY use module bases, to get the most out of the limited bots at their disposal.

As far as pushing game styles AWAY from the modular bot station, absolutely none of these will work.

[Lubricus]

one thing I've noticed is that the roboport performs 3 distinct functions:

1. define the area of the network
2. store and deploy robots
3. provide recharge points

IF you split them up in separate entities (maybe with tiers for a few of them) you could make robots more of a puzzle than the current spam-roboports-until-things-are-fast-again method.

It's done in Bob's mod. It's ends up being even a smaller puzzle. Put up the network area and then just spam charge pads when and where needed. You can also divide up the logistic network in a more powerful way and put charge pads close to the borders where you can have bot bridges and whoops there is no need for trains any longer.
With the vanilla system to big networks is just ineffective mess that takes a lot of UPS and bot bridges can only be build at the edges far away from the roboports (bad flight path and recharging) so the only way to have efficient high throughput between the logistic networks is by trains.

[Pure Ownage]

I think the splitter control should be a late game research (near bots). Might be annoying to reconfigure the base after though.

Maybe bots can cause a large power drain when recharging, as well as taking long to recharge. That way bot only bases have massive power usage spikes as a disadvantage. Might be easy to overcome with multiple reactors though.

I find most of my bots go towards personal logistics, takes about 200 bots (half of all my bots) to resupply me quickly after building a big outpost. Maybe some way to buff personal logistics that doesn't make factory logistics OP? Drop off items before recharging if the recharge threshold has been reached but the player is within a certain radius.

Another idea is to have a slow AOE charging station (roboports won't charge anymore) which slowly charges bots passing through a certain range. This will require chargers on all long distance paths, might make bot bases a little less OP. Out of power bots will crawl back to the nearest station and sit within the radius until they are half way charged.

Bots are easy because they require little overhead then next to no running costs. Some way to make the running cost of 200+ for all bases difficult to achieve might fix this.

In general I use bots to provide small throughput on items with one use, as running belts for them seems wasteful.

[dog80]

I think the splitter control should be a late game research (near bots). Might be annoying to reconfigure the base after though.

Maybe bots can cause a large power drain when recharging, as well as taking long to recharge. That way bot only bases have massive power usage spikes as a disadvantage. Might be easy to overcome with multiple reactors though.

I find most of my bots go towards personal logistics, takes about 200 bots (half of all my bots) to resupply me quickly after building a big outpost. Maybe some way to buff personal logistics that doesn't make factory logistics OP? Drop off items before recharging if the recharge threshold has been reached but the player is within a certain radius.

Another idea is to have a slow AOE charging station (roboports won't charge anymore) which slowly charges bots passing through a certain range. This will require chargers on all long distance paths, might make bot bases a little less OP. Out of power bots will crawl back to the nearest station and sit within the radius until they are half way charged.

Bots are easy because they require little overhead then next to no running costs. Some way to make the running cost of 200+ for all bases difficult to achieve might fix this.

In general I use bots to provide small throughput on items with one use, as running belts for them seems wasteful.

What this made me think of in my current playthrough once i reach nuclear (i go from steam->nuclear) and i got the kovarex enrichment process running, its like i am in energy heaven. This seems a bit overpowered to me. I have like 3-5k normal uranium and my closest uranium patch is still full with plenty of uranium. Maybe make uranium patches in general smaller a bit, or much - or it was just a lucky map gen. I play standard. greetings

[bobucles]

I think the splitter control should be a late game research (near bots). Might be annoying to reconfigure the base after though.

There was a nice idea to give yellow splitters nothing, give red splitters the priority setting, and add the filter setting to blue splitters. Don't forget that early game factorio should still be as simple and open to new players as possible. It would be disastrous to a beginner if every single game feature was unlocked at the beginning of the game. The issues with bots vs. belts don't become relevant until much later on so there's no point adding solutions until the point in the game where they're absolutely needed.

[Godmave]

Late to the party and too lazy too read all 29 pages, but just wanted to throw in my ideas for belt buffs, straight copy from discord:

Godmave - Last Friday at 8:50 PM
In some games there are gold drops. Low drops are a few coins, big drops are bags of gold. The same could be done for items on belts. The problem would be the transition between those states. Like, when you put slow items on a belt and at the end it gets compressed it would turn into a box/pallet of that item, maybe with a little number on it like when you have an itemstack on the cursor
same if you take items of that stack, on a certain point it turns into bits and pieces showing the items again without box

Godmave - Last Friday at 8:53 PM
if you keep it to stacks that are like one square big it should be ok. its just another layer that moves along the belt

Godmave - Last Friday at 8:55 PM
palletes would autosnap to always be spaced the same
so no overdraw can happen
problems would occur with mixed belts. those would be unable to stack in some cases

Godmave - Last Friday at 9:14 PM
to complicate things you could make it so that you have to research first stacking belts and after that stacks for each individual item

Godmave - Last Friday at 9:24 PM
if "item-density-of-an-item" >8 turn them into a stack of that item and block any other item-type of entering that space, or something like that. as long as the stacksize is bigger than 8 the belt-segments works like a movable box. as soon as the itemcount falls below 8 it falls appart into a full compressed beltsegment filled with that item
that would open up another research possibillity that allows stackinserters to move boxes (full stacks, or as full as a box is on that segment) from one belt to another. normal inserts could only move multiple items out of one box still

Godmave - Last Friday at 9:30 PM
to spin that even further you could make the box space researchable, so that at first you only can have like 10 items per box, but research it (infinitely?) to allow one more item per box
that way the belts would scale like bots do atm

[vyktor]

Also one of the most tedious things to do is to upgrade your whole main bus from one tier of belts to the another... adding two tiers of auto-upgraders (so in case of belt weaving you can red->blue; yellow->red) would be huge QOL improvement.

And if you want to make a few people angry make bots slow down in the range of beacon. And make the effect stack...

[TheRaph]

I like the Idea of having underground belts in a underground-layer.

But how to do?

I think the easiest way is to type a hotkey to switch in underground mode.
There - in underground mode - the entire map may be dark brown.
Light structures from above should render as colored rectangles (for orientation), heavy objects (like reactor) should have a basement.

In this area you could put "underground belts" which was made by belt(y,r,b) + stone (for walls and ceiling).
The graphics of that underground belts should be like normal belts but with walls left and right and supporting poles (like in mines).
You may put belts where you want, but not under deep water, buildings with pavements, walls, oil reservoir and non-stone-ores.

Walls should have also a basement (fundament) to prevent worms (new!) from going into your outpost / base.
There should be special worm-save passages to put in walls to archive underground belt passing through walls.

There should be some technique to defend against underground aliens (worms) ... "subterranean unit detected!"
Worms move slowly and the bigger one have to bite trough walls (the smaller one will not go through walls). ... a wall who has been damaged will be indicated in underground AND overground mode so you see where your attackers are.
This will also add a side effect to pavements (like stone and concrete) so small worms will not go through stone, mid size worms go not through concrete and the biggest worms have to be defeated by "underground echo stompers" or what ever

just an Idea ton introduce the underground level and mak it more fun

For short things (where current underground belts are currently used) you may introduce belt-bridges. Just 1 to 4 tiles wide vor early game, before you start to use real underground belt spaghetti.

Just an idea of what may possible ...

The palette / crate thing I like too. There should be 4 by 4 packing stations which packs that crates with stuff. A crate may hold a half Stack of Item "x" and may stack themselves by 10. So you have 5 times more in a stack of crates than in one stack of item "x".
One crate use both lanes of belt (same place as 3x2 Items) and could be grabbed by a stack inserter. To have real benefit it should not be necessary to uncrate them before inserting it in an assembler.

But so far ... good job devs.

[LiWa]

I really like the Death Spell comparison from Baldur's gate with the logistic robots!
---> PLS USE IT

Eg: Make/add high tier late game components that are too big/heavy to be transported by (little flying) logistic robots and instead require ground based belts, trains etc.
This way logistic robots would still be fun and powerful for low/mid game components like plates, gear wheels etc. But for late game components you would require both belts and robots to have an optimal factory.

(This could be combined with the addition of some more complex recipies for rocket parts and other late game constructions. Eg. right now it feels too easy to build rocket parts when you already have production set up for all the different sience packs. It feels like there is a gap for more complex recipies that really require the tier three assembling machine.)

[PanteraSan]

Bots needs a nerf, period. The already said "bot maximmum carry weight" system sounds cool, I think, instead of only scalling down the numbers.
Oh, just thought about a "movable chest" that can buff the belt issue a little.
A new type of machine that creates "moveable by belt chests" or large cargo crates, so you can load it up with many type of itens at once, up to a researchable maximum cap. This cargo crate can only be loaded on a new type of belt.
This way you can avoid the 40+ wide belt bus needed to supply a megabase without bots, and add new functionality to the filter inserter.

[Bauer]

You don't care about resource or energy costs in late game.

What matters is player time, QoL, and UPS. (and maybe foot print)

Hence, nerving or buffing resource or energy costs is useless if not exaggerated up to crippling the game. And nerving player time, QoL, and/or UPS doesn't make any sense (and enrages ppl). Belt UPS has been optimized with 0.16 already. Thanks for that!

That leaves, as some have pointed out already, only buffing belts with respect to QoL and player time. Enough suggestions have been made in this thread.

[Bauer]

I use 8 or 12 wide blue belts at mining outposts. Laying down all the belt sucks ass in vanilla with 100 personal bots at 20 UPS. Thinking about it... I should use bots for it. QoL is what matters here.