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

Regular reports on Factorio development.
ASDFGerte
Burner Inserter
Burner Inserter
Posts: 14
Joined: Wed Dec 13, 2017 9:34 pm
Contact:

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

Post by ASDFGerte »

Packed items like pallets/containers
  • Just adds another thing to do for every single recipe, mostly just adding tediousness. Basically mandatory barrels if you wanted to increase throughput.
  • ...
TL;DR; Bulk, in essence, is just relevant when the items are not inside some inventory.

Stacking should mostly be done as a convenience for the player, not by the player themselves. Every item should be stack-able and consumers should be able to consume/output bulk. Inserting bulk and single of the same item-type is no issue - the assembler would always unpack inputs into its internal slots (when you open the assembler, it would always be a number of single items). As an example, an assembler making inserters would get a bulk of iron plates (for this post, ten iron plates), ten single gearwheels and a bulk of green circuits. It would produce a bulk of inserters, taking ten times as long as the normal recipe. Optionally, make a setting what to output or add a new "bulk-assembler" that waits for enough input to produce a bulk output. Otherwise, just take bulk as soon as one input is bulk. Note that even mixed belts of bulk and single are behaving quite well. Importantly, less items should mean more UPS!

Sure, there would be a way to change a bulk to single and back, but it would rarely be used (and there could be hotkeys for doing it manually, and a general "pack"/"unpack" recipe for assemblers). A large throughput factory would just do bulk all the way. There is another nice benefit: on the current version, megabases with higher mining productivity have drills fill express belts insanely fast. People use bots even for mining, as creating patterns that output and use enough belts for larger patches is tedious. Mining drills should instead be able to output bulk ore at a tenth of the speed. Furnaces would then take bulk and smelt that, and after more steps, bulk of science would finally be taken by science labs.

Most importantly, note that
[...] bulk objects [...] cannot be flown by robots.
see this post, it also includes other interesting ideas. This does not nerf robots but increases throughput by belt considerably. Using bots to carry low volume still works as before. Intuitively, a flying robot cannot carry a bulk of steel beams.

In all typical cases, factories do not produce or consume a single of something. As soon as the time for an assembler to be supplied with ten of an item type is irrelevant, bulk will be the option. This is the case even early in the game and for a vast majority of all items produced (think science, who cares if it is ready a few seconds later).

Balance could be solved by making bulk conversion a late game research or by other methods, e.g. rebalancing early game throughputs (yellow/red belt speeds, etc).

This highlights the issue that item price is generally too low and quantity too high. One rarely needs single of anything - not even for personal use and especially not for production. A megabase would rarely ever use single items, in essence just multiplying item price by ten and reducing quantity equally. Note that when stack sizes would always be multiples of bulk, even placing entities from bulk would be no issue, the bulk slot would just automatically be converted to single (potentially needing some time, but no explicit "unpack" command by the user would be needed).

________________________________

Unrelated addition requests (sorted, first being the most important):
  • Solar power MK2. Placing solar power is the issue, not making it. There are bases with two million solar panels - two §"$%"§$ million! With nuclear being as UPS hungry as it is, there is no alternative to solar sadly.
  • Make nuclear less UPS hungry. It takes fuel cells in, outputs electricity, and is almost never looked at after placement. There is no reason for it to use so much cpu. A related point is that uranium spawns too much - or fuel cells, nuclear fuel and nukes are just super cheap! Capitalizing on the latter, in addition to barely anyone ever building single reactor setups, make all components of nuclear reactors twice as expensive, increase the fuel cell cost by ten (produce one fuel cell instead of ten), and increase heat/steam/power production/consumption by four. Potentially reduce neighbor bonus. This makes reactor setups below four a viable option, reduces cpu used by nuclear by factor four and finally gives me a way to get rid of the uranium on our map - i set it to the minimum where i could notice any uranium spawn, and cannot possibly use it all. A single patch, 2 million ore, was enough for the entire game. It was harvested before researching considerable amounts of mining productivity. As another example, i want to remove an uranium field containing a few millions, but doing so would give me around half a million u-235 (taking mining productivity into consideration). I cannot possibly use that.
  • Add bigger, larger chests. Storages use hundreds of storage chests, which should be replaced by bigger versions (why not a 4x4 tile size chest that can hold considerably more than 16 chests?)
  • Add a way to load your personal items (roboport, exoskeleton, nightvision, battery, ...) from your base's electrical network
  • Add a way to plant trees or generally decoratives that prevent the map from becoming flat and grey (also a good way to use wood! Just make wood be usable to plant trees, this also gives the game option to plant forests between you and biters. Possibly biters need to more efficiently remove forests when they are used as walls)
giustizieri25
Burner Inserter
Burner Inserter
Posts: 14
Joined: Fri Jun 24, 2016 10:53 am
Contact:

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

Post by giustizieri25 »

My idea in favour of belts is:
- a new infinite research that increases belts speed by a small amount, and makes the recipe for belts a little more expensive for each research completed

The research should apply to express belts (not a new specific type of belt, so that blueprints work across different situations).
For example, if the standard recipe for express belt is:
1 express belt = 10 iron gear wheel + 1 fast transport belt + 20 lubricant

Than this recipe becomes 10% more expensive each time
1 express belt (level 1) = 11 iron gear wheel + 1 fast transport belt + 22 lubricant
1 express belt (level 2) = 12 iron gear wheel + 1 fast transport belt + 24 lubricant
...
1 express belt (level 15) = 100 iron gear wheel + 7 fast transport belt + 80 lubricant

This way the game becomes an infinite quest for making more science, but also more transport belts. Also the insane amount of lubricant required should help in expanding in search for oil or coal.
dgw
Fast Inserter
Fast Inserter
Posts: 197
Joined: Tue Apr 12, 2016 7:06 pm
Contact:

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

Post by dgw »

giustizieri25 wrote:My idea in favour of belts is:
- a new infinite research that increases belts speed by a small amount, and makes the recipe for belts a little more expensive for each research completed

The research should apply to express belts (not a new specific type of belt, so that blueprints work across different situations).
For example, if the standard recipe for express belt is:
1 express belt = 10 iron gear wheel + 1 fast transport belt + 20 lubricant

Than this recipe becomes 10% more expensive each time
1 express belt (level 1) = 11 iron gear wheel + 1 fast transport belt + 22 lubricant
1 express belt (level 2) = 12 iron gear wheel + 1 fast transport belt + 24 lubricant
...
1 express belt (level 15) = 100 iron gear wheel + 7 fast transport belt + 80 lubricant

This way the game becomes an infinite quest for making more science, but also more transport belts. Also the insane amount of lubricant required should help in expanding in search for oil or coal.
Making the recipe more expensive just means players will rush to build a ton of express belt up front to save materials, and hold off on the research. Changing the recipe doesn't affect already built items/entities.
User avatar
cpy
Filter Inserter
Filter Inserter
Posts: 839
Joined: Thu Jul 31, 2014 5:34 am
Contact:

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

Post by cpy »

Stacks on belts? Count me in! Just make some boxes with item icon on it and we're good man!
Caine
Fast Inserter
Fast Inserter
Posts: 213
Joined: Sun Dec 17, 2017 1:46 pm
Contact:

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

Post by Caine »

deer_buster wrote:I would like to suggest that a splitter could also be setup to take two belts of different items and output 1 or 2 belts of items with those 2 items each taking up a single lane of each belt, or perhaps a lane filter (much like the lane filter on the creative mod's matter creator)
You mean this effect?
BeltMerge2.png
BeltMerge2.png (110.41 KiB) Viewed 8019 times
Why would you want to do this with a single splitter?
Last edited by Caine on Sat Jan 13, 2018 7:53 am, edited 1 time in total.
Sniperfuchs
Burner Inserter
Burner Inserter
Posts: 5
Joined: Fri Dec 29, 2017 9:44 pm
Contact:

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

Post by Sniperfuchs »

My biggest gripe with nerfing bots in terms of numbers is, as many others said, it won't do much since just more bots and ports would be used.
I like the idea you mention at the end a lot more, where you want to make each logistics option strong in their own way. I was always under the impression that this triangle of logistics worked like this:
Trains for long distance, high throughput. Belts more mid range constant throughput. Bots for very low ranged but very high throughput. Also, as a "bonus" bots are great to supplement a factory (or the player) in terms of being able to move small amounts of items where they are needed (like in the mid-game where you struggle to find room for building rarely-in-use items. That's where plopping down 2 chests and a roboport seems completely fine.

However, I think the way this triangle works right now, there will never be a reason to NOT use bots or looking at it from the other side, to actually use belts, even if you buffed them. My own thoughts about this would be something like making bots use a lot more energy or, to accentuate the use for low range, nerf standard bots to 1 cargo size and make a different kind of bot with 3 or 4 which use so much power, that they are only good for very low range, high throughput. Or things like making bots constantly be charged while in a certain radius of their home port (you wouldn't be able to stack them on top of each others zone) and when they leave that, they are a lot slower. That would once again solve some problems with the mid-range bots, where belts should be the optimal solution, not bots. However, just throwing random ideas around, not saying any of this doesn't have its own problems. But in one way or another, I think the range should be the limiting factor of bots to not overlap as much with belts.

Another big offender imo is how trains are currently used (or allowed to use I should say). Trains are meant for long range transport, I assume that is the developer's intention. However, current bot megabases use trains for literally anything, even if it's a distance of 100-200 tiles. Again, a distance where I think belts should be the premium option. The thing that even allows this, however, are not trains but actually the fuel. The additional vehicle acceleration and the break force upgrades makes even the longest trains insanely fast to enter and leave a station. Train tracks are 2 tiles wide. You can increase the throughput of trains by just adding wagons and trains, so you never get wider, you just get longer, whereas belt arrays grow in size rapidly while providing a pathetic amount of throughput comparatively, so even at low distances it is still better to use trains in many cases which just shouldn't be the case.
My proposal (which is in no way without flaws and should be debated): Make fuel increase max speed only, no acceleration and make trains accelerate slightly faster baseline so they don't feel incredibly sluggish with 6+ wagons. That way, long ore trains from outposts would not take forever to get to your smelter but they are not used as a replacement for belts.

Then and only then I think belts should be touched with buffs or anything. The reason I say this is that I feel like the current way to play the game optimally simply doesn't allow belts to be strong either way; the other two options overlap just so heavily with them for various reasons, that there will never be a good solution until you give each of them the appropriate niche they were intended to be good at.
vipm23
Long Handed Inserter
Long Handed Inserter
Posts: 62
Joined: Fri Aug 12, 2016 4:05 pm
Contact:

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

Post by vipm23 »

Dranzer wrote:
Regarding bot nerfs, an actual chest access cooldown may be worth a lot. An inserter can only access a chest so quickly, and you can only ever have four (well technically eight) inserters accessing a chest at a time. It doesn't have to be crippling, but it might go a long way towards making bots a situation for "Tricky configurations" - Hell, that might even be a reason to buff logistics bots in other respects - if they have to compete with inserters for speed, then they could maintain their use as a flexibility tool whilst leaving major hauling to belts, and then you could reduce their tech/production cost, maybe even make roboports smaller. That way trains -> belts -> bots could be about trading throughput for flexibility. Maybe. It's just a thought.
This. Part of the problem is that an infinite number of bots can be in any one tile, accessing the same chest, at the same time, so throughput is wholly dependent on number of bots. Chests having a cooldown between each time a bot can access it would throttle throughput from chest to chest, while not otherwise penalizing the player for having lots of bots.
User avatar
Drury
Filter Inserter
Filter Inserter
Posts: 794
Joined: Tue Mar 25, 2014 8:01 pm
Contact:

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

Post by Drury »

WIZ4 wrote:We hope, we are waiting. Stack-belt
Stack-belt.gif
Okay now show me how that looks on a vertical belt.
GenBOOM
Long Handed Inserter
Long Handed Inserter
Posts: 95
Joined: Tue May 16, 2017 11:39 pm
Contact:

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

Post by GenBOOM »

WIZ4 wrote:We hope, we are waiting. Stack-belt
Stack-belt.gif
+1
User avatar
irbork
Fast Inserter
Fast Inserter
Posts: 246
Joined: Fri Jul 04, 2014 1:17 pm
Contact:

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

Post by irbork »

No! Lets not touch bots whats so ever. Klonan belt compressor is excellent, lets implement this entity.
exlesnick
Manual Inserter
Manual Inserter
Posts: 1
Joined: Thu Jul 07, 2016 8:05 am
Contact:

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

Post by exlesnick »

It's risky step, but i'm do it!
I will wrote my comment in russian language, because my writing experience in English is too small for all of this :oops: , I hope this will be read by people who know how to do Russian ;)
WARNING RUSSIAN LANGUAGE AHEAD
Last edited by Koub on Sat Jan 13, 2018 9:03 am, edited 1 time in total.
Reason: Fixed spoiler
TiMatic
Inserter
Inserter
Posts: 28
Joined: Sat Jan 06, 2018 12:09 am
Contact:

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

Post by TiMatic »

V453000 wrote:New tier of belt which would be able to stack items.
  • If only the stack belt is allowed to have stacks, then whenever items move to a single tile of a normal belt, all of the items would un-stack, which woulbe be quite annoying.
  • ...
When items move from a tier 3 belt to a tier 1 belt this would be similar to a move of 3 stacked items to 3 single items. But to get a good look for that, the stacked belt could have a special graphics at the end, like a belt with a circuit connection.
V453000 wrote:
  • ...
  • If only inserters would be able to create the stacks, it would get really annoying to attempt making a fully compressed, fully stacked belt even if inserters auto-compressed the belt.
Currently only splitters can create a fully compressed belt. Why should this be different for stacked belts?
2 uncompressd stacked belts + 1 splitter = 1 compressed stacked belt.

I don't see any real problem here => so you could add it to the game.
Last edited by TiMatic on Sat Jan 13, 2018 12:11 am, edited 3 times in total.
PaszaVonPomiot
Long Handed Inserter
Long Handed Inserter
Posts: 77
Joined: Fri Dec 29, 2017 1:50 pm
Contact:

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

Post by PaszaVonPomiot »

Slightly reduce number of items bot can pick up, slightly reduce the speed, slightly increase charging time, reduce the number of bots per roboport and there you go you should be set without much drama.

Splitter looks great :)
yekkusu
Manual Inserter
Manual Inserter
Posts: 4
Joined: Sat Jan 06, 2018 5:51 pm
Contact:

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

Post by yekkusu »

Well, I think this:
If you guys want to debuff robots, PLEASE do it in the next update 0.17 essentially if the debuff is: Bots can't carry heavy stuff or big stuff. The first reason for that is: I would simply have to undo my entire base, that's not helpfull. xD

Some good debufs is: Consume more energy, takes more time to charge, and can't travel long distances because it consume energy faster, that's of course: For logistics bots, personal robots can operate differently than the rest of the base, because at some point, it's extremelly boring to repeat some layouts over, and over again, bot's are helpfull.

About some other things that makes bots too strong: Make some of those things researcheable at an end-game state with space science over than 50k, so we as players can still achieve that but in a harder way: It will make robots less atractive to some people, and something we can do with megabases.

If you're going to make any debuff just don't do one that forces me to delete my actual save XD I know it's experimental, but I would NEVER try to create a megabase based on belts AND bots, if I knew bot's would suffer such a debuff that will make me redo everything xD.

Belts: I just think belts can have more options, or a new tier, faster: Then just create a new tier of inserter to work with this belt, make it extremelly difficult to achieve this type of belt if needed, but I don't think this is possible.

I know you guys can't just do everything we want, the game HAS to have a vision, and if you guys listen to us every time, the game will be a mess.
But before doing any big change, please continue asking for megabases with Belts, with bots and other things and check things out first then.

I love belts, I love bots and I DO think that bot's are amazing.

AND: For the linked worlds, you guys can make a new gameplay Type Without bots, just like RailWorld or DeathWorld, or make the bot tier of research be reseted everytime you go to another planet. So the player will need to re-research the bots again, but if they go back to the last world they will have acess to their bots.

Or, I don't know, make the bots in the "new" world being less helpfull? Nah.

Good job guys. Continue with your hard work.
Meister_Knobi
Manual Inserter
Manual Inserter
Posts: 4
Joined: Thu Dec 21, 2017 9:46 pm
Contact:

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

Post by Meister_Knobi »

Mimos wrote:
Meister_Knobi wrote:Im sorry when i miss something similar, but my idea is based on something, for what i do not know an other word for then "hitbox".

As for an example: Trains have a hitbox, so they cant pass each other when they are on the same rail. Nothing new so far, but what if robots would get a hitbox too? This would limit Robots at a Point where adding just more Robots wouldt increase througtput. The Size of this hitbox could be used as a new way to balance the Robots.
For an example in an example: a robot have a hitbox of 1x1 titles, a movement speed of 11,25 tiles/s (Dobble as blue belt, dont know how mutch it is right now) and can carry 3 items at the same time means that you could limit one lane of robots (Point to Point) to 30 items/s. This could be interpreted as an item density for Robots (5,333 items/tile vs blue belt with 7,111 items/tile).

i dont know if my calculations are right but numbers indicate the potential balancing.

What do you think?
That would probably sadly come at an enormous UPS cost. Which would as a side effect discourage using bots, which I think is a bad idea even under the assumption that nerfing bots was a good idea.
Sure it would be an UPS loss, but Robots are more UPS efficient so in the end it could just equalize. Not every robot needs to calculate its own path. Think of imaginary rails in the sky, witch the Robots follow until the Requester Chest is saturatet.
For Balancing it could be that only Loaded robots have a hitbox and empty dosent. And iron could only colliede with iron, copper with copper and so on. There are some ways to tweak.

edit:
I cant find it any more, but someone mentioned somthink like to reduce the amount of robots per area. my suggestion to this is to limit the ammount of robots controled by a roboport, maybe about 100? Then it would be nessery to block the placement of other roboports in an 30 or 20 tile radius or that the ammount of robots per 50x50 square do not stack.
Last edited by Meister_Knobi on Fri Jan 12, 2018 11:56 pm, edited 1 time in total.
BluetoothThePirate
Burner Inserter
Burner Inserter
Posts: 11
Joined: Sun Jun 08, 2014 8:18 pm
Contact:

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

Post by BluetoothThePirate »

I wrote this elsewhere (not on the forums, on a youtube comment) but I in general prefer the idea of making more transport options because the bots are currently filling niches that could be split among multiple different transport options. I often experiment with building a train line down the middle of my base to distribute materials. A station partway down the bus drops off iron and copper to reload the drained belt. Unfortunately it comes with an incredibly high risk of death. If we had an option to build a train in a trench or overhead other such 3D structures it'd make it safer to use trains in this way, but I can understand the need to keep the game flat.

What about a slight redesign to stack inserters to make them actual stack inserters? They gather up materials on one side but then drop them on a belt as a pile, and at the other end pick up a pile and deal it out on another belt in a line? No need for circulating materials like a pallet or a box, they'd work as current when going between train cars, containers and machines, and whether they pile things up or split them apart could be a UI setting or managed by circuit conditions? A few stack inserters could concentrate a full belt down to a sparsely-populated belt full of piles, which could then be unified together via splitters and run down a bus, and then either have each processing line consume the stacks as-is or have a few stack inserters to fan the stacks back out like a card dealer. You could also include some code in the stack inserter behavior and the assembly machines that they will wait until they have enough output to grab a whole stack before they pick it up.

You wouldn't need to build stacking behavior into the mining drills, just strategically position some stack inserters in the field to concentrate the belts down. If you want a number to use for how many items can be in a pile, set it to cap at a tenth or a twentieth of the item's storage stack size, so no piles of artillery shells or oil barrels but you could have five ore per space, ten plates or twenty circuits.
golfmiketango
Filter Inserter
Filter Inserter
Posts: 549
Joined: Fri Jan 29, 2016 2:48 am
Contact:

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

Post by golfmiketango »

One way to debuff bots would be to make them explodey again. In the fusion bots mod (which actually buffs bots even further, making them incredibly OP), robots do not go gently into that good night, but explode violently, as if a small bomb had been detonated, leading to chain reactions, and hilarious, dangerous results when biters and bots start interacting with each other. I know from experience, this is a fun way to debuff them, you can't help but laugh at some of these incidents, even if they are frustrating on a certain level.
m44v
Fast Inserter
Fast Inserter
Posts: 131
Joined: Sun May 15, 2016 8:55 pm
Contact:

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

Post by m44v »

Koub wrote: Now back to topic. I really think just comparing peak throughput of optimal bot network with 4 blue belts is looking at only part of the picture.
- What's the investment to create both setups in terms of resources ?
- Can we also have a look at the power consumtion of both setups ?
That wasn't peak throughput, that was constant throughput for one hour. Regarding resources and power, does it matter? Late game most of the resources go into science and modules, and power is cheap by the time you unlock logistic chests. Whenever bots are more expensive than belts is inconsequential.
- Can we make the same experiment with double the length ?
That would depend if by same experiment you mean keeping the roboports saturated (which was a condition for the test) or the same number of bots.
Last edited by m44v on Fri Jan 12, 2018 11:56 pm, edited 1 time in total.
Engimage
Smart Inserter
Smart Inserter
Posts: 1069
Joined: Wed Jun 29, 2016 10:02 am
Contact:

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

Post by Engimage »

madeof_tin wrote: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.

Image
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.
These are almost exactly my thoughts
Stack behaves like any other item on the belt and is considered as one for splitters.
However - imo only stack inserters should pick stacks from belt and only if the whole stack can fit into destination.
You also should not be able to put anything on top of already placed items on belts be it single item or a stack. So stack on the belt will never exeed stack inserter capacity.
Also stack inserters lose the ability to scoop multiple items from belt and loaders are introduced instead. The later will also help transitioning from stacked belts to unstacked oned through a container.

As for the bot nerfs I still find chest rate limit the most effective way to fix situation. I also think bot capacity is also something to be addressed.
However if you opt into increasing bot charge speed I would prefer construction bots to avoid this nerf especially personal ones which are in the worst state now as they are almost unusable early game due to lack of personal power supply. You should definitely buff PSP or make a base power grid connector to make use of batteries etc.
Last edited by Engimage on Sat Jan 13, 2018 12:01 am, edited 2 times in total.
Mestiff
Burner Inserter
Burner Inserter
Posts: 5
Joined: Sat Jan 06, 2018 11:35 pm
Contact:

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

Post by Mestiff »

Zool wrote:One way to nerf bots would be, to give a bot a „loading and unloading time“ on a chest of lets say 1s, and only after he is finished loading, the next bot can come ... that way, the throughput of chests can be limited easily, and more bots wouldn‘t increase the throughput of a simple chest to chest transport.

In a situation like that, bots would still be superior for low-throuput, but very special items, but at the same time belts can shine for throughput.
I think it's a good idea, having more bots will give less benefits for each additional bots because they'll queue to unload. It can be a formula like: 0.25s + 0.05s x items to load/unload, this way it still valuable to research the upgrade carry limit for bots even if the number of items carried have an impact in the loading/unloading time.
A single chest could have max 10 items/s with max research even if there's thousands of bots, making belts the best choice for high throughtput and bots the best choice for several small tasks with constant slow/med troughtput. Adding the fact that bots would have to go back to roboports to charge if they wait for too long....
I love bots and i think this idea isn't really a nerf and will make bots still valuable for their ressources cost, research investments and material restrictions (roboports, logistic chests).
Last edited by Mestiff on Sat Jan 13, 2018 12:33 am, edited 1 time in total.
Locked

Return to “News”