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

Regular reports on Factorio development.
Locked
Yarri
Manual Inserter
Manual Inserter
Posts: 3
Joined: Sun Dec 17, 2017 11:15 am
Contact:

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

Post by Yarri »

My humble opinion

Typically, players build a super-bus with 8 belts.
If it is replaced by 1 super-belt with x10 speed, but forbid to put and take resources by manipulator. Only a splitter.
And add to the splitter the speed controller from 10 (default) to 1 for balancing the intake of resources.
Super-belt for each level - yellow, red, blue - to upgrade the system.

This will remove the excess of the belts and make the system more flexible.
And super-belt (bus-belt can be called) will be a competitor to bots.

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 »

Tomik wrote:
Image

Also add fucking Loaders, which are already programmed in the game. Allow them to only put things in and out of cargo wagons and other chest types and put ores into and out of furnace type buildings faster then then stack inserters. Not Assembler types and Reactors/Steam Engines types. You do this and suddenly the bonus gained from HUMONGOUS Botport unloading/loading stations and robotic furnace setups goes to zero. Xterminator and KoS will have to redo A LOT of their designs but won´t be as much pissed if you nerfed bots.
+1

I also quite like the idea bots occupying some space (this would inherently force only one bot to interact with chest at the time).

And larger/joinable late-game chests. Offloading 3-vagon-train to chest 20x1 tiles large and N loaders being automatically balanced. Or chest 6x1 tiles would do ;)

leoch
Fast Inserter
Fast Inserter
Posts: 132
Joined: Fri Dec 16, 2016 9:37 pm
Contact:

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

Post by leoch »

Nice FFF, I agree.

But have you considered that maybe modules and especially beacons are simply over-powered? To me it makes sense that Assemblers tier 2 and 3 are a bit faster, but seems like a "megabase" should be huge. Many of the ones I've seen are not much different than my "medium-sized" bases with less than 1/20th the throughput. If megabase production requires several more lines of factories, then belt throughput is much less of an issue.

vipm23
Long Handed Inserter
Long Handed Inserter
Posts: 54
Joined: Fri Aug 12, 2016 4:05 pm
Contact:

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

Post by vipm23 »

Suggestion:Instead of trying to make the belts compete with bots for sheer throughput per space, have belts remain low cost and energy efficient for their throughput compared to bots, while improving their performance in tight spaces. Part of the reason bots excel is that they can move items into and out of spaces that belts can't, so it's possible to make much more space and module efficient factories using bots over belts. Adding things like 90 degree inserters and the new filter splitters would help mitigate this by allowing more compact belt setups.

On that note: Loaders. Give them a power requirement(A little bit more than a stack inserter going full tilt), a material cost(A little higher than a stack inserter) and a technology requirement(Logistics 3?) and they're pretty much good to go. They fill a niche that inserters have trouble fulfilling(High throughput into/out of one container) while being specialized enough they can't feasibly replace inserters or splitters in any other role(taking off a belt going past, filtering items out, compressing multiple belts into a single one, etc etc).

This would buff belts in a way that bots would only slightly benefit from, since you can use them to feed a fully compressed belt straight from or to a container instead of provider or requester chests, and achieve the same throughput in the same space without having to supply the bots.

And it appears I've already been beaten to the punch several times over...

User avatar
hitzu
Filter Inserter
Filter Inserter
Posts: 530
Joined: Tue Sep 09, 2014 5:55 pm
Contact:

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

Post by hitzu »

Make chests 2x2. Not only this would increase the role of belts in the train stations, but also would make the perfect requester+provier+assembler setup not so perfect. :)

warlordship
Inserter
Inserter
Posts: 23
Joined: Mon May 08, 2017 8:13 pm
Contact:

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

Post by warlordship »

mooop12 wrote:
(about belts) It is probably better to leave this issue as it is so that we don't break the existing game.
And then at the end
I strongly believe that bots should have a debuff.
Come on. This kind of indecision in a team honestly doesn't put you in a very good light. Should we fear a bot nerf or should we look forward to a belt boost? I would feel better if todays FFF just wasn't released.

Also: "Hurr durr I don't like playing with bots so everybody should dislike them like I do, they should be nerfed!"
Well, this is why the forum post is here. There have been a lot of suggestions for decent "nerfs" to bots that might not actually affect their usage, while also a few recommendations for "buffs" to belts that can remove some of bots incentives. Things like:
- Loader/unloader, to make compressing belts much easier to do.
- Possibility of stacked belts
- Corner inserters.
- Limit in number of accesses per second per chest (bot docks, locks down chest to get contents, then unlatches), but with buffs to bot cargo size.
- Removal of beacons (I want this change) so it's not only possible to crank up an assembler to 11 using only bots.
leoch wrote:Nice FFF, I agree.

But have you considered that maybe modules and especially beacons are simply over-powered? To me it makes sense that Assemblers tier 2 and 3 are a bit faster, but seems like a "megabase" should be huge. Many of the ones I've seen are not much different than my "medium-sized" bases with less than 1/20th the throughput. If megabase production requires several more lines of factories, then belt throughput is much less of an issue.
I agree. I really don't like modules that much, and really hate mixing types too. So I hardly ever use beacons, instead prefer to spread out and make my mega bases actually - you know - mega in size and repetition.

There is little in this game I like more than to see a line of 50+ assemblers with the input/output belts aligned and full of items.
Last edited by warlordship on Fri Jan 12, 2018 9:57 pm, edited 1 time in total.

User avatar
<NO_NAME>
Filter Inserter
Filter Inserter
Posts: 270
Joined: Tue Aug 02, 2016 9:52 am
Contact:

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

Post by <NO_NAME> »

Don't forget to add research that will unlock option to filter via spliters. Prioritizing sides is ok but filtering is too overpowered for early game.
I am a translator. And what did you do for Factorio?
Check out my mod "Realistic Ores" and my other mods!

3trip
Inserter
Inserter
Posts: 41
Joined: Fri Sep 18, 2015 3:40 pm
Contact:

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

Post by 3trip »

milo christiansen wrote:
Zeblote wrote:
Frightning wrote:1: Modules and Beacons being as they currently are means that there is really only one endgame layout that is optimal. Which is the ever famous alternating rows of beacons and assemblers, which everyone uses because it is clearly optimal. If modules and/or beacons were changed so that there was more than one 'optimal' layout for endgame, belts might be more worthy of consideration.
Solution: remove beacons. Every design people come up with that involves them looks horrible...
That... Is actually a great idea. It removes the #1 late-game layout constraint, making belts much more competitive.

Or just remove the beacons ability to stack so you can only just use one, maybe buff the tower to compensate.

Serenity
Filter Inserter
Filter Inserter
Posts: 704
Joined: Fri Apr 15, 2016 6:16 am
Contact:

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

Post by Serenity »

nakran wrote:I'm a bit surprised about some of the reactions of the last FFF because, at least for me, it was clear that the bots would stay.
Yeah, I have no idea why people freaked out so much. It was very obvious that the post was somewhat theoretical and more of a "what if". That if things were built from scratch now, bots would look different, but that they can't change things too drastically after the fact. That's also why it's not a contradiction at all to say "I feel that bots need a debuff, but they won't be nerfed much".
But it's typical of the internet that people completely overreact and whine over nothing.

Avezo
Filter Inserter
Filter Inserter
Posts: 450
Joined: Fri Apr 01, 2016 3:53 pm
Contact:

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

Post by Avezo »

Zeblote wrote:
Frightning wrote:1: Modules and Beacons being as they currently are means that there is really only one endgame layout that is optimal. Which is the ever famous alternating rows of beacons and assemblers, which everyone uses because it is clearly optimal. If modules and/or beacons were changed so that there was more than one 'optimal' layout for endgame, belts might be more worthy of consideration.
Solution: remove beacons. Every design people come up with that involves them looks horrible...
Hell no!
Have you tried building a smelting row with productivity modules, but without speed beacons? It becomes GIGANTIC beyond anything reasonable.

Though, if there was other solution to that I probably wouldn't mind them gone.

Meister_Knobi
Manual Inserter
Manual Inserter
Posts: 4
Joined: Thu Dec 21, 2017 9:46 pm
Contact:

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

Post by Meister_Knobi »

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

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

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

What do you think?

warlordship
Inserter
Inserter
Posts: 23
Joined: Mon May 08, 2017 8:13 pm
Contact:

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

Post by warlordship »

Avezo wrote:
Zeblote wrote:
Frightning wrote:1: Modules and Beacons being as they currently are means that there is really only one endgame layout that is optimal. Which is the ever famous alternating rows of beacons and assemblers, which everyone uses because it is clearly optimal. If modules and/or beacons were changed so that there was more than one 'optimal' layout for endgame, belts might be more worthy of consideration.
Solution: remove beacons. Every design people come up with that involves them looks horrible...
Hell no!
Have you tried building a smelting row with productivity modules, but without speed beacons? It becomes GIGANTIC beyond anything reasonable.

Though, if there was other solution to that I probably wouldn't mind them gone.
What if they removed the speed penalty for productivity? Since you can only use those modules in intermediate, you could still have a use for plain, old speed modules in some machines, or they could still be faster overall than the "slightly faster but less cost" productivity modules.

mOoEyThEcOw
Inserter
Inserter
Posts: 22
Joined: Fri Mar 17, 2017 11:27 pm
Contact:

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

Post by mOoEyThEcOw »

On the question of belt throughput, I made a suggestion thread, for an idea of launches. Basically use artillery cannons to shot items through the base. Make them constant through put like belts, and make it so they can't cross, like belts. This could be a solution to managing the through put problem mentioned in the FFF.

vipm23
Long Handed Inserter
Long Handed Inserter
Posts: 54
Joined: Fri Aug 12, 2016 4:05 pm
Contact:

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

Post by vipm23 »

Avezo wrote:
Zeblote wrote:
Frightning wrote:1: Modules and Beacons being as they currently are means that there is really only one endgame layout that is optimal. Which is the ever famous alternating rows of beacons and assemblers, which everyone uses because it is clearly optimal. If modules and/or beacons were changed so that there was more than one 'optimal' layout for endgame, belts might be more worthy of consideration.
Solution: remove beacons. Every design people come up with that involves them looks horrible...
Hell no!
Have you tried building a smelting row with productivity modules, but without speed beacons? It becomes GIGANTIC beyond anything reasonable.

Though, if there was other solution to that I probably wouldn't mind them gone.
Suggestion: Module racks. A 1x1 rack that can hold one module, that buffs just the machine it's facing.

It's the sort of thing you can stuff in between the spaces a belt build leaves, so you can boost both a belt-fed machine and a bot-fed machine to the same extent.

User avatar
hansinator
Fast Inserter
Fast Inserter
Posts: 160
Joined: Sat Sep 10, 2016 10:42 pm
Contact:

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

Post by hansinator »

Hi!

This is a very interesting development lately. I've always tried to build factories without bots b/c I think it's more fun. Ever since I realized how complex it is to build optimal belt setups I wished that there would come some improvement. As has been pointed out, there are some quirks that everyone has to work around. Once you find the proper blueprint building blocks on the forum or wiki the challenges become more of a tedious thing you have to do to satisfy some unintentional requirements the game engine imposes on the players. The most annoying thing then is that it takes so much space to build. The new splitter settings are a huge step into the right direction. I'm all excited about more belt buffs.

Here are some more Ideas:

Make two-story express belts; i.e. stack the belts instead of making the belts move stacks. The drawback is, that inserters can't work on these belts. You have to use entry/exit building blocks (like on highways) to convert the two-story express belt into two normal express belts. Either the entry/exit always work like a Y-adapter merging/unmerging two belts into/from the two story belt, or you can place entry/exits that only access the upper or lower level of the two-story belt so you have more flexibility.

Make an entity to block one side of a belt. It can already be done with underground entrances/exits, but they impose unnecessary restrictions onto the belt-system-designer. It would really be better if you just had a building block to achieve this basic thing. Being able to block one lane is a must-have for advanced belt designs, so why not make it an official game feature instead of allowing it through a crude backdoor.

Make an inserter that has multiple drop positions. Instead of just moving stuff from one side to the other, this inserter could move things from one pickup location to one of three drop locations, which are the remaining three orientations. What to drop where could be defined via filters or set by the circuit network.

Make belt speed controllable via circuit network. Instead of sending on/off via the circuit network one could send a value to regulate belt speed from 0-100%.

Make inserter pickup behaviour consistent no matter in which orientation it is placed next to a belt. The last time I checked inserters had problems to pick up items reliably picking from the side of an express belt. It works better when they are facing the belt. Unless they have that weird stuttering effect. This is annoying especially because it isn't obvious at first and then it becomes a problem that may require redesigning your whole belt based smart furnace block.

Make an air jet pusher for belts: https://www.youtube.com/watch?v=E-Bj7TKgXSE . That would be fun and give a sense of a modern factory when you build it :)

Make nixie-tubes part of the game. No advanced circuit-controlled belt system can be built without debugging via nixie-tubes ;-)

Redoneter
Burner Inserter
Burner Inserter
Posts: 8
Joined: Fri Apr 14, 2017 2:14 am
Contact:

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

Post by Redoneter »

Personally, I think a small nerf to bots (Such as power capacity and charge rate decreased by 25% and 50% respectively, and the maximum cargo size bonus reduced by a bit) and a small decrease in belt costs would be best.

TiMatic
Burner Inserter
Burner Inserter
Posts: 17
Joined: Sat Jan 06, 2018 12:09 am
Contact:

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

Post by TiMatic »

hitzu wrote:Make chests 2x2. Not only this would increase the role of belts in the train stations, but also would make the perfect requester+provier+assembler setup not so perfect. :)
Because a chest can store more items than a train car, why not make a chest 6x1 or 3x2 like a train car.

Samlow
Burner Inserter
Burner Inserter
Posts: 7
Joined: Sun Jan 07, 2018 12:50 am
Contact:

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

Post by Samlow »

Seeing as some people commented on diminishing returns, has this been considered or mentioned in detail before?

Regardless, I named this as my sollution to bots scaling linear (and belts scale till theyre full or out of space in the setup) is because we had a similar issue in From the Depths.

That game is about building your own (often AI controlled) vessels to fight other player made (and NPC controlled) vessels.
When I was in active development I was tasked with coming up with a better Engine system. Our metagame was stacked for the energy using weapon (Lasers) since you could build a exponentially scaling (trivial supply) engine. This led to laser designs just absolutely obliterating everything. There was also no active defense against lasers possible, increasing the problem.

The sollution however was three-fold. 1: Remove exponential scaling of engines 2: Provide a defense against lasers 3: Give more choice for power supply.

Although the concept was more purist then the implementation, we ended up with a new engine system, that had diminishing returns on single engine size, but rewarded smarter building of them at the same time. You now had the choice of building either a highly efficient engine or a powerful compact one. Still, people were free to use as many as theyd like (linear scaling), but they are practically limited by the ships sizes.

The key here though was not just removing something that people used which was overpowered, but also provide a more engaging experience as a replacement!

Diminishing returns
So, what are diminshing returns?

Basically, its a simple calculation.
Lets say you want to expand something by 1 of the same, but you dont want it to be as efficient? Just add a efficiency multiplier in the formula somewhere. One of the simplest ways for us was to add a square function on the formula with the efficiency factor, but the exact code is not that relevant here. The basic gist is that every instance added, increases the total function by less than the previous instance added. There is a diminishing return formula applied to infinite research.

The way to apply this curve to factorio can be many ways:
- Power draw increase
- Battery time decrease (need more calculations on bot to stay clear of other bots)
- Flight speed decrease
etc etc.
The last one would probably be the most efficient for factorio, since its really hard to make a slower network with more bots more efficient.

The advantage is that casual bot use is largely unaffected. Its the overstacking of bots thats suddenly put to a halt, and actually means that any future nerfs to bots cant be solved by just adding more bots.

SHADOW13
Burner Inserter
Burner Inserter
Posts: 10
Joined: Tue Apr 25, 2017 12:02 pm
Contact:

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

Post by SHADOW13 »

I would suggest % belt speed boost research (infinite?) along the same one for loaders (included or separate), this way wouldn't affect bots but would boost belts

I like "stacks" of items idea, how about 1x3/3x1 entity (like splitter but 1 tile bigger), it stacks 3-5 lanes (ie. input from left, top, bottom) and outputs middle on the right as a stack (when belt links outwards) or works the other way around if belt's connected inwards

implement both options above and belts win

OvermindDL1
Fast Inserter
Fast Inserter
Posts: 174
Joined: Sun Oct 05, 2014 6:12 am
Contact:

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

Post by OvermindDL1 »

What about just making a logistic network local to only a single roboport? I.E. the roboport manages it's own network, the network being it's range, thus robots in a single roboport only ever go back to that roboport and only work with chests within the range of that roboport. A logistics chest could be overlapped by multiple roboports no problem. The new buffer chest would be useful for roboports to 'pass' items between, the roboport with production of the item fills it up, and the other roboport that has no other inputs of that item then use that buffer chests' items.

I'd even vote on significantly reducing the roboport range (at least the logistics range, or perhaps separate logistic and construction roboports entirely) and make it upgradeable via research (with an override on the roboport to specify a manual shorter range like you can stacks with inserters). This then makes bots very local. Still very used, but not 'as' often as things like the central bus for each outpost would become important again (more so the shorter the logistics range is).

Locked

Return to “News”

Who is online

Users browsing this forum: No registered users