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

Regular reports on Factorio development.
Locked
yenz9
Manual Inserter
Manual Inserter
Posts: 1
Joined: Mon Oct 23, 2017 6:17 pm
Contact:

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

Post by yenz9 » Sat Jan 27, 2018 12:51 pm

The Belt Bot challenge:
Eat the cake and still have the cake and also add topping to make it tastier.

In other words:
A slow, fun and logical transition from belts to bots, without reducing the bots maximum capability.
Why: bots makes too much sense in the factorio world to be removed or get to much reduced performance.

How:
1. Reduce the transportation capability for bots when introduced.
2. Increase the performance for late game belt system.
3. With science slowly increase the performance of bots to reach maximum capability after the 1st (or 5th, or 20th) rocket has been launched.

In details:
Bots:
a. Introduce 3 tiers of roboports, either as separate buildings or each capability unlocked by science.
b. Chests and player can only be serviced by closest roboport even if covering areas overlaps.
c. Bots transporting one chest serviced by roboport A to a chest serviced by roboport B travels first to roboport A then by the connecting lines to roboport B before delivering in the receiving chest. Added benefit bots does not get out of energy in the middle of a U shaped roboport coverage.
d. Bots transporting from one chest to another chest both serviced by the same roboport do not need to go to the roboport first.
e. Reduce the amount of robot stacks available in roboports (1stack of ech type at start then increase by one stack for each science.
f. Bots without energy upgrade needs to load it batteries at every roboport it passes.
g. Every energy upgrade adds one roboport step before recharging. Randomness in chosen recharging port needs to be added so not all bots choses the same roboport for recharging.
h. Reduce amount of charging stations in roboport tier 1 and 2 (1 station in tier 1, 2 in tier 2 and 4 in tier 3)
i. Reduce the charging time for bots, start at 1s and is reduced with science.
j. Exit rates for bots from roboports starts a one bot per second and is lowered with science.
k. Add possibility to make one way roboport lanes.

Belt systems
a. Faster inserter to be able to fully saturate one side of a blue belt from one chest. At the moment 3+ fully upgraded stack inserters are needed to saturate a blue belt. I believe 2 fully upgraded inserters for one blue belt should be enough. Maybe a inserter with two arms?

Conclusion:
Bots will be very limited when introduced, they will have an ok capability to transport between chests and player serviced by the same roboport but will have a very limited throughput for longer distances.
Bots can handle U shaped roboport coverage.
Bots only after endgame bases will still be possible.
Bots will travel in lanes and not be all over the map.
Train to chest to belt will be easier with faster inserter.
Buffer chest will be even more valuable.

Zanthra
Fast Inserter
Fast Inserter
Posts: 110
Joined: Fri Mar 25, 2016 8:18 am
Contact:

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

Post by Zanthra » Sun Jan 28, 2018 9:22 am

Has there been any thoughts of better layering of belts? Underground belts are very limited in how much you can do with belt braiding, running two distinct belts on the same path. Perhaps an expensive layered belt could be available, and a layer splitter would be like a current splitter, except it would have a selectable or multiple selectable layers for it to interact with. When initially placed, these layered belts would operate on the default visible layer, and so fast replacing standard belts with the layered belt would be fine. You could then put more of the same item, or another item entirely onto the the extra layers of the belt. This provides a distinct upgrade with associated costs, and allows people to expand main bus systems in a third dimension without finikey braided belts. Naturally a more powerful system would be belt coloring (not related to belt speed colors that exist now) where when placing a belt you select a color for that belt, and that belt would be seperate and distinct, but be allowed to coexist in the same tile as a belt of another color. And there is a possibility of longer underground belts with turns, but then you approach the same 1x1 in 1x1 out that makes robots as op as they are now.

All of these approach the problem that robots are superior because they don't take up the space. There is only so much ground space in any build, and robots avoid the problem by flying over everything. Belt multiplexing I think is the way to make belts competitive with robots.

darth_sneaker
Manual Inserter
Manual Inserter
Posts: 2
Joined: Sat Jul 16, 2016 9:40 am
Contact:

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

Post by darth_sneaker » Mon Jan 29, 2018 8:22 am

I personally like to use logistic network for a few items where i don't need masses i.e. feeding ores that i trashed back into production, feeding assembly machines where i have factory wide only one or a few, where feeding with belts half around the world would be pain in the ass.

Here are my 2 cents, but i did not read the full thread, so i am sorry if i repeat something already told here, but when i do, count this as a +1 for it ;-)

The only overpowerment of bots i see is that they stack infinitely(!) unlike any other thing in the game. You can have only 1 belt on a tile and one below it, but if you want, you can have 5000+ bots unloading into a single chest in one tick (as far as i can judge) . As with any other transportation there should be some senseable limit.

If we had a collusion box around bots, that only applies to bots and make other bots speed down, this would instantly reduce bots to an adjustable limited 'overpowerment' (while creating traffic jam in the air that maybe would be fun to handle if one can setup sort of flying traffic lights and/or priorities for specific bots) while getting closer to real behaviour. Real drones cannot fly directly above each other, if you try, the lower drone will just fall at least significantly down and would likely crash.
But introducing such a limit would not necessarily to be calculated during flight, but maybe only during load/unload which should be much less calculation to process each tick and the code could be simliar to the recharging code of the roboports, where robots need to wait until beeing recharged.
Saying this, a threshold of bots that can un/load per chest and tick would in my opinion do the trick of reducing bots overpowerment while keeping all the balanced improvements. If this limit would start low it would not hinder the early use of this lategame gamechanger, as no one starts with thousands of bots, but with another research increasing this threshold limit, it could be empowered again. If such a limit would be implemented it would raise the use of belts to help unload bots with speed again, creating cargoairport alike setups with multiple chests connected via belts to the destination.

At least having another limit to bots with loading/unloading, that should be research-improvable would remove overpowerment of bots while letting the player choose how to play his game.
As for my opinion the logistic network should be available a bit earlier in the game (not too much) but with such a limit that takes multiple researches to not frustrate the users of powerful botsswarms or those who favor beltless factories, but not everyone who wants to have the logistic network uses them for overpowered mass-transportation.

But in addition this could create a good reason for something like cable cars or a similiar transportation that fills the hole of fast cargo to a specific point/chest just like trains, but with need of another type of road where to drive. i.e. self-driving cars that can only drive on paved path, find their way by themselves like robots, but cannot drive through buildings and of course can create traffic jam just like trains which would be another challenge to master.
This would make it really interesting and it would give the research of automobile a very new direction as an alternative to train which would be fun to handle, plan, manage and decide what to research first while probably (should be) unpractical for transportation to/from far away posts thus not removing the need for trains.
This type of cable cars (or whatever) could be in my opinion a balanced way to achieve the nealry same result like mass-transportation by bots, and provide a balanced replacement without their overpowerment.

/my2cents

darth

thelordodin
Fast Inserter
Fast Inserter
Posts: 114
Joined: Fri Jan 06, 2017 1:54 am
Contact:

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

Post by thelordodin » Mon Jan 29, 2018 2:29 pm

Great idea! As an approximation an averenge number of bots per chank can be used. Or just separating chunks to smaller units.
I.e. when a bot enters a chunk - increment counter on chunk. Than decrement robots' speed in that chunk by averenge of that counter.

olvog
Manual Inserter
Manual Inserter
Posts: 1
Joined: Thu Feb 01, 2018 11:16 am
Contact:

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

Post by olvog » Thu Feb 01, 2018 11:35 am

Okay, so many posts on this topic^^
Ive played this game several month ago with a group of friends. Played the marathon mode and it was very funny. But after bots it became way more easy. Now we discussed how it is possible to nerf the bots without just dropping the flight speed etc.

Our idea was:
Limit the bots for a certain Roboport and than alow those Bots in there just to work in that area no exchange between different Ports. So you can build overlapping Roboports but they dont interact with each other. Every Roboport than gets an inventory system like the Player so that Port can demand differen things which the Bots will deliver from his Area. Smart Inserter than can take stuff out of the port and they can be transported to another Roboport.
This will reduce the swarm of Bots flying through the whole base, and long way distances. The player will create smaller construction hubs with a single Roboport in the middle. All these Hubs can be connected with belts or train. Maybe an awesome circuit network to mix the belts.

Thanks for your attention, bye bye
olvog

User avatar
bobingabout
Smart Inserter
Smart Inserter
Posts: 6832
Joined: Fri May 09, 2014 1:01 pm
Contact:

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

Post by bobingabout » Thu Feb 01, 2018 4:25 pm

olvog wrote:Limit the bots for a certain Roboport and than alow those Bots in there just to work in that area no exchange between different Ports.
Considering my base is about 30 roboports by 30 roboports, and anything within this base can be moved from anywhere else within this base.... This is an unbelievably massive nerf.
Creator of Bob's mods. Expanding your gameplay since version 0.9.8.
I also have a Patreon.

Pascali
Fast Inserter
Fast Inserter
Posts: 138
Joined: Wed Aug 23, 2017 8:24 pm
Contact:

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

Post by Pascali » Thu Feb 01, 2018 5:45 pm

...and an believable important nerv.

bobucles
Smart Inserter
Smart Inserter
Posts: 1588
Joined: Wed Jun 10, 2015 10:37 pm
Contact:

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

Post by bobucles » Thu Feb 01, 2018 10:13 pm

...and an believable important nerv.
And it's an ultimately pointless nerf that completely misses the point. Bot networks already lose efficiency as they grow in size. A single bot can move lots of things when its longest paths are only 50 tiles, but that same bot will move very few items if it has to travel 900 tiles.

The super bot network happens when the network is VERY SMALL. Any nerf that shrinks the size of the network will not fix this. It will only FORCE players into using high powered compact networks. Those huge 30K bot farms are the ones that suffer huge losses in efficiency and thus can be competitive with a belt solution.

User avatar
5thHorseman
Filter Inserter
Filter Inserter
Posts: 771
Joined: Fri Jun 10, 2016 11:21 pm
Contact:

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

Post by 5thHorseman » Fri Feb 02, 2018 12:04 am

So to make bots work well with belts, roboports have to not work until you have at least 25 of them networked together at max distance?

:D
"So you completed the game with a spaghetti factory? Well I hand crafted a rocket and threw it into space with my bare hands!"

Tricorius
Fast Inserter
Fast Inserter
Posts: 213
Joined: Fri Jul 01, 2016 9:04 pm
Contact:

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

Post by Tricorius » Fri Feb 02, 2018 1:01 am

bobucles wrote:The super bot network happens when the network is VERY SMALL. Any nerf that shrinks the size of the network will not fix this. It will only FORCE players into using high powered compact networks.
Yup. I’m guessing anyone who has put much thought into bots has multiple networks in any decently-sized base.

In fact if your base is large enough it really isn’t smart to just string roboports around all your walls to maintain and supply them, because you then have bots traveling completely across the map. You’re better off having say one network per wall. This way they at least stay in a line instead of traveling from one corner to the other across a great expanse.

Those networks would be for low-throughput things. For instance; I deliver artillery ammo to one chest per defensive wall network (with belts, trains, or a completely separate higher-speed bot network) and then let the bots in the local wall networks maintain ammo supply to each turret. (I’m actually working on Mk2 of a wall that automatically maintains “optimal” network sizes, and can shuttle needed supplies along to the next wall network. It can also automatically build the next network segment, deliver and deploy bots, and stock it up when a blueprint is stamped down.)

But those networks do *not* at all intersect with my rail goods sorter, or the networks that handle RAC (junk), construction, supply, or military trains. Those bot networks need to have a much higher density to handle larger loads more efficiently. When a RAC train comes in I don’t want it to take ten minutes to unload and sort the junk materials coming back.

Does no one automate walls? You couldn’t possibly want roboports that don’t connect if you’ve ever built a decently-sized automated wall. I don’t want to drop ten thousand artillery shells on a loop belt with regular turret ammo. That would be a huge waste of a lot of resources.

gloowa
Burner Inserter
Burner Inserter
Posts: 5
Joined: Thu Mar 02, 2017 10:57 pm
Contact:

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

Post by gloowa » Fri Feb 02, 2018 3:06 am

For improving belts, has anyone considered introducing a belt section with zero travel time?

What i mean is: imagine an underground belt section, but items appear on the exit instantly, just after they enter. (use any explanation you want. teleports. wizards. aliens.)

This won't widen bandwith, but it will reduce travel time, and could(?) help with UPS... And if that section would be non-blocking (like underground belts) then you reclaim terrain that would be "eaten" by belts otherwise...


Another idea i had was this:
A new belt type, (let's call it a "bus belt") that is wider than normal belts (say, 2 tiles wide) and has more lanes/tile of width. So if 2 standard belts side by side have 4 lanes, than this belt would have 5 or 6 (or 7? dunno how many you can squeeze in there without making items overlap too much). Then have the belt endpoint sections, kinda like splitters, where on one side you have standard belt interface, and on the other the new belt interface. You could then take, say, 4 standard belts, run them into that endpoint, have contents compress into 2 tiles of width and un-compress at the end of high-bandwith section. Problem is this would be completely incompatibile with inserters, but i can see something like that be useful for factories that use main bus (all of them?)

Claudius1729
Long Handed Inserter
Long Handed Inserter
Posts: 53
Joined: Mon Apr 03, 2017 5:47 pm
Contact:

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

Post by Claudius1729 » Fri Feb 02, 2018 9:45 am

I like that the devs are considering improving belts over bots and I'm fine with logistics bots nerf.

But I really would like to see construction bots buff and availibility much sooner. Construction is still too tedious in a game that's supposed to be about building and managing a set of small and large factories.

User avatar
Deadlock989
Smart Inserter
Smart Inserter
Posts: 1380
Joined: Fri Nov 06, 2015 7:41 pm
Contact:

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

Post by Deadlock989 » Fri Feb 02, 2018 10:07 am

gloowa wrote:For improving belts, has anyone considered introducing a belt section with zero travel time?

What i mean is: imagine an underground belt section, but items appear on the exit instantly, just after they enter. (use any explanation you want. teleports. wizards. aliens.)

This won't widen bandwith, but it will reduce travel time, and could(?) help with UPS... And if that section would be non-blocking (like underground belts) then you reclaim terrain that would be "eaten" by belts otherwise...
Zero? You think so small. Make it negative travel time. Items arrive at the end of belts before you even made them.

User avatar
bobingabout
Smart Inserter
Smart Inserter
Posts: 6832
Joined: Fri May 09, 2014 1:01 pm
Contact:

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

Post by bobingabout » Fri Feb 02, 2018 10:18 am

bobucles wrote:
...and an believable important nerv.
And it's an ultimately pointless nerf that completely misses the point. Bot networks already lose efficiency as they grow in size. A single bot can move lots of things when its longest paths are only 50 tiles, but that same bot will move very few items if it has to travel 900 tiles.

The super bot network happens when the network is VERY SMALL. Any nerf that shrinks the size of the network will not fix this. It will only FORCE players into using high powered compact networks. Those huge 30K bot farms are the ones that suffer huge losses in efficiency and thus can be competitive with a belt solution.
unless like me you use MK5 fusion powered robots that don't need to recharge.
Yeah, I mod, sometimes my mods might end up in bordering cheatsville territory. but these fusion powered robots aren't cheap costing a portable fusion reactor each, so it kind of balances out.
Actually, I'd rather use Plutonium RTGs (Real life technology), but that means expanding the nuclear stuff to include plutonium and the like, so for now I use fusion reactors.

seriously though, recharging is the big issue, and just gets worse as distance increases.
when I put out a large request (EG, a train stops at the station and unloads all input chests), the aftermath is that the robots spend a very long time recharging. you then need more robots to compensate for the ones stuck recharging.
This is my motivation for actually doing the fusion powered robot. it was requested a long time ago, but back then I dismissed the idea as overpowered.

The same kind of issues are what you get from simply traveling across the map in the base game, robots spend a long time recharging.


So, back to this suggestion of no networks, just single roboport zones:

It's basically another game breaking change. It's not what the devs want either, they WANT you to be able to expand your robot network by building blueprints, blueprints that include roboports on the very edge so robots can build, and replace them. They WANT you to have personal requester slots so robots can deliver materials to you from across the map. The buffer chest in itself is a way to do the long-distance hauling before hand to minimise the long distance player requests.

What they're not entirely happy with is the logistic bots that move items from a place in your base to another place in your base, replacing the job of belts. Hence requester chest being locked behind high-tech(Tier 5) science, where the robots themselves and all the other mentioned supporting operations only need science pack 2, which effectively makes logistic robot networks an endgame technology.

I think part of the issue is related to the robot carry capacity upgrades, and robot speed upgrades.

The problem is they're more effective than they were originally intended to be.
Creator of Bob's mods. Expanding your gameplay since version 0.9.8.
I also have a Patreon.

Pascali
Fast Inserter
Fast Inserter
Posts: 138
Joined: Wed Aug 23, 2017 8:24 pm
Contact:

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

Post by Pascali » Fri Feb 02, 2018 11:24 am

bobucles wrote: And it's an ultimately pointless nerf that completely misses the point. Bot networks already lose efficiency as they grow in size. A single bot can move lots of things when its longest paths are only 50 tiles, but that same bot will move very few items if it has to travel 900 tiles.

The super bot network happens when the network is VERY SMALL. Any nerf that shrinks the size of the network will not fix this. It will only FORCE players into using high powered compact networks. Those huge 30K bot farms are the ones that suffer huge losses in efficiency and thus can be competitive with a belt solution.
It´s a good nerv. On small areas theres no need for belts - bots are too strong. And bots are quicker and easier to setup(an more boring).

User avatar
Alice3173
Fast Inserter
Fast Inserter
Posts: 115
Joined: Sun Apr 24, 2016 11:35 pm
Contact:

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

Post by Alice3173 » Fri Feb 02, 2018 1:59 pm

bobingabout wrote:Considering my base is about 30 roboports by 30 roboports, and anything within this base can be moved from anywhere else within this base.... This is an unbelievably massive nerf.
Would actually be useful as a checkbox option inside each roboport though. Especially with modded roboports such as the oens in your mod, their area is big enough that it can be difficult to keep them separate from other networks which can bog down your network if you're trying to keep things efficient. Being able to explicitly separate roboports from each other would be useful.

ratchetfreak
Filter Inserter
Filter Inserter
Posts: 939
Joined: Sat May 23, 2015 12:10 pm
Contact:

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

Post by ratchetfreak » Fri Feb 02, 2018 2:59 pm

Alice3173 wrote:
bobingabout wrote:Considering my base is about 30 roboports by 30 roboports, and anything within this base can be moved from anywhere else within this base.... This is an unbelievably massive nerf.
Would actually be useful as a checkbox option inside each roboport though. Especially with modded roboports such as the oens in your mod, their area is big enough that it can be difficult to keep them separate from other networks which can bog down your network if you're trying to keep things efficient. Being able to explicitly separate roboports from each other would be useful.
That's a huge buff to robots though

User avatar
bobingabout
Smart Inserter
Smart Inserter
Posts: 6832
Joined: Fri May 09, 2014 1:01 pm
Contact:

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

Post by bobingabout » Fri Feb 02, 2018 7:10 pm

ratchetfreak wrote:
Alice3173 wrote:
bobingabout wrote:Considering my base is about 30 roboports by 30 roboports, and anything within this base can be moved from anywhere else within this base.... This is an unbelievably massive nerf.
Would actually be useful as a checkbox option inside each roboport though. Especially with modded roboports such as the oens in your mod, their area is big enough that it can be difficult to keep them separate from other networks which can bog down your network if you're trying to keep things efficient. Being able to explicitly separate roboports from each other would be useful.
That's a huge buff to robots though
that's what I was thinking. you took a massive nerf idea, sugested it be optional, and it became a massive buff.
Creator of Bob's mods. Expanding your gameplay since version 0.9.8.
I also have a Patreon.

gloowa
Burner Inserter
Burner Inserter
Posts: 5
Joined: Thu Mar 02, 2017 10:57 pm
Contact:

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

Post by gloowa » Sat Feb 03, 2018 4:14 am

Deadlock989 wrote:
gloowa wrote:For improving belts, has anyone considered introducing a belt section with zero travel time?

What i mean is: imagine an underground belt section, but items appear on the exit instantly, just after they enter. (use any explanation you want. teleports. wizards. aliens.)

This won't widen bandwith, but it will reduce travel time, and could(?) help with UPS... And if that section would be non-blocking (like underground belts) then you reclaim terrain that would be "eaten" by belts otherwise...
Zero? You think so small. Make it negative travel time. Items arrive at the end of belts before you even made them.
Meh. If you wanna go there, i have a better proposal - make the new belt type swap time and space dimensions - instead of moving items through space over some time, make it move items through time over some distance ^_^

Tricorius
Fast Inserter
Fast Inserter
Posts: 213
Joined: Fri Jul 01, 2016 9:04 pm
Contact:

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

Post by Tricorius » Sat Feb 03, 2018 5:31 am

Pascali wrote: It´s a good nerv. On small areas theres no need for belts - bots are too strong. And bots are quicker and easier to setup(an more boring).
Again, the better option is to strengthen belts and make them more desired. And at the level that bots are “too strong” everything is reduced to max-level tech which allows you to stamp either bots or belts down en masse. So, I would argue they are probably equally quick and easy.

And “fun” is subjective, not objective. I find bots fun to design and construct, and fun to watch in operation. I find belts to be tedious to design and construct, but pleasant to observe.

Locked

Return to “News”

Who is online

Users browsing this forum: No registered users