Concrete stacks way too low.

[roman566]

I just want to ask one important question: who said that bots should be the best option for paving?

You can make a blueprint and make pavement of 200x200 within seconds. Try that with the character: Running, running, running. In the begin it's fun, after some time it's ...

... still ten times faster than with bots. + and - on numpad do help.

[hitzu]

I just want to ask one important question: who said that bots should be the best option for paving?

You can make a blueprint and make pavement of 200x200 within seconds. Try that with the character: Running, running, running. 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.

[StoneLegion]

I made a silly mod because this thread. If it's such a big deal use the mod. If you don't want to use the mod or refuse then I think you should make a post how modding should be removed

https://forums.factorio.com/forum/vie ... 94&t=16622

[bobucles]

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.

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.

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.

To make construction bots feasible here we would need :

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.

[roman566]

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.

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]

You would have to increase it to insane levels for bots to be feasible, by insane I mean bot carrying 100 units of concrete.

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.

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.

[Adil]

Well, concrete paving could use a buff, really.
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.

hm, maybe a special type building, might look good: the robot places a single tile entity, which starts to rumble and whistle and covers like a hundred tiles around it before self-deconstructing or self-destroying.
I'd do that eventually, unless someone manages that before I get around to this stuff. (That's what I've wrote this idea for. Might be a bit of a wait otherwise.)

[hitzu]

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.

This!
Robots are fine. The decay of ghosts and the annoying sound aren't.

[ssilk]

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?

To plate such many stuff in a reliable time needs more than just a bigger stack-size for the bots.
(The same problem is with blueprints in general: You wait for a single pole, which connects the whole blueprint and it comes with the very, very last bot.)

And reliability plays the biggest role in the whole process of planning a factory. You don't need to think in "I can place this, then I can place that". You want to think also in "The first task needs maximum 1 minute, the second 10 seconds.". Something like this is needed to plan ahead, because if you cannot know how much time a task takes you cannot search for alternatives.

So my list of things, that needs to change/added to solve those problems now and for all time:
- Adding stacksize is a good start.
- 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)
- 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.
- 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?

[roman566]

You would have to increase it to insane levels for bots to be feasible, by insane I mean bot carrying 100 units of concrete.

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.

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 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.

[SirRichie]

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?

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.
Also, the task is already heavily parallelized by assigning one robot per concrete tile.
But while I think the model is wrong, the conclusions you draw are in the right direction.

- 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)

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).

- 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 vote against that. Ghosts remain until built, so there is no real impact of losing a bot.

- 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?

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.

[TimmPure]

- 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?

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.

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.

[hitzu]

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.

You got the mod. It does exactly what you want. Just download and enjoy.

[bobucles]

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.

[lancar]

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.

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.

[ssilk]

I'd argue that MapReduce is the wrong model here.

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).

The player can already bring the items closer to the task.

This is difficult, but doable. Think to the colored-logistics model. https://forums.factorio.com/forum/vie ... =67&t=8905
That is exactly thought for that. Also adding new types of chests, which was also suggested many times. The problem is from the game-play view: Does it make fun to optimize this? Is it needed?
Isn't it much better to let the game optimize this part? Isn't it clever to say "This should just work in the very best way".

- 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 vote against that. Ghosts remain until built, so there is no real impact of losing a bot.

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.
And such situations happen quite often in different constellations. If you draw it on a curve it will look like so:

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

Y-Axis are delivered items per second. X is time. X-Axis is very dependend on distance, see the seconds just as "may take longer if more distant". The problem are those bots, that "take too long". Those, which need to wait at each roboport for example. Or those, which where already too far away when requested. You have not always such bots, but with rising distance and amount of items the chance grows very fast. They disturb the delivery in a way, which makes it "unreliable". Unreliability is bad, because that leads to non-calculable waiting times.

In other words: Me as player cannot optimize here. For a game about optimizing delivery it's just bad game-play. And for the case, that optimizing this should not be a players job: The game behavior is really bad here.

For me, to take fun out of this, this must look more like so:

Code: Select all

        ^
        |
  i     |
  t   40|
  e     |      .
  m   30|    .  .
  s     |   .    . 
  /   20|         .
  s     |  .       .    
  e   10|  .        .
  c     |.           . 
       -+------------------------->
              10    20    30    40   time

With this I can begin to optimize the transport, bring for example the items more near to the target.

- 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?

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.

Luckily making them more intelligent in path-finding this is in the devs todo-list. But I think not in 0.13.

[bobucles]

When is a construction bot ever going to swipe an intermediate? They only build finished goods, and only when the player asks for them. So there is no conflict with letting them grab from blue chests.

[SirRichie]

In addition: I still do not get the point about unreliability or long delivery times, which is a better description.

The chance for long delivery times does not grow with distance. There is no chance involved at all. Sure, bots need to recharge and may queue up on a roboport. But that is just like having too few iron gear assemblers. Some part of the system stalls other parts. And it is the player's job to figure out what is going on. It is a core concept of Factorio.

[ssilk]

The chance for long delivery times does not grow with distance. There is no chance involved at all.

With growing distance the bot needs to recharge and with that the last bot will need much more time. He finds the smallest bottleneck.

Hm. Maybe that is a good comparison: If I want to find bottlenecks in my factory, then it is easy with belts, but really difficult with logistic bots. They are not reliable enough to be sure, that I will find the right bottleneck.

In other words: If you want to optimize the factory you make a change and then measure (I do look, how the things are behaving now, is it better and why?). But if the system you change is too strong dependent on the system you won't change this job is difficult.

Sure, bots need to recharge and may queue up on a roboport. But that is just like having too few iron gear assemblers.

No, sorry, that is a much simpler problem.

Some part of the system stalls other parts. And it is the player's job to figure out what is going on.

That is exactly, why we need a better reliability.

[bobucles]

That is exactly, why we need a better reliability.

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.

If you can set up a blue chest on the perimeter to stash 5 laser turrets, 10 wall pieces, and a dozen repair packs, base repair goes from "wait 2-10 weeks for delivery" to basically instant. Planning on a huge concrete binge? Well just drop a chest, request it full of 2000 concrete, and let bots do the rest. EZPZ.