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

[hitzu]

Instead of nerfing their effectiveness, increase the cost. Not necessarily in direct resource requirements.

They already cost a lot, both in material and power equivalent!
Making them even more expensive would change nothing, but the initial investments. Why? Because the bots themselves boost the production and rapidly pay off themselves. The real cost in this game is a player's direct labor such as thinking, planning and building the belt layout. Managing the logistic network is trivial, expanding it just would increase the production and resources for its expansion.

[vedrit]

If you read the last FFF carefully, they want the choice to matter. Currently, if you want to play effectively you have no choice but bots. That's not fun.

I, and likely many others, find that belts have a fundamental disadvantage that cannot be overcome and will cause players to want to use bots when available; routing items.
Belts will not deliver items based on destination needs, only based on what's been put into the belt or removed along the way.
Belts can and will be obstructed by other machines, other belts, tracks, and water.
Belts cannot overlap.


Sure, some of these can be overcame with some work on part of the devs, but it will likely not be insignificant.

Nothing short of a complete overhaul or entirely replacement of belts with some other system will cause belts to be a significant option once bots are unlocked.

[SquarelyCircle]

So any solution of the "bots problem", that goes into need of more resources is going into the "wrong direction".

Increasing cost is equivalent to decreasing output per resource. Quadrupling the cost is the same as quartering the output of each bot, but reducing output increases the real-world processing power required to accomplish a given number of bot tasks. Having steadily increasing costs allows entry into the bot phase of the game, and allows slowly reduced effectiveness per cost, but doesn't decrease what a given number of bots does.

I do like your line of thinking on the decreased battery size. Things that alter HOW they work would be a lot better than things that directly alter HOW WELL they work.
Someone mentioned requiring time to accomplish acts like grabbing from chests, and allowing only a few bots at a time to grab from a chest.

Another idea along this lines is that bots are each "assigned" to a particular roboport, so they can only work within its range, much like the personal roboport. To work outside of their own roboport would require reassigning to another roboport, which requires open spots in those roboports, or perhaps even player intervention.

In part, the problem is that bots really are an upgrade from belts. They don't fill a different role than belts. Trying to make belts and bots comparable alternatives makes bots pointless. If you want to use belts in the late game, you're missing out on the upgrade. So the real problem isn't bots, but belts. They don't have an upgrade equivalent to bots, and to fix that, nerfing bots is merely reducing the potential effectiveness of your base. Perhaps a late-game belt upgrade that makes them more effective really is what's needed.
For example, what about a belt alternative that has built in "auto-detecting" inserters on every segment of belt. They detect what adjacent buildings need and auto-grab those items from the belt and put them in the buildings. The auto-arms could use logistics (like filling adjacent requester chests) and player-set filters.
Furthermore, Bob's inserters provides useful functionality to inserters that would really buff them in the base game (like diagonal insertion), and should be considered for inclusion in some form.
Another alternative would be highly efficient late-game buildings that can only be used with the upgraded "auto-detecting" inserter belts I've described above (or some similar alternative belt upgrade).

Honestly, the more I think about it, the more I think this has less to do with bots, and a whole lot to do with the inability to upgrade belts, because we're just focusing on upgrades in terms of output instead of other forms of efficiency.

Bots ARE an upgrade to belts. To change that, we're either making bots pointless (i.e. not an upgrade from the current belts), or we need to make the late-game belt option more viable.

[Soloincognito]

The problem cannot be solved with more costs! When you are about to have bots researched you have in general more than enough resources (well, depends much on play-style, but I would say in most cases it is no problem to have 1000 instead of 100 robots. Which shows that this statement is more or less true).

With costs I also mean not only resources, but also time (charging time, time to build), repair (just needs more resources), power (also just more res) and any kind of "more". At the stage of robots the game doesn't win anything from taking more ressources (time, power...).

So any solution of the "bots problem", that goes into need of more resources is going into the "wrong direction". (Need to mention that I'm talking about logistic only. There is no question, that the construction bots as they are are working more or less well, the problem is with the logistics only, cause their advantage increases with every usage, that is the main difference to the construction bots, which aren't used endless).

Agreed which is why the best improvement would be to have a small access time(say around the speed of a fast inserter) each time a bot accesses a chest and to block other bots from accessing the same chest at the same time. It’s a change that would create natural bottlenecks not solvable by mindlessly building more bots but that would be solvable by creative engineering.

And the best part is I imagine that the best solution might end up being context dependent. Sometimes it might be adding more chests to allow more bot concurrency, but I could also imagine situations where the best solution might be belts. Who knows until we experiment with it and figure it out. To me that’s the type of problem solving that makes Factorio fun.

[hitzu]

If you read the last FFF carefully, they want the choice to matter. Currently, if you want to play effectively you have no choice but bots. That's not fun.

I, and likely many others, find that belts have a fundamental disadvantage that cannot be overcome and will cause players to want to use bots when available; routing items.
Belts will not deliver items based on destination needs, only based on what's been put into the belt or removed along the way.
Belts can and will be obstructed by other machines, other belts, tracks, and water.
Belts cannot overlap.


Sure, some of these can be overcame with some work on part of the devs, but it will likely not be insignificant.

Nothing short of a complete overhaul or entirely replacement of belts with some other system will cause belts to be a significant option once bots are unlocked.

And I absolutely agree that these are strong inherent benefits of the logistic network - convenience, versatility, and flexibility. But it shouldn't be stronger in every way. Why then the belts exists for? First of all the logistic network should lose its virtually limitless throughput. In the scale of throughput, it should be after trains and after belts. Secondly, it should lose a little bit in the space efficiency when it comes to tight layouts, especially in beaconed layouts.

[psihius]

After pondering about the issue, reading what different people say and talking on various Discord's through the weekend, I came to the conclusion that bots, for all intents and purposes, are okay as they are. What I would look at, before coming back and seeing if bots are still up there, are:

• Power - it's trivial to go overboard on power to a point it does not matter how much power draw roboports and robort charging take. Also, same issue applies to Laser turrets. Also, powering beacons is also easy due to the same reason.
• Beacons - doing layouts with beacons with belts is very restrictive, especially when there are more than 2 ingredients involved. Basically it boils down to a single build possible for it to work. Right now due to beacons stacking effects you make it as dense as possible. And problems feeding the beast mode assemblers and unloading the produced goods.
• Belts, and maybe, inserters - for late game beaconed factories express belts are just not up to the task. Same goes for unloading/loading trains, especially the bigger once. Building a station even for a 4 wagon train just become annoying due to the amount of belts you use for the throughput (8 lanes). Now for a megafactory, you usually go with even bigger trains because train congestion and other issues.

I'd say bots are the least of the problems here. The biggest problem is that having gigawatts of power production is easy - all it takes is space and usually it's solar, that's has no running costs - just upfront resources. But you never just put tons of solar upright in a moment - you build is slowly while phasing out steam power and nuclear in very late game (mostly due to UPS issues, or you have a "smallish" backup power reactor). This might be both power building and bots not consuming enough power while doing their job.

Beacons - I don't think I really have to add here anything. Beacons are big and their coverage is very restrictive combined with their ability to combine bonuses leads to very restrictive builds you can do, especially with belts.

Belts. First major thing is - you need to many belt lanes to unload trains and/or transfer items to middle distances. That hurts performance, balancing becomes impossible at certain point (that's why you start using robots - that's the only thing that works to balance out the lanes) and it becomes just unwieldy to work with to a point that you think "screw it". Second part is we really need some better ways of loading/unloading trains, especially the longer once - although, I think that bots are actually one of the good ideas here, since they should be good for doing short-range extremely high throughput jobs.And it all bumps into beacon induced problems of throughput and belt balancing. All that is covered with a nice blanket of UPS concerns for very late game.
I do really think the more or less proper way to solve belt throughput issues is some kind of "bulk belt". You should be able to unload onto that belt via special chest/structure from trains and bot network (+ maybe stack inserters), but you can't take with inserters from it (maybe stack inserters, but I don't think it's a good idea). This belt should be reserved to do point A to point B bulk transfer. Have special splitters/machines that can do splitting from bulk belt to regular belts and/or end terminating entitity that unpacks a bulk belt into defined number of regular blue belts. Idea is it should be a end-game tech and items, so you have to evolve and adjust your base, but not too much. Also I'd say it should be 3 or 3 tiles wide and maybe comes not in a single tile length, but maybe as a 3 x 10 tile segments and splitting/loading/unloading entities can be placed only on the ends.
What it's carrying capacity should be? Well, I thought that 4 blue belts might be a good start, but to me maybe a research that can up that further up to 8, 12 or even 16 times is not a bad idea. This takes care of 2 problems: belt mid-distance throughput and optimizing UPS resource usage buy using a highly optimizeable belt type.

Inserter issue are probably due to beacon tight building issue. We want a 90 degree inserters or configurable inserters there because often to build a good build, you need to pack it in very tight. And with certain items, inserter load/unload speed and belt compression just becomes an issue, so we use bots.

As for the bots, if it still comes back that something needs to be done with them, I'd gear them to short-range peak throughput satisfaction. Like train loading/unloading for example. They should suck at sustained throughput at mid and long distances. Whether it's balanced by power usage or some other type of restriction. I thought about having a "CPU" bandwidth, that you can upgrade through research, but it also increases power usage by roboports and robots due to more power hungry CPU's and bigger batteries needing higher charging rates making peak power demand for massive bot charging 3-6x times the idle drain. Coupled with handling of the power issue should make massive robot networks a huge work to build and maintain.

[bobucles]

Increasing cost is equivalent to decreasing output per resource. Quadrupling the cost is the same as quartering the output of each bot,

But that's not really true. The point where bot balance goes wild is far beyond any point where a player cares about "how much" a setup costs. Money is not a factor for a mega base and no amount of high initial cost will ever stop players from setting up their ultimate base. All that matters is going fast.

[Mylon]

For the people suggesting maintenance as a feature, I wrote this mod. Bots regularly need maintenance: https://mods.factorio.com/mods/Mylon/Bot_Servicing

Try it out and tell me how it affects your playing experience!

[Soloincognito]

If you read the last FFF carefully, they want the choice to matter. Currently, if you want to play effectively you have no choice but bots. That's not fun.

I, and likely many others, find that belts have a fundamental disadvantage that cannot be overcome and will cause players to want to use bots when available; routing items.
Belts will not deliver items based on destination needs, only based on what's been put into the belt or removed along the way.
Belts can and will be obstructed by other machines, other belts, tracks, and water.
Belts cannot overlap.


Sure, some of these can be overcame with some work on part of the devs, but it will likely not be insignificant.

Nothing short of a complete overhaul or entirely replacement of belts with some other system will cause belts to be a significant option once bots are unlocked.

Routing items is absolutely the killer feature of bots and that is the way it should be. The problem is that they get that killer feature plus they get what should be the killer feature of belts: the ability to have a stable high throughput movement of items from a fixed point A to a fixed point B.

Adding a chest access delay and limiting concurrent access by multiple bots would allow them to keep their killer feature of dynamic routing and still be extremely valuable for that, but it would make belts the preferred solution for situations where you don’t need that dynamic routing.

[zp_wingman]

I think the bots should have some kind of wear. Maximum charge cycle count before battery capacity decreases? Rotors renewal? Storage compartment replacement?
Something so that effort for Player Logistics and the odd low volume transport is hardly noticeable, but getting really expensive for long Robo-Buses -
maybe expensive enough that you can't produce new robots with a robot-only logistics system (wear on the robots > repair items produced)?

[Omnix]

That idea was probably posted by other people so treat my proposal as a form of "vote" for that kind of solution. I just dont have enough time and strength to read 26 pages

So my proposition for drone debuff is - nerf the logistics range on roboports and assign player logistics to construction bots entirely (or maybe a differernt player logistic bot entirely for that?). With less range on roboports it wouldn't be possible to cover whole factory without wasting lots of space and resources on multitude of roboports. Basically nerf the roboport range to the point of conflict between good bot network coverage and efficient space management for other factory buildings like assemblers, belts, rafinerys etc.

[MeduSalem]

...

Oh ssilk is still alive...

My interests shifted a bit and I have a new team at work, which does much more interesting stuff (React, Typescript, Redux)...
But sometimes I still take time to read a bit in the forums.

Well... yeah... seems like time doesn't stop and everything changes.

A lot of people from the past years aren't there anymore (except when lured out of their caves with controversial Friday Facts ).

But I guess that is what happens when a game reaches its final stage, only months away from being handed over to the hardcore modding community.

[BHakluyt]

Dear Devs

I have an idea:

re: Inserters are the problem
Postby BHakluyt » Sun Jan 14, 2018 8:00 pm

Hm...I am just going to throw this one out there. Earlier today this popped into my mind for some reason when reading your post's title.

How about another assembly machine level 4, a little bigger or even not but i think 4x4 instead of 3x3. (Yeah that nice blueprint you got? You got to update it for late late game too. I am talking about making the game fast here where the guy who landed can't even imagine it yet.) Together with this add another fourth tier advanced belt, WITH infinite speed research. Don't remove inserters but finally here is the perfect place for that loader which must also have its own infinite speed research. (So theres more sinks for rocket packs too.) AND the player need to balance the two, or in other words research them together. (All these technologies should preferably require all the sciences so that the noodle noobs and spaghetti bois can't easily get to it.)

Now this assembly mashine mk 4, although it can be loaded with inserters too, works with loaders. Connecting directly.

The image that popped into my mind earlier was actually that these mk4s must be like little factorissimo buildings perhaps and inside you have basically a single or quarter chunk and there you make use of many belts, or bots, and inserters and stuff and so when you really have made your own custom assembly machine mk4, fed it with 4x express belt mk4 with loaders and all went into 32 plus blue belts and stack inserters, and still you need more, then, really, you just got to place down another assembly machine.

edit:
Or perhaps, inside this mk4 assembly the outside loaders move everything into either inside loaders or chests, whatever the player place next to corresponding outside input/output. Split one chest into 2, to 4,or maybe a new item...the LOADER SPLITTER! ? Anyways the highspeed thingy can then feed directly into mk4s. Note, mk4s inside mk4s dont allow you to enter but revert to a default mk4 wich is faster and perhaps can craft more items together for those future recipies we dont want to have to mod a new assembly... maybe add more module slots for the mk4 too.

Damn I need to learn to mod proper. And quit my day job or just completely forsake sleep..

edit 2: typos -its a real struggle with a cracked phone screen. And I sort of hope my idea could be part of the solution to this whole horrible debacle about the bots/belts debate..

Boyd Hakluyt

edit - uh too much Cracktorio and not enough sleep seem to impair cognitive capabilities. A loader splitter is just stupid. Mk4 belts have mk4 undies and splitters. Make them scale with the mk4 speed research, or even better yet have seperate infinite research for each item. We need more reasons to launch more rockets. And it adds the complexity that players must focus and think and manage research. Otherwise that level 13 belt will be useless with your level 2 splitters slowing down the belt everywhere.

Also, note normal inserters will not work with this mk4 belt after a certain speed - it will be just too fast.. Don't bother with that, its cool. This mk4 is mainly for the bus. Like a pipe that just pour that copper into that bottomless pit which is your green c factories.

[Olloxan]

How about some environmental changes. There could be areas or landscapes where bots can´t fly, like very "windy" ones or the atmospheric gas is to thin for them to create lift...

[dir94]

My thoughts on stack belts:

Stack belt definately should be a separate entity, not an upgrade to all belts. Mainly because some players (i guess (me at least )) like to build efficient setups with no super extra reserve at throuthput, e.g. if i know that this production line is satisfied with one red belt of iron, i don't want to use blue belts just because i can. If i want to noticeably increase the output of this production line. i better go for some rework of it with a bit of extendability in mind (or think of it before first time construction) with the posibility of beacons use and so on.

Continuing this idea, i think that stack belt logic should be a separate logistic approach, just like bots are. With several new entities, new interesting transitions between different approaches. Particularly, since our goal is to extend late game gameplay, the most interesting and convenient transitions thould be with common belts. Of course common splitters cant transport stacked items from stack belt. Some example entities that come to my mind: stack splitters and UG belts of course (maybe some monstrous graphics for splitter to show it is high tech entity and bigger size (2x2?)), stack unpacker - mostly like Klonan's belt buffer, but accepts stack belt on one side and probably doesn't allow inserters to put items in it. Another idea for unpacker is inline belt entity that accepts stack belt but you have to use inserters to output staff. Maybe some specific stacked inserters (or even existing ones?) that could place stacks on stack belt and only such inserters could pick stacks from such belts. For packing my suggest is to use inserters to put staff in some entity that outputs inlined belt (like belt unloader entity).

One of cons of my suggestion is that this way hardly beats bots in the aspect of ease of deploy. Thus probably involving more classic core fun gameplay.

tl;dr my suggestion is stack belt as separate approach with its own mechanics and interesting gameplay features and new entities

[BHakluyt]

Yeah! A 2x2 loader, huge 4x2 splitters and magnificent 2x2 undies, all accompanied by a shiny new 2 wide super fast belt which can, count carefully, move 4! lanes of items!! With the potential max speed only set by your CPU. And research.
It is in a way a belt upgrade but it is a new logistic thingy. It is a new type of belt that make stuff flow like lightning.

Just watch out not to make it too good so that trains get usesless. Or oh yeah make them so super expensive that you would be stupid to do a 500km stretch with this stuff when a train can do it too for much cheaper.

[CF Worthy]

I would like to weigh in on this topic if I may...

After watching a review of the FFF with Xterminator on YouTube, and a personal chat with devs through a livestream, there seems to be some miscommunication of intentions.

Though it is true that the devs have the freedom to make a game completely for their own pleasures, it's apparent that they thoroughly reflect on the wishes of the fans, and are trying to find a balanced game to meet the needs of both. That being said, if they intend to share in the changes that may or may not be noticed by fans, they must be looking for player feedback, so here is mine.

As a whole, it is theoretically counter-productive to limit the abilities of some things in an attempt to glorify others. If anything, we fans are demanding more production out of both bots AND belts. This may be demanding too much, but for those of us who are unfamiliar with the programming demands this entails, like myself, it seems a reasonable request. It is my belief that limiting the bots or productivity as a whole is a cheap attempt at improving server performance as a whole.

It seems the popular vote is to leave bots alone. The real problem is belt performance, and there have been many suggestions as to what can be done. Personally, I like the idea of pallets! It seems only reasonable that you could, and should, pack your various materials in bulk and transport that bulk through belt much faster than one-by-one. These pallets can have their own crafting recipe, one for every resource, but would then act as a single stack of the whatever resource. You would not be able to carry pallets in inventory, you would receive a stack with every crate picked up. Bots would not be able to carry the heavy load of a crate, which would finally balance the two. Crates would have a durability in crafting machines, sames as science packs, but would register in the recipe as the base resource. As for the image, as this has been argued as the most difficult task, I think a simple cardboard box could be easy to create, and duplicate for every item. Just paste the icon of the item over the top of the box like a label! Perhaps to ensure a clean look, this can be toggled by hitting ALT as you do to see items within assembly machines and chests. I don't know if this sounds like easy programming, but it seems simple enough to me. I'll let you be the judge.

Keep up the great work to an already amazing game!

[dreamworkeraholic]

Automated vehicles with designated load/unload points (chests) will be great addition to bulky trains

[ssilk]

Increasing cost is equivalent to decreasing output per resource.

Sounds like, but indeed this isn't the case with the robots: You can see the costs as an investment into the future to build more bots and increase production with more robots. Which decreases the costs of the bots.

Robots enable - unlike the belts or train - an exponential grow by producing them!

The reason for this is, that once built the logistic bot have endless usages: A bot can be used for any transport. That makes his usage exponentially growing: With any new chest (seen as start/end-point of a transport) you increase their capability and with any transport you have a win over the belts. While the belts have only linear usage: Once built they can be used only for this transport.

Having steadily increasing costs allows entry into the bot phase of the game, and allows slowly reduced effectiveness per cost, but doesn't decrease what a given number of bots does.

I don't see that. What you explain would mean, that the robots price increase with each bot. More or less like bitcoins.
But that does not make much sense.
Indeed I see it like so: It's like inflation of money, because the money can be used more than once after it is printed. In the real world this kind of "re-usage" (and increasing inflation) is limited by sales tax. In Factorio there is no such tax (and makes no sense) and as explained it makes no sense cause once built the robot can be used endlessly and increases the productivity to exponetial rates instead of linear rates like the belts.

Anything, that adds more costs to the bots is like adding more costs to print money. But once money is printed it has a constant "usefuleness". As bots have. And the more bots you have and the more they are used the better.

Bots ARE an upgrade to belts. To change that, we're either making bots pointless (i.e. not an upgrade from the current belts), or we need to make the late-game belt option more viable.

Well, agree. But to make it correct: They are not just an upgrade, they introduce EXPONENTIAL TRANSPORT USAGE instead of LINEAR. And that is the point, why they (also due to my year long experiences) are game-breaking in the long-term game.

So a simple solution is to reduce the exponentiality and that can be done with the already discussed suggestions (Thanks to Shados for this gread list):
- S2: Limit amount of bots that can interact with a container simultaneously / explicit bot/container congestion / limited speed of bot un/loading (e.g. by explicit queing with un/loading speeds, or by a token bucket queuing system)
- S18: Explicit per-area restriction(s) on bots (e.g. hard cap on number, decreasing speed, increasing power cost)
- S21: Nerf long-distance bot delivery times (e.g. by preventing bots from recharging before their delivery is done, by by increasing increasing charge costs for every roboport zone crossed, etc.)
- S28: Pairs of machines that effectively 'teleport' items around a base
- S33: Make bots explodey
- S34: Make bots ability to carry / effectiveness in carrying a given type of item be dependent on its production complexity, such that bots can carry more high-complexity items (e.g. rocket parts) and less (or no) low-complexity ones (e.g. ore, plates)

I add also a new idea:
S35: Limit the number of chests per logistic network.

My comments:
S2: Worth testing, but I predict that this will just be overgone by the players with more chests, which is a backstep.
S18: This is one of my favourite ideas. Cause this idea makes a lot of sense, when introduced with "colored logistics".
S21: Also one of my favorites: Limit the transport-length (E.g. Bots cannot recharge while transport items and reduce speed slowly until minimum speed)
S28: That was also discussed a lot in the suggestions. It makes only sense as a replacement for the current functionality of bots (e.g. when limiting the range).
S33: This would work, when it would mean, that bots can transport a lot, but have a "half-life period", e.g. they have a limited life-time depending on distance they traveled. Cause that would make bots an ending resource and it works like with the money.
S34: Meanwhile I think it would work somehow, but it's not very logical and there are better ideas.
S35: That in combination with S2 would work. But players would cry for simpler splitting of networks (colored logistics).

[DarkyPupu]

A small dlay when loading / unloading from a chest sounds a fair (and credible) solution to me.