Concrete stacks way too low.

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