Friday Facts #225 - Bots versus belts (part 2)
Re: Friday Facts #225 - Bots versus belts (part 2)
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.
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.
Re: Friday Facts #225 - Bots versus belts (part 2)
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.
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.
-
- Manual Inserter
- Posts: 2
- Joined: Sat Jul 16, 2016 9:40 am
- Contact:
Re: Friday Facts #225 - Bots versus belts (part 2)
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
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
-
- Fast Inserter
- Posts: 153
- Joined: Fri Jan 06, 2017 1:54 am
- Contact:
Re: Friday Facts #225 - Bots versus belts (part 2)
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.
I.e. when a bot enters a chunk - increment counter on chunk. Than decrement robots' speed in that chunk by averenge of that counter.
Re: Friday Facts #225 - Bots versus belts (part 2)
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
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
- bobingabout
- Smart Inserter
- Posts: 7352
- Joined: Fri May 09, 2014 1:01 pm
- Contact:
Re: Friday Facts #225 - Bots versus belts (part 2)
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.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.
Re: Friday Facts #225 - Bots versus belts (part 2)
...and an believable important nerv.
Re: Friday Facts #225 - Bots versus belts (part 2)
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....and an believable important nerv.
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.
- 5thHorseman
- Smart Inserter
- Posts: 1193
- Joined: Fri Jun 10, 2016 11:21 pm
- Contact:
Re: Friday Facts #225 - Bots versus belts (part 2)
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?
Re: Friday Facts #225 - Bots versus belts (part 2)
Yup. I’m guessing anyone who has put much thought into bots has multiple networks in any decently-sized base.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.
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.
Re: Friday Facts #225 - Bots versus belts (part 2)
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?)
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?)
-
- Long Handed Inserter
- Posts: 54
- Joined: Mon Apr 03, 2017 5:47 pm
- Contact:
Re: Friday Facts #225 - Bots versus belts (part 2)
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.
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.
- Deadlock989
- Smart Inserter
- Posts: 2529
- Joined: Fri Nov 06, 2015 7:41 pm
Re: Friday Facts #225 - Bots versus belts (part 2)
Zero? You think so small. Make it negative travel time. Items arrive at the end of belts before you even made them.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...
- bobingabout
- Smart Inserter
- Posts: 7352
- Joined: Fri May 09, 2014 1:01 pm
- Contact:
Re: Friday Facts #225 - Bots versus belts (part 2)
unless like me you use MK5 fusion powered robots that don't need to recharge.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....and an believable important nerv.
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.
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.
Re: Friday Facts #225 - Bots versus belts (part 2)
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).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.
Re: Friday Facts #225 - Bots versus belts (part 2)
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.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.
-
- Filter Inserter
- Posts: 952
- Joined: Sat May 23, 2015 12:10 pm
- Contact:
Re: Friday Facts #225 - Bots versus belts (part 2)
That's a huge buff to robots thoughAlice3173 wrote: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.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.
- bobingabout
- Smart Inserter
- Posts: 7352
- Joined: Fri May 09, 2014 1:01 pm
- Contact:
Re: Friday Facts #225 - Bots versus belts (part 2)
that's what I was thinking. you took a massive nerf idea, sugested it be optional, and it became a massive buff.ratchetfreak wrote:That's a huge buff to robots thoughAlice3173 wrote: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.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.
Re: Friday Facts #225 - Bots versus belts (part 2)
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 ^_^Deadlock989 wrote:Zero? You think so small. Make it negative travel time. Items arrive at the end of belts before you even made them.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...
Re: Friday Facts #225 - Bots versus belts (part 2)
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.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).
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.