... still ten times faster than with bots. + and - on numpad do help.ssilk wrote:You can make a blueprint and make pavement of 200x200 within seconds. Try that with the character: Running, running, running.hitzu wrote:I just want to ask one important question: who said that bots should be the best option for paving?In the begin it's fun, after some time it's ...
I mean why the bots? As you mentioned before, there could be other mechanics such as auto filling tool, or maybe something like self-replication device that uses blueprints. And why we even count the time? Why bots should make this task fast? Just because there is time limit for ghosts and the annoying sound when there is not enough materials and not enough bots? Let's just ask devs to make the exception for paving, delete this sound for the paving task and increase the lifetime of the floor ghosts. We even can ask to make the paving task priority low on the list so we can have access for construction bots at any time for other tasks that are more important for us at the moment. Let the bots work for a long time while we make our chores.ssilk wrote:You can make a blueprint and make pavement of 200x200 within seconds. Try that with the character: Running, running, running.hitzu wrote:I just want to ask one important question: who said that bots should be the best option for paving?
Look at the top of the page. It's right there in the title of the game.I just want to ask one important question: who said that bots should be the best option for paving?
Neat! Experiments like this are always fun and useful. I know when I was trying to concrete up an old base, I had to triple the number of roboports just to get enough charging stations on the field. Paving is a thirsty business.With that in mind, I performed an experiment.
I ordered a path of concrete roughly 300 units in size. I have over 150 construction bots so it should be two trips.
To be fair, the most effective and direct change is to increase the concrete laid down per trip. Doubling a bot's travel endurance affects everything. Construction bots already feel pretty good about building any other arbitrary thing so such a change is cooky at best. Doubling a construction bot's concrete load hits directly where the problem matters.To make construction bots feasible here we would need :
You would have to increase it to insane levels for bots to be feasible, by insane I mean bot carrying 100 units of concrete. 2,3 or even 5 would not help much. Take my experiment. In time that it took bots to place 150 tiles I placed 2.6k. Multiply the bots carrying capacity by 5 and you get 750 tiles vs 2.6k (and I had filled inventory so I could do much more than that if I went prepared).bobucles wrote:To be fair, the most effective and direct change is to increase the concrete laid down per trip. Doubling a bot's travel endurance affects everything. Construction bots already feel pretty good about building any other arbitrary thing so such a change is cooky at best. Doubling a construction bot's concrete load hits directly where the problem matters.
It's already pretty well established how false that is. First off, 150 construction bots is NOTHING. You can't expect anyone to take such a small fleet seriously. Secondly, you vastly under estimate the power of multiplying. Take 500 bots, each of them carrying 5 bricks. That's 2500 slabs of concrete down before the first recharge, which is nothing to scoff at.You would have to increase it to insane levels for bots to be feasible, by insane I mean bot carrying 100 units of concrete.
This!Adil wrote:Though when I was paving my base, I was okay with robots working day and night, until the ghosts of pavement started to die of old age.
Though I don't really think the player speed should be a reference. After all, player can place any other entity with the same outpacing of the robots, but they're used still.
I am really not in the mood to explain the same thing over and over again so let's just drop it. I wanted some improvement for player life, so we do not have to waste so much time, but now? I no longer care. I will just run back and forth or use a car or something. Not my problem.bobucles wrote:It's already pretty well established how false that is. First off, 150 construction bots is NOTHING. You can't expect anyone to take such a small fleet seriously. Secondly, you vastly under estimate the power of multiplying. Take 500 bots, each of them carrying 5 bricks. That's 2500 slabs of concrete down before the first recharge, which is nothing to scoff at.You would have to increase it to insane levels for bots to be feasible, by insane I mean bot carrying 100 units of concrete.
If your bots hauling concrete beyond their standard travel range or without adequate charging platforms, you've failed. Everything is slow when it's done poorly.
I'd argue that MapReduce is the wrong model here. In MapReduce, you are dealing with data, which you can replicate easily across sites. This is untrue for physical items, which Factorio simulates.ssilk wrote:I want to bring in another aspect into this discussion. It's maybe a bit hard to understand.
The problems we are facing here are very similar to problems managing large amounts of data, parallelization and especially comparable to the mapReduce model...
If you see the problem as map/reduce ( https://en.wikipedia.org/wiki/MapReduce ), then the operations for Factorio are:
- splitting up the tasks (place one item) on different robots
- the "reduce"-operation is to complete those tasks. For example to travel to point A, pick up an item, travel to point B, place an item.
When you look on, how really big machines do this task, then we need to think about the problem: What happens, if one bot fails. It could be something, perhaps I've take it accidentially taken down one bot. Perhaps some biter has eaten it.
Because of that most of such systems do actively create more reduce jobs, than they need, just for the case, that some node has break down meanwhile. Because there is a problem: If you do just exact so much reduce jobs, as you have tasks, and one of the reducers fail short before he has finished, then the whole queue needs to wait for this single task, which - in the end - double the total calculation-time.
What does this mean for our game?
Not really a thing that needs to be decided on the game-balancing side. The player can already bring the items closer to the task. Although some logistics-construction-interplay would be nice as in: logistics bots carry the items to the closest provider chest from which construction robots pick up the items (much like a broadcast model).ssilk wrote: - Reducing distances. Bring the items nearer to the targets (some ideas mentioned here). But also better ways to recharge (a flying recharger?), more intelligent pathfinding.
- More intelligent ways to spread items over the area (bring the stuff to the place, BEFORE it is needed); repair kits is most wanted, but the same is true for other stuff. More ways to split the robot-network (https://forums.factorio.com/forum/vie ... =67&t=8905)
I vote against that. Ghosts remain until built, so there is no real impact of losing a bot.ssilk wrote: - make the bots more reliable: Say for every 10 or 20th item they bring one more to the area, for the case, that one bot got lost. If the bot which brings it is too far away then it will be replaced with the one, which is more near.
I agree, and I see some quick wins here. An easy, first fix would be to compare total flight time, when assigning a task to a robot. That does of course mean that you'd have to order the list of robots for each task anew.ssilk wrote: - make the bots more intelligent: There should be a "working queue" for each bot with his estimated duration. If it is faster to add a task to a bot, which is at that time closer to the target than a free one, that is far away, why should the distant bot do it?
Good thoughts. Just to add to this specific little discussion: there are some unusual cases that might be challenging to solve. For example, sometimes a construction bot is waiting for another construction bot to come clear a tree before it can plop down the item it is carrying. In that case, flying distance is a very inaccurate estimate.SirRichie wrote:I agree, and I see some quick wins here. An easy, first fix would be to compare total flight time, when assigning a task to a robot. That does of course mean that you'd have to order the list of robots for each task anew.ssilk wrote: - make the bots more intelligent: There should be a "working queue" for each bot with his estimated duration. If it is faster to add a task to a bot, which is at that time closer to the target than a free one, that is far away, why should the distant bot do it?
You got the mod. It does exactly what you want. Just download and enjoy.roman566 wrote:I am really not in the mood to explain the same thing over and over again so let's just drop it. I wanted some improvement for player life, so we do not have to waste so much time, but now? I no longer care. I will just run back and forth or use a car or something. Not my problem.
Maybe a new Constructor chest type that only construction bots are allowed to draw from? I wouldn't want my system to withdraw items from my outpost recipe requester setup.bobucles wrote:I do agree that it is pretty difficult to set up a "stockpile" of local raw materials for your construction bots to use. Items get randomly thrown into storage chests and finished products won't always be where they're needed. IMO the best fix is to let construction bots dig into requester chests. That way you can throw construction materials exactly where they're wanted and get logistic bot support at the same time.
The alternative is to get super crazy with smart inserters and combinators. But I mean. The blue chest is already there.
Yes, of course. But what I wanted to explain is, how I can achieve more reliability in a task, which is massively parallelized. (By doing 1-10% more work).SirRichie wrote:I'd argue that MapReduce is the wrong model here.
This is difficult, but doable. Think to the colored-logistics model. https://forums.factorio.com/forum/vie ... =67&t=8905The player can already bring the items closer to the task.
It's not alone loosing a bot. Think to this: You place a blueprint. Parts of the blueprint can be built by personal robots. The other part is built by the local construction bots. Now things change and some logistic bots bring you (cause you requested them a while a ago) some items. They won't be used for construction, cause the bots are already on the way.I vote against that. Ghosts remain until built, so there is no real impact of losing a bot.ssilk wrote: - make the bots more reliable: Say for every 10 or 20th item they bring one more to the area, for the case, that one bot got lost. If the bot which brings it is too far away then it will be replaced with the one, which is more near.
Code: Select all
^
|
i |
t 40|
e | *
m 30| * *
s | * *
/ 20| *
s | * *
e 10| * *
c |* * <- The problem
-+----------------------------------------------/\/\/\/------>
10 20 30 40 50 60 80 some time
Code: Select all
^
|
i |
t 40|
e | .
m 30| . .
s | . .
/ 20| .
s | . .
e 10| . .
c |. .
-+------------------------->
10 20 30 40 time
Luckily making them more intelligent in path-finding this is in the devs todo-list. But I think not in 0.13.I agree, and I see some quick wins here. An easy, first fix would be to compare total flight time, when assigning a task to a robot. That does of course mean that you'd have to order the list of robots for each task anew.ssilk wrote: - make the bots more intelligent: There should be a "working queue" for each bot with his estimated duration. If it is faster to add a task to a bot, which is at that time closer to the target than a free one, that is far away, why should the distant bot do it?
With growing distance the bot needs to recharge and with that the last bot will need much more time. He finds the smallest bottleneck.SirRichie wrote:The chance for long delivery times does not grow with distance. There is no chance involved at all.
No, sorry, that is a much simpler problem.Sure, bots need to recharge and may queue up on a roboport. But that is just like having too few iron gear assemblers.
That is exactly, why we need a better reliability.Some part of the system stalls other parts. And it is the player's job to figure out what is going on.
Currently one of the least reliable aspects of construction is where the raw materials come from; basically all your construction materials are scattered everywhere. Storage will go into any random yellow chest, and the requester system doesn't allow access for construction bots. Addressing the latter will make a huge difference, as players will be able to request raw materials anywhere they please and dramatically streamline the travel time for construction projects.That is exactly, why we need a better reliability.