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

[Engimage]

Concerning stacking: I think as discussed it's an excessively clunky mechanic, and that there is a less clunky, more intuitive way to achieve the same goals.

Namingly:
https://mods.factorio.com/mods/twanvl/pallets
It works exactly like barrels, but for items instead of fluids. Make bots incapable of carrying pallets, and this would be pretty much good to go.

Pallets in this particular mod do require pallets themselves as a separate item to actually pack items and they do have an empty pallet as a side result which you need to transport back like the barrels do.
This is too overcomplicated and requires double the transport lines (1 forward 1 backward) which is just too complex to actually benefit from it.
Thats why people propose different ideas which do not require transporting additional materials so that pallets are naturally created by stack inserters or other devices

[ZlovreD]

Another two ways to make using logistic robots more complex (balanced?) at mid/late game:

#1 Weight/Complexitivity restriction for logistic robots.
Let's assume what robots is a stupid worker what can't handle with heavy or complex parts. In another words - they can move only common/simple parts (ores, ingots, basic intermediate products) and restricted to work with hi-edn and/or complex parts (science packs, rocket parts, items from recipes with more than 2 ingredients and etc.)
It's can be implemented as additional value in items prototype (let's call it "weight") and default value must be setted at 5, for example. Those items what must be allowed by default get this value at 1 (ores, ingots); another ones, which a little bit heavier at 2; those which more complex but yet allowed - at 3; and some extra items - at 4. All other - at 5 (manualy or by default if this option is not setted).
Then add researchable technology to upgrade robots strength/brains which rise their allowments to operate from 1 to 4 (+1 per tech lvl)
As additional restriction - set to all kind of pallets, compressed stacks and similar "weight" to 5 by default.

#2 Filtered/Programmable logistic robots.
All logistic robots can't operate w/o direct order or plane of work. But in this case, to make this work properly we need to add possibility to gives names to all entities in game (which buildable by players) and new roboport (ui) to setup robots.
Then we could make work plans for robots what they must do (like for trains):
> Get 10 iron ores from [Mine]
> Unload and get 5 ingots at [Smelter]
> Unload at [Factory]
So each robot will be restricted to their own work plan.

#2.5 Combine both.

[rldml]

It sounds like you guys want to decide what I think is the most fun way to play the game
etc.

Oh boy, here we go again. I'm not quite sure HOW you managed to read that much into the dev's intent and turn it so negative so quickly.

Well, they do write stuff like: "We believe that belts are more fun, but we are guiding the player towards a less fun style of play." and "If a new player looks at a random Twitch stream, Youtube video, or Imgur album of a megabase, everything he sees now is a train network connecting a bunch of segregated robot production cells, which is visually repetitive, and compared to belt bases, visually less interesting.".

I don't see the point where the devs tell you, which type of gameplay you have to prefer because of fun. They just give their opinion how the game should work to make it more fun for everyone.

Based on what the devs determined in the last FFF, bots are twice at effectiveness with throughput in comparation to belts and have many other advantages. Trains have their niche where they work best: you can use belts and/or robots to transport goods over great distances too, but with growing distance trains are simply the superior solution. We need such an niche for belts too. The tech gap is not such a niche and the greater costs for robots are`nt either.

Greetings Ronny

disclaimer: i`m using bots and belts and trains, i am not a bot hater.

[EvanT]

Other than limiting bots per box (un-/loading) count there is no change that will not be counter able by adding more bots/roboports.

Belts have a limited throughput per tile defined by inserter and belt speed.
In a way bots are limited by roboport/recharging slot count (at some point the bot consumes more energy flying to/from a recharge point than doing work.). But compared to belts they are not even in the same playing field.

Energy consumption is just another easy scaling factor.

Someone mentioned that bots are perfect for short range transportation. Trains are perfect for long range mass transport. In the late game there is just no need for midrange transportation.

The bot-factory designs are centred on setups which use max 5 roboport ranges with train stations in the middle. For belts being able to shine there they have to be a lot better than now.

tl;dr: bots are waaay better at distribution and balancing throughput than belts but belts are way more fun to figure out.
E.g I utilize on demand ore trains. Consuming Stations deactivate if they are satisfied and producing stations deactivate if there in not at least one trainload. So I have no Train dedicated to two station but to two groups of stations. To prohibit trains from stopping mid track (both groups have no active station) I have a midway station whichs's stations will never deactivate so the trains have a place to wait. This station has heavy throughput since every piece of ore is going through it. The mining sided trains are 1-3-1 and the smelting sided ones are 2-4-0(I have multiple smelting points since green production goes from ore to product at one place.) So I have two onloading and one loading station and connect both sides by belt. The mess needed to deal with balancing and distribution would boil down to having provider and requester chests and a line of roboports in-between the stations with bots. But figuring out the belt layout was a lot of fun.

The mentioned new features to belts will help but there is a long way ahead if belts should be a viable option.

[vipm23]

This is too overcomplicated and requires double the transport lines (1 forward 1 backward) which is just too complex to actually benefit from it.

Hardly. It's still a 25x increase in throughput even if you ship back pallets. (50 items per pallet, so 50x items moved, divided by two because you need a belt to ship pallets back.)
Note that this increase also applies to train loading/unloading without affecting the train's capacity, which would let belt-based train unloaders actually exceed bot-based unloaders with regards to turn-around time.

It's an inherently quick and intuitive way to represent 'stacking'. It works exactly the same as barrels so new players can draw parallels. And it only requires 1 + 2n recipes to be added (Pallet, plus pallet load/unload recipes- this can be automated so mods stay compatible, just like the barreling recipes) to be implemented.

Compare this with programming an entirely new mechanic just to add stacking behavior, in a fashion that doesn't readily, intuitively follow from or really interact with existing mechanics

[csdt]

I've read the last few pages of this thread and several things seem to come back regularly.
So let me sum the ideas and bring some extra stuff.

TL;DR

4 possibilities (that could be combined):
Nerf bots: it should be an intuitive mechanic like traffic jams (for example)
make bots funnier: it could require a virtual network a bit like trains
make belts easier and funnier: simple tasks made intuitive and simple like belt compressing
increase belt throughput: pallets/crates/packs seem good but need to be thought properly to be intuitive

Logistic bots

First of all, if bots are nerfed, they shouldn't be nerfed with arbitrary limitations like: they cannot transport such items, or they are slower.
The item limitation will just kill the main purpose of logistic bots: transport rare items to machines with complex recipes.
Making them slower: people will just add more of them.
In the two cases, it's no funnier nor more interesting.

A change to bots should not change the way to use them for low throughput transportation but only for high throughput transportation.
There are some possibilities for that, but the only one I saw is basically reduce the number of bots that can take stuff from chests at the same time (chest cooldown?).
Some researches could increase the number of bots on the same chest at the same time.
This idea is sensible and will not affect low throughput transportation, but will also need to redesign only the chests part of the network to achieve high throughput. So people will just create bigger storage/providing areas.

In my previous post, I proposed the following idea:
Bots cannot be at the same place as other bots. This way, if one tries to create a high bandwidth transportation with them, it will create traffic jams and the throughput will be much lower than with current mechanics.
The way to achieve higher throughput would be to have physically larger paths to smooth the traffic.
What I like with this idea is that it is very intuitive and doesn't affect low throughput designs while requiring an overall redesign to achieve high throughput.
It would also be possible to have some researches to increase the density of the bots.

Another idea I just had would be to completely change the way logistic bots work by manually setting up virtual bot lines like the trains.
For this to work, one should not need to specify the path of every single bot, but create some predefined paths that bots could take.
However, this would not solve the high throughput problem, but will make bots harder, but also (hopefully) funnier to set it up.
This would also disable the natural load balancing of bots.

Transport belts

I really think the main problem with belts is not really their throughput, but their usability. It's often quite tedious to work with them.

The first thing to consider in this respect is that something that is thought simple and intuitive should be simple and intuitive like belt compressing.
Belt compressing should be easily doable with both inserters and belt merging.
However, having huge builtin belt balancers doesn't fit: the concept is not simple and many people will think that it's hard to setup.
We should not have super powerful machines that do whatever we want. We should keep machines simple, while improving interactions between those machines.
In this respect, I don't really like the filter option of the new splitter and would prefer to a dedicated belt for that (or another simple way to do it).

An idea that come often is increasing the throughput of the belts (for end-game bases at least).
It should also be intuitive and not arbitrary.
Stacking belts look good (concept and visual), but as far as I understand, they would be very hard to implement efficiently.
Moreover, it becomes not really easy to visualize the fullness of a belt.

Another suggested ideas would be to have pallets/crates/packs.
It seems to be a good idea, but we should probably avoid duplicating every single item in the game.
Moreover, the naive idea to need an assembling machine to pack/unpack those is terrible and not practical.

So we would need and simple (and small) way to pack/unpack.
I would recommend a packing belt: takes any input, gather a bunch of them, and outputs a packed version. One could restrict that items should identical to be packed together.
Same in reverse with unpacking belt.
To avoid duplication of game items, when a player takes those packed items, they get directly the unpacked items.
One restriction could be that regular inserters cannot handles packed items and leave them on the belt.
In that case, we would want packing/unpacking inserters: they work exactly as stack inserters, but are able to take packed items from belts, and always put packed items on belts.
Of course, this could be an option of the stack inserter to avoid creating a new inserter.
Note that, with those inserters, we don't need packing/unpacking belts, but they would be handy.

With all that, the concept of pallets/crates/packs exists only at the belt level (and inserters) and does not affect the rest of the game (like player inventory, chests, trains, machines, craft).
Moreover, once it's explained to the player, the mechanic becomes really easy to use and to understand. AFAIU, It would also be fairly easy to implement just by having an extra flag attached to the items on the belt.
Visually, it could be a crate with one of the item visible on top. With that, it would be easy to visualize if the belt is full or not.


What do you think of these ideas, both pro-belt and pro-bots?

[Koub]

So, by all accounts the bot charging nerfs are a reality now

Source ?

[Ringkeeper]

I personally think, the FFF 224 and 225 where interesting to read and actually are worth to think about.

The problem with such "emotional rollercoaster" in posts are... people (some) don't read , TLDR or only selective read the post... otherwise they would have read that it is just a "what if" scenario and not a plan.
And you can always discuss (in a normal manner) about "what if" . Yeah, maybe at the end there is an outcome where all parties say "hey, that sounds good, lets do it".

But then again, there are some "dedicated fans" that rather should be treated for their game addiction then able to post..... but hey, they pay the salary so.. meh... /ignore

[anarcobra]

One thing that suddenly stikes me is that belts in factorio are not really used as belts in real factories.
Of course to some extent they are, but for example something like a splitter serves no purpose in real world factories. Instead you would have some device that sends items left or right depending on some factor. Belt merging would additionally be done by some device that determines whether to pass items from one belt or the other depending on certain factors. And lastly, in real factories certain operations (manufacturing steps) are done on the belt. Look at a car factory for instance. The chassis sits on a conveyor of some description and machines work on it as the body movies along the factory. There is an actual game that uses this as well: http://store.steampowered.com/app/59137 ... tion_Line/

If there was some mechanic to create for example circuits or engines, or whatever item on the belt directly you would see more belts used. It would also more closely match real life. No one uses belts to transport batteries from the battery factory to the phone factory (they also don't use bots obviously, but imho that seems more realistic now that amazon and other companies are starting to use them). In factorio there are really only 2 transport modes: short and long distance. So it's no wonder that belts and robots are fighting. I strongly believe that if you nerf bots enough to make belts viable you will just get the opposite of what you have now, where people will be "forced" to use belts because bots just don't have any advantage (other than player delivery which can be solved with longer reach).

All of that said, maybe it's time that factorio, and mega base builders just admit that we have reached the limits of megabases and that is okay. Give chests a hard limit of bots/s that can access them, or real pathfinding, or whatever and move on to a different challenge from building massive bases. For me personally it feels like I went through the 5 stages of grief and I am now at acceptance. I now look at bots and understand that however much fun they are, the fact that they allow megabases purely because they do not have any kind of interaction while in the air is kind of silly, and possibly just a side effect of a decision that was made at some point just to have something working *now* that could be fixed later. It is an early access game after all. Well, this is later and here we are.

[3trip]

What about changing recipies? Just Make iron, copper and other high use resources use less individual pieces on the belt.

For example, say you quadruple the usefulness of each piece of iron in all recipies. now factories will produce 2 gears for each piece of iron given Instead of needing two iron plates to make one gear. This means you can have the same throughout, with 1/4 the belt usage for iron, or four times as many factories on the same belt.
You will also want to increase the recipe for refining them by the same amount at well.


Best part of this is that Any recipe buff will buff the perceived throughput of that resource equally, trains, belts, inserters and bots, equally.

[Ringkeeper]

What about changing recipies? Just Make iron, copper and other high use resources use less individual pieces on the belt.
*snip*
Best part of this is that Any recipe buff will buff the perceived throughput of that resource equally, trains, belts, inserters and bots, equally.

Which wouldn't change anything on the problem, rather the opposite. Belts would profit way less from this change then bots. So bots would be even more usefull.

[mathturtle]

Sorry everyone haven't read more than half of the replies... apologies if this is a repeat.

Twinsen, I sort of get where you are coming from, but your solution so far doesn't seem to fix the real problem.

So it seems to me that the real problem is that belts and logibots are trying to fill the same niche. Sort distance high throughput transport of items. Trains have the niche of long distance high throughput transport (try your throughput thing again over 1000 meters and add a train in to see this. It will smash even the bots throughput.) But it seems to me that especially with beaconed builds, belts just don't have high enough throughput to compete in the short distance high throughput area. Inserters grabbing from a requester are immediately picking up a full stack where even a blue belt they take time to gather their stack and their throughput isn't as high. And there are several beaconed builds where inserter throughput is almost the bottleneck (green circuits and blue circuits). I think you need to figure out what the niches of logibots and belts should be and make changes from there. Having them compete for the same niche and nerfing bots to make them equal or less then belts will just make people mad (and then you'll have the bot people saying that now the game is forcing them to use belts).

Consider an outpost with level 150 mining productivity and see if you can improve belts to be usable there (because even big belt bases I have seen use bot outposts). With bots it can supply several 2-4-2 or bigger trains, but I don't think you'll get that throughput with belts right now since one speeded miner on each side saturates a blue belt.

Thoughts on splitter changes:
I think your changes are neat, but you are fixing the wrong problem. The old black magic splitter sorters are dead, hooray! Priority splitters are nice. It was impossible to do this with the circuit network and get it right so adding support to vanilla is the right call. But I hope it is gated behind technology (with an appropriate tutorial when the tech is researched). Having it from the beginning is too powerful. Filter splitters... well you just obsoleted filter inserters for everything but train unloading of mixed trains. I hope you wanted that. They'll be nice for mixed outposts if belts ever have enough throughput to be used in outposts with high mining productivity.

Take your time to get this right, but I'm waiting to start my 0.16 megabase until this issue is resolved one way or another. I don't see the point of working on it when new mechanics will potentially break the bots or obsolete the belts I use soon (also compression would be nice if I use belts).

[csdt]

So it seems to me that the real problem is that belts and logibots are trying to fill the same niche. Sort distance high throughput transport of items.

That's why I suggested few posts ago to nerf only the high throughput part the bot networks.
Bots are much easier to use and set up, so they are really good to bring many different types. So if the throughput is, somehow, limited, then belts and bots will not have the same purpose:
- Bots for low throughput transportation.
- Belts for high throughput close/middle-range transportation.
- Trains for high throughput long range transportation.

[cvkurt]

Concerning stacking: I think as discussed it's an excessively clunky mechanic, and that there is a less clunky, more intuitive way to achieve the same goals.

Namingly:
https://mods.factorio.com/mods/twanvl/pallets
It works exactly like barrels, but for items instead of fluids. Make bots incapable of carrying pallets, and this would be pretty much good to go.

The problem is that it works exactly like barreling... which is tedious (as noted in the FFF). A better alternative, IMO, is auto create/destroy the empties... and have mk3 assemblers handle the pack/unpack automatically. This could be done without any new recipes, so the crafting menus don't get bloated.

(I discuss this more a page or two earlier in this thread.)

[feitingen]

Blue belts quickly become too inefficient in large megabases, I feel like I'm forced to turn to bots at one point.

Bots use a lot of electricity, which makes it fun to try to match the new demand for power, so what about some sort of powered belt? Either a belt "beacon" which speeds up belts in a limited range, or a higher tier belt which needs to be powered to be useful.

Then trains would still be needed for long distance since it will be presumeably too expensive/cumbersome to make long powered belt runs, and bots would no longer be too overpowering unless you pour research into bot speed.

Anyways, I always found it strange that belts doesn't require any power.

[Brambor]

On Steam there still is '[/list]' at the end of one paragraph (title Belt buff imidiately folows after that)
taking the html out of steam and taking into consideration only the FFF: it is the 16806th -> 16813th character
It is the only

Code: Select all

[/list]

on the page.

[csdt]

The problem is that it works exactly like barreling... which is tedious (as noted in the FFF). A better alternative, IMO, is auto create/destroy the empties... and have mk3 assemblers handle the pack/unpack automatically. This could be done without any new recipes, so the crafting menus don't get bloated.

Like I previously said few posts ago, I would even go further by making those pallets/crates/packs a reality only for belts and inserters.

Regular inserters cannot handle at all packed items, and "packing" or stack inserters (with option) can handle packed items and put packed on belts.
And those special inserters put unpacked items in containers and machines.
The player will get unpacked items when they pick up packed items on belts.

And for bots, traffic jams could be an interesting and intuitive idea.

[cvkurt]

Regular inserters cannot handle at all packed items, and "packing" or stack inserters (with option) can handle packed items and put packed on belts.
And those special inserters put unpacked items in containers and machines.
The player will get unpacked items when they pick up packed items on belts.

I'd be happy with your alternative.

[garath]

Remove beacons...
In an earlier post, someone remarked that bots allow more beacons than you can fit with belts. Simple solution: remove beacons. But let’s say you want to keep beacons for some reason. What solution would allow maximum beacons if you chose to use belts instead of bots?

[Lubricus]

Another two ways to make using logistic robots more complex (balanced?) at mid/late game:

#1 Weight/Complexitivity restriction for logistic robots.
Let's assume what robots is a stupid worker what can't handle with heavy or complex parts. In another words - they can move only common/simple parts (ores, ingots, basic intermediate products) and restricted to work with hi-edn and/or complex parts (science packs, rocket parts, items from recipes with more than 2 ingredients and etc.)
It's can be implemented as additional value in items prototype (let's call it "weight") and default value must be setted at 5, for example. Those items what must be allowed by default get this value at 1 (ores, ingots); another ones, which a little bit heavier at 2; those which more complex but yet allowed - at 3; and some extra items - at 4. All other - at 5 (manualy or by default if this option is not setted).
Then add researchable technology to upgrade robots strength/brains which rise their allowments to operate from 1 to 4 (+1 per tech lvl)
As additional restriction - set to all kind of pallets, compressed stacks and similar "weight" to 5 by default.

#2 Filtered/Programmable logistic robots.
All logistic robots can't operate w/o direct order or plane of work. But in this case, to make this work properly we need to add possibility to gives names to all entities in game (which buildable by players) and new roboport (ui) to setup robots.
Then we could make work plans for robots what they must do (like for trains):
> Get 10 iron ores from [Mine]
> Unload and get 5 ingots at [Smelter]
> Unload at [Factory]
So each robot will be restricted to their own work plan.

#2.5 Combine both.

#1 I think Bot's should be good at things like deliver locomotive to the player so you don't need to run around the base so much. The problem are that they easily can solve the puzzle's like how to deliver circuits to the high-tech science (Although without careful planing they are worse than belts at doing it, the throughput is in reality usually poor and it cost lots of energy, science and resources to set up)
#2 With the ability to determine the flight-path's -the bots would be much stronger and it would be tedious to set up instead of a fun puzzle with limitation to overcome.