Friday Facts #225 - Bots versus belts (part 2)
-
- Manual Inserter
- Posts: 1
- Joined: Sun Jan 14, 2018 9:51 am
- Contact:
Re: Friday Facts #225 - Bots versus belts (part 2)
I found the idea with stacking conveyors interesting. To avoid buffering on each conveyor what about some 1x1 conveyor entity which limits stack height, which will pass through. If stack is bigger, than it will pass partly. All items over limit will be stopped.
Re: Friday Facts #225 - Bots versus belts (part 2)
Also aside great ideas in this thread i wanna see belt "ghost bulding" like train tracks. Why? Because belts shine in middle distances and this is great feature for train tracks also it will be nice for belts.
Re: Friday Facts #225 - Bots versus belts (part 2)
My 2 cents... I really don't like the splitter solution... I always thought the splitters were a bit unrealistic, so their fixed behaviour was their best part. Now they'll work as computers without even requiring power. I hope at last the change will concern the blue splitters only. Also, I agree with nerfing the bots, speeding up the recharge times and costs and limiting their strength, so every bot can't transport tons anymore. But I always like the hardest difficulty possible in games so I don't speak for everyone. Anyway, keep up the good work!
Re: Friday Facts #225 - Bots versus belts (part 2)
I never thought of that. That might actually get rid of some of the tedium of placing belts.sathill wrote:Also aside great ideas in this thread i wanna see belt "ghost bulding" like train tracks. Why? Because belts shine in middle distances and this is great feature for train tracks also it will be nice for belts.
Re: Friday Facts #225 - Bots versus belts (part 2)
I think, that the minimum space betwen two Robots must be a loot bigger. So the bots have to fly courves around themselves and they cant fly in a row like a belt. They have the same speed but longer ways to go.
20 Drones in real life cant fly in a direkt row because turbulence in the air, the danger of chrases...
This is not possible in real life.
20 Drones in real life cant fly in a direkt row because turbulence in the air, the danger of chrases...
This is not possible in real life.
Re: Friday Facts #225 - Bots versus belts (part 2)
Personally, I think belts are a lot more fun than bots, so as such it feels disappointing that bots are so much stronger than belts late game. Nothing wrong with bots being strong, but I think belts should still remain viable, so a bot nerf is necessary I think.
The problem is when you have a very large amount of bots in action at one time, then they can transport very large amounts of material, even at moderate distances. The quick fix would be to simply limit the total number of bots.
Reduce the number of bots that can be held in a single roboport, currently 300, and reduce it down to 50 logistics and 50 construction, with an option to increase through science, but not too high. Bots are still powerful for small deliveries or large, short distance transports, but become less efficient with greater distance. Of course this can be resolved with more roboports, but that takes up more resources and space, and when you have more roboports than assemblers you might start to wonder if it was worth it. Could possibly be combined with increased production costs of robots and roboports. Or refueling with batteries on a regular basis, say every 100 full bot recharges the port needs to consume a battery as replacements for the robots, so they can't be maintained with solar panels alone. Maybe increase energy requirements for bots as they get faster. I think currently they have fixed wattage no matter what, so they travel farther on a single charge as well. If the wattage increases with the speed then they will need to recharge sooner. This could be compensated with research to increase charge capacity to increase bot range, with increased recharge time as a consequence.
Alternatively, restrict roboports so they have to be built a minimum distance from each other, feels arbitrary and there is no equivalence amongst other buildings. And you could just place the ports on a grid and place the assemblers in the spacing between them, instead of having all the ports next to each other. But it would mess up designs, and cause problems with beacon layouts.
The problem is when you have a very large amount of bots in action at one time, then they can transport very large amounts of material, even at moderate distances. The quick fix would be to simply limit the total number of bots.
Reduce the number of bots that can be held in a single roboport, currently 300, and reduce it down to 50 logistics and 50 construction, with an option to increase through science, but not too high. Bots are still powerful for small deliveries or large, short distance transports, but become less efficient with greater distance. Of course this can be resolved with more roboports, but that takes up more resources and space, and when you have more roboports than assemblers you might start to wonder if it was worth it. Could possibly be combined with increased production costs of robots and roboports. Or refueling with batteries on a regular basis, say every 100 full bot recharges the port needs to consume a battery as replacements for the robots, so they can't be maintained with solar panels alone. Maybe increase energy requirements for bots as they get faster. I think currently they have fixed wattage no matter what, so they travel farther on a single charge as well. If the wattage increases with the speed then they will need to recharge sooner. This could be compensated with research to increase charge capacity to increase bot range, with increased recharge time as a consequence.
Alternatively, restrict roboports so they have to be built a minimum distance from each other, feels arbitrary and there is no equivalence amongst other buildings. And you could just place the ports on a grid and place the assemblers in the spacing between them, instead of having all the ports next to each other. But it would mess up designs, and cause problems with beacon layouts.
Re: Friday Facts #225 - Bots versus belts (part 2)
Maybe if you need to build your roboports far apart from another
Re: Friday Facts #225 - Bots versus belts (part 2)
bots are to stronk. Belts are o.k. - it is an enjoyment leaning back an watching them. Because you have a good and confortable to watch feeling/feedback about the amout which is beeing transported.Avezo wrote: Once again - there is no issue with bots being too strong. There is issue with belts being too weak. In this case, instead of nerfing bot access to chests, find a way to buff belt access to them (psst, pssssst... Loaders...).
Re: Friday Facts #225 - Bots versus belts (part 2)
I actually think that any “solution” to the bots problem (which I don’t really think is a problem in the first place) is going to be pretty easy to work around (most of them, are simply ways to force bots to use more resources). So I really don’t care if there are bot nerfs. In fact, the last couple weeks have just shown me that I probably need to start learning how to mod Factorio.
However I’ll toss out an idea I don’t *think* I’ve seen yet (hard to be sure with so many posts).
Use roboports themselves for the network storage. They already store repair packs. And you can insert robots and repair packs in them. Remove logistics chests from the game and incorporate their functionality into roboports.
Roboports are already charge-port throttled. This could be genericized to dock-ports. This would severely limit throughput, but could be worked around by stamping more roboports down (and they are powered, so every roboport used for capacity is now costing power instead of being a small, cheap chest).
As this would severely limit bots, I would hope that we would get some sort of research to help boost this up (maybe adding additional docking ports for roboports, or speeding up the load/unload/charge phase of each dock).
This also makes it virtually impossible to use robots in an optimal beaconed block. I hope beacons would change along with this change. As it stands the only optimal beacon block either uses bots or belt weaving (which I actually never use because I consider it cheating).
However I’ll toss out an idea I don’t *think* I’ve seen yet (hard to be sure with so many posts).
Use roboports themselves for the network storage. They already store repair packs. And you can insert robots and repair packs in them. Remove logistics chests from the game and incorporate their functionality into roboports.
Roboports are already charge-port throttled. This could be genericized to dock-ports. This would severely limit throughput, but could be worked around by stamping more roboports down (and they are powered, so every roboport used for capacity is now costing power instead of being a small, cheap chest).
As this would severely limit bots, I would hope that we would get some sort of research to help boost this up (maybe adding additional docking ports for roboports, or speeding up the load/unload/charge phase of each dock).
This also makes it virtually impossible to use robots in an optimal beaconed block. I hope beacons would change along with this change. As it stands the only optimal beacon block either uses bots or belt weaving (which I actually never use because I consider it cheating).
Re: Friday Facts #225 - Bots versus belts (part 2)
Imagine building belts in layers from ground level and then -1 -2 -3 +1 +2 +3 with some kind of easy way of changing between the layers/views!GenBOOM wrote:indeedPurpleGreen wrote:when i read stacked belts ... i actually thought about something like this
this would be fantastic
Regarding bots, Its a flying intelligent thing, it makes sense it can do amazing things, but maybe the resource cost or resource upkeep of bots is to low compared to the throughput given. I mean how does the power efficiency look like between bots and belts? If bots have 5x the throughput of belts and more flexibility then maybe the power usage can reflect that.
Another suggestion is to introduce assembly-kits - that cannot be transported by bots due their to size and weight. A kit is a prepackaged box/pallet with all needed resources in the right ratios for a given recipe. The kit increases assembly speed as the kit is pre-organized, increases delivery throughput to assembler as it is one box with all resources in the right ratio. Finally belt throughput is also greatly increased as a kit can carry more resources in a smaller footprint compared to individual items. And of course kits introduce new challenges in terms of staging the kits on sub-assembly lines (filling up all need resources for a given recipe). Kits frames/boxes can be made of wood thereby being a sink for all that late game wood or they can be made of in metal and can be reused / re-purposed for different recipes. See some inspiration below:
Keep up the great work on this game!
Re: Friday Facts #225 - Bots versus belts (part 2)
One of the best solutions among others as Shados mentioned in his excellent review would be some sort of un/loading entity for trains. Just like a pump, but for solid items. But it should only deal with intermediate items from the 3rd tab.
Re: Friday Facts #225 - Bots versus belts (part 2)
I think that Worker robot cargo size is good research BUT it can be more expensive. Actually I like to see it as infinite research. Reason for that is that when you build mega base you still end up problem where robots eat all ups. With damn expensive research it will not ruin game at start but another hand at end UPS problems does not kill all fun if you have way to do things with less bots.
Re: Friday Facts #225 - Bots versus belts (part 2)
Many people complained that loaders were OP, now you're complaining that bots are OP. The logical solution is to finish loaders! They need to require power, have logistics support, and of course shiny new graphics.
This problem might be solved by having planet #2 be airless, which would prevent bots from working. Now a planet that is belt/train only would kind of suck, so the player could work (with belts/trains) towards indoor factories where bots could work. Problem solved without a nerf. In fact, what we get is something new (factories similar to Factorissimo).For example, the extension where you would expand to other planets, start there over, and once you achieve the rocket there, you would combine the production of the two planets somehow. But if starting on another planet just means playing with robots from the start, which means plopping a few cells of what you need and making a few mines, I don't see the point.
Re: Friday Facts #225 - Bots versus belts (part 2)
I would not mind Factorio going the way of Dwarf Fortress and implement Z-levels. However, without major changes it would completely trivialize belt logistics. It would be a major overhaul in gameplay.DesruX wrote:Imagine building belts in layers from ground level and then -1 -2 -3 +1 +2 +3 with some kind of easy way of changing between the layers/views!
-
- Manual Inserter
- Posts: 2
- Joined: Sun Jan 14, 2018 1:01 pm
- Contact:
Re: Friday Facts #225 - Bots versus belts (part 2)
First, thank for such a wonderful and addicting game. Kudos to everybody involved in the making of this awesome game.
I am sure that a lot of people do not want any nerfs to bots, but I do not mind. I was always troubled by how they move at the same speed regardless of how much of whatever they are carrying. A weight mechanic added to items that affects their movement speed can be an option. Another option would be to implement a smaller cap on number of bots per roboport. This may allow for an easier method of controlling bot throughput.
A long (length of current underground pipe) super express underground belt I think would be a nice addition along with an accompanying splitter. This belt can be used for main bus and other areas where suitable. Not sure how things work, but I am hoping that the belt being underground will help with UPS. Perhaps even make it so that inserters cannot pickup from or place items on these belts. Other existing belts can connect to these to either feed them or the output for inserters to pickup from.
I am sure that a lot of people do not want any nerfs to bots, but I do not mind. I was always troubled by how they move at the same speed regardless of how much of whatever they are carrying. A weight mechanic added to items that affects their movement speed can be an option. Another option would be to implement a smaller cap on number of bots per roboport. This may allow for an easier method of controlling bot throughput.
A long (length of current underground pipe) super express underground belt I think would be a nice addition along with an accompanying splitter. This belt can be used for main bus and other areas where suitable. Not sure how things work, but I am hoping that the belt being underground will help with UPS. Perhaps even make it so that inserters cannot pickup from or place items on these belts. Other existing belts can connect to these to either feed them or the output for inserters to pickup from.
Re: Friday Facts #225 - Bots versus belts (part 2)
Introduce weather! Bots can't fly in rain, storm or heavy winds
And if someone wants bots, it could be disabled in mapgen settings.
And if someone wants bots, it could be disabled in mapgen settings.
-
- Manual Inserter
- Posts: 1
- Joined: Sun Jan 14, 2018 11:48 am
- Contact:
Re: Friday Facts #225 - Bots versus belts (part 2)
Are you kidding?Robotuser wrote:20 Drones in real life cant fly in a direkt row because turbulence in the air, the danger of chrases...
This is not possible in real life.
This is a game, there is nothing to compare to real life. Everything is intentionaly simplified, so that you don't have to spend twenty years making an asembling mashine from sticks and shit.
Belts need power source in real life. You can't put a locomotive or 5 tons of metal (or whatever) in your pocket IRL. After all, you need to sleep, drink , eat and go shit sometimes. And you telling me, that bots can't fly in a row, because of the fucking turbulence in the air, realy?!
Re: Friday Facts #225 - Bots versus belts (part 2)
It's interesting to read that "Ok, bots are too powerful, let's also make belts more powerful!". I'm not sure that's the correct approach. I do understand that players can get angry if bots are nerfed too much though.
I have thoughts about how bots could be nerfed hopefully without upsetting players too much:
- Increase costs dynamically
Sort of like how research gets more and more expensive, recipes could also get more and more expensive. If you had 500 bots, the number of materials required to build a single bot would be multiplied by say 20. You could still expand your bot factory, but each bot would get more and more expensive so to expand it faster you need to increase your production of the ingredients for the bots.
If the mod API would support dynamic recipes in-game, I would build a mod for this.
- Remove a bot every now and then
Or some other kind of maintenance cost for robots, other than requiring electricity.
- Do not allow bot collisions (probably way too performance heavy unless you find a way to optimize it)
As mentioned by others, it is sort of unreasonable to have 500 bots within the same 10x10 area. Other options might include having to build air-paths for the robots or make air-shuttles to be able to use 100 robots in the same area.
I have thoughts about how bots could be nerfed hopefully without upsetting players too much:
- Increase costs dynamically
Sort of like how research gets more and more expensive, recipes could also get more and more expensive. If you had 500 bots, the number of materials required to build a single bot would be multiplied by say 20. You could still expand your bot factory, but each bot would get more and more expensive so to expand it faster you need to increase your production of the ingredients for the bots.
If the mod API would support dynamic recipes in-game, I would build a mod for this.
- Remove a bot every now and then
Or some other kind of maintenance cost for robots, other than requiring electricity.
- Do not allow bot collisions (probably way too performance heavy unless you find a way to optimize it)
As mentioned by others, it is sort of unreasonable to have 500 bots within the same 10x10 area. Other options might include having to build air-paths for the robots or make air-shuttles to be able to use 100 robots in the same area.
- 5thHorseman
- Smart Inserter
- Posts: 1193
- Joined: Fri Jun 10, 2016 11:21 pm
- Contact:
Re: Friday Facts #225 - Bots versus belts (part 2)
Bots require infinitely more power to run than belts, because belts require 0 power.DesruX wrote:I mean how does the power efficiency look like between bots and belts? If bots have 5x the throughput of belts and more flexibility then maybe the power usage can reflect that.
Making bots cost 5x the power as belts would make them cost 0 power.