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

Regular reports on Factorio development.
Locked
still__alive
Manual Inserter
Manual Inserter
Posts: 3
Joined: Fri Jan 05, 2018 11:55 pm
Contact:

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

Post by still__alive »

Mobius1 wrote:Sticking to the point:
We all agree that in the long term, bots are superior to belts from the moment they're available to build, even nerfing them they'd still be superior.
So, buffing belts, or increasing their speed would be just another blueprint copy-paste thing, nothing new and challenging would be put there (see what I did there Kovarex? :D)
(BTW, you used way more furnaces with the bot transporting than from the belt transporting, the truth is if you plop down same lanes you would see 1.2x difference on the final production. The main purpose of bots is that they can be used with multiple inputs recipes that are impossible to achieve with belts, also they're faster than belts when you need a big base, belts are useless.)

Instead, what about using belts as real-life logistics happens, inside the assembly machine! Inserters takes from the belt, put on the machine inside the factory building, that whole production line will output a product every x seconds based on the speed of the machine, inserters and belts. So the idea here would be something similar to Factorissimo where it would be available in the vanilla game and the factory building would replace the assembly machines, there would be no more assembling machines in the game, instead they would be an factory building where you have to design the production block inside your factory building using belts, containers, machines that will do stuff with the raw materials, inserters to move intermediates around and that factory building would output in a box outside, in the real world, where logistic bots would then grab the finished products and separate them for delivery either by train, car, truck, whatever means the player would choose from.
But there is a catch, you would have to prepare that factory building to craft 1 product at a time, just like an assembly machine does, but the productivity from the factory building would depend on the player's designing inside it. That way you make the logistic part of the game more interesting, there would forcefully make belts worthy somehow since they would be necessary inside the factory buildings (OFC I would still download the mod that would enable logistic bots inside bcoz belts sux, but that's just me) and everyone would be happy, excited, glad to play exactly the way they want... (it would be a shitshow, obviously, but you know, I had to :D)

I hope something useful will come from those words and kudos for the FFF #224 Twinsen you managed to light a fire without a fire, I loved it!
Okay, first of all, I love this idea. I don't even have the words to express how much I love this idea! I'm probably one of the few who was crazy enough to read 30 - 40 pages of the last FFF thread, and all of this thread. Out of all the ideas I've seen proposed, the is by far the greatest one. Not any other idea holds a candle to this. The Factorissimo mod is so in sync with the Factorio spirit, imo. Heck, the Factorissimo mod would probably be my absolute favorite mod, if I wasn't still playing vanilla to get some achievements. @Devs: if you haven't tried this mod, give it a shot and consider how you could use the idea to improve belts.

I wouldn't implement this idea exactly like this quote describes. I don't like the idea of removing any of the existing stuff, so I'd skip the part about only being able to use the existing assemblers in the factory building. Actually, I'd keep it basically the same as the Factorissimo mod, with the tweak of not limiting the belt input/output slots. No bots allows inside the factory building either. Maybe even different interior and exterior sizes of factory buildings too. And the factory being the only building that could interact with a new class of much higher throughput belt. Basically the problem (as I understand it*) with belts vs bots is how bots eventually thrash belts in both throughput efficiency, and space related requirements. Leaving the players who cannot restrain themselves to choose a strategy they find less fun.

And I think this Factorissimo could help solve the issue. Combine it with one of the other ideas I liked in one of the two threads, the one where you have another tier of belts with super high throughput, but need special building to interact with them. The factory would be the perfect candidate to be that building. You could have a new class of belt where 1 belt moves stuff as if it had the throughput of 5, 10, 20, or however many blue belts you want it to equal, so now belts give the best throughput. This new class of belt would have to run into the factory where you'd design your layout to unload the belt and split it off however you'd like, with the excess running back out into the super-belt. That is how you could have belts match the throughput capacity of bots.

Then as far as space usage is concerned, you could have different factories with larger or smaller interior and exterior spaces. So the player has room to squeeze in some layouts that are harder to do with belts, like the beaconed stuff that people are talking about. I haven't got that far myself yet, so this is where my knowledge of the game breaks down. But you could allow or disallow beacons inside the factory building, and allow or disallow beacons outside the factory to affect what is contained within. Whichever makes it the most interesting. The point being to have factory buildings of a certain size that help negate the disadvantage of belts having a physical space that they cannot share, compared to bots with no collision. Certain exterior sizes are limited on the inside so you can't squeeze too much, like a huge green circuit production line, into too small of a space.

Maybe these factory buildings could even be coded in such a way that it also helps UPS even more as well. Once it is designed and the game knows what the maximum output of the product the factory makes is, maybe it could shortcut the simulation of all the assemblers and inserters inside the factory. Turning 20 assemblers (3 wire, 2 circuit) producing green circuits into 1 assembler, as the computational side sees things. If the input of material slows, the output of product would slow by an appropriate amount.

I don't like the idea of directly nerfing bots in any way, because from what I understand that would have an impact on the maximum size of factory possible when you start to run out of computing power. I don't even like the idea of making bots more complicated but vastly more interesting to use at the tradeoff of UPS, thus smaller factory sizes. I would want the devs to address the issue by making belts better in some way. Or add in new bots with more limitations and interesting mechanics, and just push the current logistics (only logistics bots) robots further up the tech tree, as they are. So the UPS friendly nature of these bots is still available for megabases.

I apologize if my thoughts have been written in a disorganized fashion. TLDR; Solve the belts vs bots "issue" by making the Factorissimo mod an official thing, and make it work in conjuction with a new class of super-belt.

*Disclaimer: With 560 hours, I've still only launched 2 rockets, and have not yet made any use of the logistic bots myself. Construction bots yes, logistic bots no. I have had access to them, just not ready to actually try them out yet.

neavilos
Manual Inserter
Manual Inserter
Posts: 3
Joined: Thu May 26, 2016 4:34 am
Contact:

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

Post by neavilos »

I don't know if this idea has been suggested yet, but why not have the robots take up volume? As I understand it, one of the main benefits robots provide is the ability to circumvent surface-level factory equipment by literally flying over it. However, that doesn't preclude this mode of transportation from having spatial constraints. For example, limit the number of active robots to 4 robots in any one tile, mirroring how only so many items can fit onto one belt. The robots would have to avoid colliding with each other, forcing them to flank one another to get to the same chest, roboport, etc. After that, robot movement could be expanded to 3-space (adding up and down directions to make them more mobile) and bounding how high they can navigate to eliminate excessive stacking (perhaps then adding techs to increase ascent and descent speed and increase their ascension ceiling). This idea certainly nerfs robots since they wouldn't be able to immediately embark from a roboport to empty a nearby cargo wagon, nor would they be able to swarm a provider chest. It also doesn't require empowering belts.

R3markable
Burner Inserter
Burner Inserter
Posts: 7
Joined: Mon Jun 27, 2016 9:34 pm
Contact:

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

Post by R3markable »

In my recent play-throughs, I have been utilising the bots more and more. I thoroughly enjoy using bot based systems to increase throughput to the limit. Having the swarm come to life as a train with ore arrives remains immensely satisfying. Personally, I would prefer the bots to remain as powerful as they are now. Instead, I think there is a lot of fun complexity to be gained by adding an other tier to belts.. literally. I am aware that the devs are holding off from making a stronger version of belts for now, but I figure I would share this idea anyway.

I'm imagining something similar to the stacked belt, as described in this fff. It would be a 'hopper belt', or 'bulk belt', which is raised above the ground. It would have the capacity of either 2 or 4 express belts, by piling up items (visually more compressed item sprites?). Miners are not able to feed onto it directly, but require a ramp/elevator belt section (similar to the underground belt, except larger, and needing power). Because of the increased throughput of the bulk belt, you are able to hook up multiple regular fully compressed belts. These belts would dump their items onto the bulk belt via the ramps, and the ramps would stop moving if the bulk belt is full. Inserters are not able to interact with bulk belts. Unloading a bulk belt is done with a hopper, which is a belt section that is in line with the belt, and outputs to the side (or downward, when a belt crosses under). They could be allowed to output directly into an assembler or furnace, or need to be unloaded onto regular belts first. Regular belts can run under bulk belts, and placing a hopper in the spot where they are crossing, will allow items from the bulk belt to dump onto the regular belt, up to the lower belts capacity. I'm thinking the research and construction cost to be mid game, after steel, electric engines and red circuits. I imagine a typical main bus would utilise these bulks belts.

Tricorius
Filter Inserter
Filter Inserter
Posts: 266
Joined: Fri Jul 01, 2016 9:04 pm
Contact:

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

Post by Tricorius »

Lastmerlin wrote:... The problems that bots allowed to skip, were those I had already solved several times and was not keen on solving again. The single modular production cells were rather boring to build. However, they would be equally boring on belt-basis. For me, they are just black boxes with train input/outputs on this level of play. You mainly design the choice, placement, number, interaction of these black boxes. ...
I always assumed bots were the intended solution to this issue.

Once your base gets sufficiently large you start zooming through levels of abstraction. (I equate this best as similar to the ā€œevolutionā€ phases of Spore.)

When you are starting a base, every little thing counts. Every belt, inserter, assmbler, etc.

As you progress, you start abstracting...smelting, refining, circuits, science, etc.

As you drain the starting area, you further abstract...main base, iron outpost, copper outpost, oil outpost. You might even start building modular facilities (I have one that takes oil barrel trains and outputs every other type of refined barrel in trains). These are all blueprint books.

I can take a construction train to a patch of anything and quickly turn it into a module that feeds other modules by using some blueprints. It is like playing with a giant LEGO set.

When I think about factorio, I donā€™t even think of it in terms of belts and assemblers anymore. That is because of blueprints and construction bots. I use a production bus in production modules. (One that would probably frighten people because I use bus lanes of barreled liquidsā€”oh the horror.) ;)

So, to tie back to the FFF post, bots *are* my ā€œdeath spellā€. The concept of the death spell is to reduce tedium. (When you are an advanced character getting attacked by level 1 boars it is just irritating. Mechanisms in all RPGs exist to trivialize, or skip, low level content.)

I see two problems:

Belts are low level content because they canā€™t keep up in the later game.
Beacons (high level content) are exposing the weakness of low-level content.

Fix those problems. Donā€™t make the high-level content less capable.

AndrewIRL
Fast Inserter
Fast Inserter
Posts: 240
Joined: Fri Mar 24, 2017 2:17 pm
Contact:

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

Post by AndrewIRL »


New splitter behaviour is AMAZING.


Great change, enhances gameplay options, enhances belts without directly changing throughput. Perfect.

Image

Upgrade my bot throughput - place a roboport, done.
Upgrade my belt throughput - individually place each tile of belt, underground and splitter.

Reverse the direction of flow - swap the requestor/provider chests.
Reverse the direction of flow - individually place each tile of belt and splitte, reverse every underground.


The measurements on bot/belt maximum throughput are great but you've missed a key metric (difficult to measure, admittedly) and that's player time. Bots are much easier to expand and reconfigure.

Tomycj
Burner Inserter
Burner Inserter
Posts: 6
Joined: Sun Dec 17, 2017 1:35 am
Contact:

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

Post by Tomycj »

Pneumatic tubes as a new kind of belt?
+Items would need to be put into a container before? (like barrels traveling trough translucid pipes)
+A pneumatic system involving air management?
+Insted of inserting items on them, they could connect from the bottom of chests, or a new, dedicated container.

The splitters' new options shoud be a tech upgrade, just like flter inserters

snafets
Burner Inserter
Burner Inserter
Posts: 6
Joined: Wed Apr 27, 2016 7:08 pm
Contact:

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

Post by snafets »

Here the solution to all problems.

Add a mid range belt (compressed belt). This is a idea I have for a long time simple put 3 belts into one and even compress it further 3 compressed in one double compressed belt this give 9x throughput or make the mainline very small. Because of limitations there are some need features that already balance it.
  • Inserter have no access to compressed belts (I would be to lazy to implement it and it make it very easy to handle)
  • Compressed belts don't close gaps, items are only allowed in when on the other end they come out. If the end is blocked the whole line stops (1 belt 2 lines) (Again simplifies things I just have a queue and don't need to look into it.
  • They are faster. I would only use 1 item per tile not 4 to save mem space.
  • No special in/out just one belt type, the ends automatically connect to belts (a bit like underground belts)
  • Items not shown. no way I would get 18 lines nice to see.
  • Single compressed belts are passible (and don't push you), double compressed belts are like pipes.
  • Addons: Network connections that show line is moving, blocked, empty, has error (input on both sides) also visual hints for this would be nice.
  • maybe bidirectional, there is not really in-/output tiles so just push items in and give them a way out (but side matters)

Code: Select all

  1    1     -- thats how it looks like, items go from one number to the other (1 to 1 ...)
2 +====+ 2   -- = is the compressed belt, + are the endpoints connecting to belts
  3    3
For bots more complexity is needed. My suggestion is an extra recourse that handle the amount of bots. Roboports support 10 (20 or 50) bots in there area more bots cannot be handled and have to wait. Extra buildings can support more bots in an (small) area and can build high traffic paths. Or a bot controller that need to handle all actions/requests, more requests need bigger controller more power. Also "manual" controlled bots could bypass the limit, set a fixed route for the bot "bring 50 x every 10s to ...".
Also a more interesting nerf would be split the bots, one can be faster the others can transport more items, this would make range a more interesting factor. Short range get even higher throughput but long range could fall below belt throughput and make then more interesting.

alingis
Burner Inserter
Burner Inserter
Posts: 5
Joined: Sat Nov 26, 2016 3:37 pm
Contact:

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

Post by alingis »

Proposal
The Pneumatic Tube

A) Create a new type of inserter (unlocked by late game tech) which instantly transports entities to and/or from a belt.

B) Add additional research which increases belt speed (gated on the Pneumatic Tube research).

C) Make the Pneumatic Tube capable of inserting onto one or both sides of a belt.


Core Issues

1) Belts can't currently compare to bots because they are limited by throughput.

The limit on throughput is that the functionality of inverters cannot scale to match faster belt speeds. (The animation of the inserter will take longer than the throughput demands or the time spent collecting resources from the belt will leave speed boosted assemblers waiting for the inserted cycle).

2) Belts can't currently compare to bots because high end beaconed assemblers require too much space to set up using belts (particularly when crafting recipes requiring more ingredients).

Solutions

1) A Pneumatic Tube has the advantage over an assembler of not needing to show the actual item(s) that it transports; the visual cue that it has been active within the last N seconds with a simple generic animation should be sufficient for player readability. Under the hood it can probably be a simpler form of inserter (and can therefore inherit all of the settings of any inserted it replaces).

2) With sufficiently high throughput of the belts themselves it becomes possible to interleave more resources onto a single belt. With some better controls of placement onto the belt, this means players could theoretically (with the proper setup that would be creatively unique to every recipe) reduce the belt footprint down to 2 tiles, the same as is required by requester/provider chests for bot based assemblies.

devaking
Burner Inserter
Burner Inserter
Posts: 7
Joined: Mon Nov 02, 2015 8:56 pm
Contact:

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

Post by devaking »

Have bots get slower depending on polution strengh.
0 to 50% for pollution + 0 to 50% for smoke density in there flight path.

To balance this out. Create a new module : the filter
+10 to 30 % energy consomption, -5 to 15 % less pollution emited

Make a research after you get all bots to upgrade roboport with radar. Removes penalty of smoke density in roboport area but emits the same signal a normal radar does for bitter priority target.

Late game have a research for a new building that consumes filter and produce a compact carbon block, reducing air polition in X radius.

Without removing or nerfing bots, this would make player have to transit slower to bots only base mid game or have dedicated non polluted area with bors only and train bringing good from prodution area.

Making late game nots only base still possible.

Licter
Manual Inserter
Manual Inserter
Posts: 1
Joined: Sun Jan 14, 2018 7:25 am
Contact:

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

Post by Licter »

So, I am relatively new to the game and am fairly casual, but it seems to me that there are a couple of things I would love to see that could help balance belts vs bots.

First: pollution causing damage to items. This reflects what pollution does in the real world (e.g., acid rain), and given that bots are flying through the sky sucking air through rotor fans, they would be impacted more quickly by air pollution than anything else. They would be repaired automatically and consistently, obviously, but the additional drain on resources to continually produce and distribute Repair Packs would potentially become a problem (especially since both pollution levels and robot count would increase with base size and density). Damage to other items such as Assembling Machines and Inserters could create a problem of either requiring constant manual repair or relying on bots; a potential solution is only apply damage to structures that require power, and allow them to self-repair by consuming more electricity (scaling with on how severe the pollution levels are).

Second: dump belts and tilt crates (both 1x1 structures). The dump belt would be directional, like a belt, and would drop items on the ground in front of it; it would continually drop items into any container (or assembler) as fast as the belt deliver them. Tilt crates would be a specialized chest that continually drops its contents on the ground in a single direction, obviously most likely onto a belt or into an assembler, at the same speed that the character can drop items on the ground using the 'drop' hotkey. These items would have to be powered, but would open up real estate by allowing more compact packing and unpacking of stored materials (and helping to overcome the speed limitations of inserters).

PurpleGreen
Inserter
Inserter
Posts: 30
Joined: Thu Jun 15, 2017 4:32 pm
Contact:

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

Post by PurpleGreen »

<NO_NAME> wrote:
Avezo wrote:Factorio is not a competetive game. It is a sanbox game. It is fine stuff is not well balanced.
LOL! I'm saw that opinion a few times in this thread. It is basically like writing "Factorio is a sandbox game so is it fine if it sucks." - just a few levels down.
No, the game should be well-balanced. It will ensure that it will create an interesting challenge and be fun to play. It doesn't mean that it won't allow different play-styles, thought.

I'm understand where these opinions come from. We are afraid that the play-style that we are used to will be no longer possible or that are current factory will cease to work. To be honest, I am afraid of that too.
However, we have to remember that this is still early-access game and there will be changes. It isn't finished yet; it isn't fully balanced, and you can't do that without changing anything. So, if these changes brings more positive consequences than negative, we have to sacrifice some of our comfort zone and accept that. This will eventually come in our favor.
it doesnt matter how balanced factorio is . creativity is up to the user. its not the bots fault if people like to build boring ugly bases. why destroy the game for 95% of the player because 2 or 3 of the most uncreative people abuse bots.


i and many other dont think it sucks. if y<ou think it sucks , maybe play another game ?

but , since bots needs to be changed ... belts need to be changed too. it is possible to build fucking ugly , uncreative mainbelt bases that are basically just a straight belt almost as wide as long with rows and rows of assembly machines. so , change belts, too.

the only problem people seem to have , really , is the throughput of belts vs bots. so before destroying bots .... dont touch them at all , but BUFF BELTS INSTEAD. dont change a running system , fix the one THAT CLEARLY DOESNT WORK PROPERLY. why in the world is there a NEED for mods to create faster belts ? because the game is lacking faster belts. (well yuoki and such mods also come with crazy fast bots , i enjoy thatits nice that they are so fast that they are not seen as long as regular bots.

PurpleGreen
Inserter
Inserter
Posts: 30
Joined: Thu Jun 15, 2017 4:32 pm
Contact:

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

Post by PurpleGreen »

blueblue wrote:I'd like to take another look at the question of why bots really need to be nerfed.

People have made different experiments on how bots compare to belts with regard to throughput, and in some experiments bots hold up equally well or better than belts, see the subreddit, specifically see this, this. Note that in the FFF experiment, the bots have all upgrades, which takes quite a bit of research and that should be worth something.

In any case, no one is currently building belt (or any) mega bases

Yep.
Liar. where do you get that information from ? only because YOU are uncreative or too narrow minded doesnt mean that everyone else is like you. or in other words , YOU ARE NOT THE STATUS QUO.
my GF and i ARE building a megabase with belts ( and trains and bots , bots mainly for the repair of turrets, player supply or really low frequency goods or player supply)


sorry the attitude but this topic is becoming ridiculous.

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 »

Xecutor wrote:Pneumatic tubes for the win:
Image
+1

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 »

PurpleGreen wrote:when i read stacked belts ... i actually thought about something like this Image

this would be fantastic
indeed

Roolo
Manual Inserter
Manual Inserter
Posts: 1
Joined: Sun Jan 14, 2018 8:27 am
Contact:

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

Post by Roolo »

I just registered because I think the following ideas already suggested (I cannot find the original post back) really deserves to be highlighted, as it seems very simple to implement for the developers, while it solves most problems discussed here in a very elegant way.

Make robots wear out.
The problem right now is that no matter what existing parameter you tweak for robots, the impact will be little, as just building more robots is always a valid solution. The fundamental cause of this is that the only permanent cost of building robots is extra power consumption. However, increasing power production is very trivial at this point (just make more solar panels, or more nuclear reactors). As long power power production is not balanced better, the only solution to me seems introducing other permanent costs for maintaining robots, for example, by making them wear out (they could just explode after a given time, or maybe something less annoying :)). This way robots can remain as powerful as they are, while belts will still have an advantage over them, namely that they don't have any permanent costs as opposed to robots. This also adds the challenge when working with robots, that you have to keep your population of robots steady, because otherwise your factory's production can come to a grinding hold. Belts not having this problem also gives them an edge. This change would also have the side effect that players really have to think for which type of transportation they use bots, as it might due to the introduced maintenance costs not be as cost effective anymore to use them to move massive amounts of low-value resources.

Another option would be to make the already existing permanent cost of robots (power-consumption), less trivial to compensate for. This would mean a total re-balance of the electricity system, which opposed to making robots wear out, seems much more game-altering and complex to execute, and I don't know if the developers are still in for such a change at this point.

vyktor
Burner Inserter
Burner Inserter
Posts: 14
Joined: Fri Oct 13, 2017 8:42 am
Contact:

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

Post by vyktor »

I guess bot occupying space would be quite difficult to implement. Also routing would be fun (500 bots going towards chest from all directions completely blocking the one bot that's trying to leave and taking the space around chest).

It would make sense (from real life perspective) to:
  • limit access to chest to N bots at once - IRL you just wouldn't fit that many of them so close to the ground
  • non-zero loading time
  • allow any number of bots to fly on the same path (the way it's now) and make the power cost exponentially depended on the number of bots per network (excuse: with more bots on the same path they can't all just fly 10 feet above the ground, some have to go higher and higher and higher thus the higher power consumption)
  • maybe add graphic that would show bots ascending and descending
  • create research like "Advanced Bot Routing" which would decrease power consumption and increase per-chest limit
    • by default only one bot per chest at the time
    • 3 tiers, each +1, available without spacepacks - so you could have comfortably up to 4 bots at the same chest at time (like inserters per chest) before rocket
    • infinite research
  • maybe create research "Bot Loading speed" with similar rules as the one above
I believe that if you are willing to put 60 rockets worth of space packs you should be able to make bots OP. This way bots wouldn't be OP at early stages but still be suitable for megabases later on. You'd have to pay hard and consciously choose to make them OP. IMO it also reflects the real-life issues that would bot haves (routing, concurrent access, loading) and it would feel rewarding as researching worker speed.


On subject of belts, how difficult would it be to implement some sort of Tesla Teleport Belt:
  • belt itself wouldn't work as belts do, but it would be represented by two optic fibers
  • activity would just show as changed color of a fiber (maybe gradient from black to glowing based on load) = no need to draw items
  • fiber itself would be passive (you cannot interact with it in any way)
  • active components that require power:
    • you'd have to build repeaters every N tiles
    • loader/unloader stations (basically 1 tile of express belt)
    • splitters and corners would also cause delay
  • the belt would be "instant" with loader/unloader as limiting factor (you know, speed of light stuff)
    • 1 tick per any passive segment
    • 5 ticks per active segment
    • for example loader + 3 repeaters + 4 fibers + unloader = 5 + 15 + 4 + 5 = 29 ticks to transport anything
  • 1 Tesla belt could fill 4 Express Belts
  • if you decided to join 5th express belt via spliters, the fiber would just melt and break
Please don't break 5000SPM bases :(

DHunger
Manual Inserter
Manual Inserter
Posts: 2
Joined: Sun Jul 03, 2016 6:32 pm
Contact:

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

Post by DHunger »

In Xterminator's Discussion Video they brought up the point of making bots more complicated, not just lowering their capabilities. Why don't make robots require maintenance (broken engine, lowered battery capacity over time, ...) instead of just making them less powerful. I would really enjoy having to take care about my robots to get to max. Throughput.

Sorry if my english is not the best, I'm from Germany...

OkariDraconis
Inserter
Inserter
Posts: 41
Joined: Wed Mar 02, 2016 3:33 pm
Contact:

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

Post by OkariDraconis »

I like the idea of stacked belts...but make them work sort of like highways... IE there are on ramps and off ramps that can output a fully compressed belt...

2ndly... Check out Angels mods... specify the Logistics mod... They have some called a Cargo bot that holds 100 items at a but moves stupid slow... they are not viable for "hive" factories... but when combined with loaders they are perfect for train unloading trains into boxes connected with a loader... you then use belts to distribute to a production line as you see fit...
This makes it so belts are still highly useful and necessary for for your production block.

These cargo bits eliminate the problem of... how do I get my copper and iron to my new production block... but are too impractical to feed 20 chests in your production block.
Please review this idea when you get a chance
Swarm Biters (locusts) - The Evolved Response to TurretCreep

5+ years game development experiance

Sprixus
Manual Inserter
Manual Inserter
Posts: 2
Joined: Tue Apr 25, 2017 5:49 am
Contact:

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

Post by Sprixus »

I think a good way to nerf belts would be to change the way the logistics network worked. My suggestion is that logistics robots should only move items around in an area the set square size around a roboport, and the square would be around the size of a power relay. Logistic bots would be bound to that roboport, doing away with the base spanning logistics network.

You could even make it so logistic robot requests had to pass through a roboport. ie. providers would put items directly into the roboport, while requester could only request items from the roboport.

This way complex recipes can still be easily manages with robots, and the belt logistics becomes about supplying and removing items from roboports.
Last edited by Sprixus on Sun Jan 14, 2018 9:58 am, edited 1 time in total.

roman566
Fast Inserter
Fast Inserter
Posts: 136
Joined: Sat May 24, 2014 10:53 pm
Contact:

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

Post by roman566 »

You know what's THE easiest and most efficient way to nerf bots without outright destroying them? Make provider/requester chests to be 3x3. They will no longer be useful for the common 'two lines of beacons with assemblers between' builds. The end.

Locked

Return to ā€œNewsā€