Concrete and bots

[Xeanoa]

Well, we've all there to witness how atrociously inefficient contruction bots are at placing concrete. It blocks other constructions because of the sheer amount of jobs it can accumulate quickly.

I would like to see concrete(or any tile) to have a lower priority when the system checks where it can dispatch robots to. Iterate over all other ghosts first, if you still have robots without a job, send them off to build concrete.

[aRatNamedSammy]

or, an other option..as bots can carry more than 1 item at same time with upgrade, it could place more than 1 piece of concrete, depending on that upgrade

[Rseding91]

Iterate over all other ghosts first, if you still have robots without a job, send them off to build concrete.

You're not a programmer are you? That would be *horrible* for performance and is never going to happen.

[Roxor128]

I would like to see concrete(or any tile) to have a lower priority when the system checks where it can dispatch robots to. Iterate over all other ghosts first, if you still have robots without a job, send them off to build concrete.

Would be faster to just sort the build queue every 30 seconds and have the bots work through it in order.

[Rseding91]

I would like to see concrete(or any tile) to have a lower priority when the system checks where it can dispatch robots to. Iterate over all other ghosts first, if you still have robots without a job, send them off to build concrete.

Would be faster to just sort the build queue every 30 seconds and have the bots work through it in order.

"Sort" by what? Also again that would be horrible on performance if you had to touch every single thing every 30 seconds multiple times.

[ssilk]

An effective change would be, if construction bots could carry more items for construction at once. For example if the construction bots could carry 5 concrete instead of 1 it would build not 5 times faster but 10 or maybe 20 (!) times faster, cause the jam at the roboport would be much lower and more items can be placed at a time.

[Rseding91]

An effective change would be, if construction bots could carry more items for construction at once. For example if the construction bots could carry 5 concrete instead of 1 it would build not 5 times faster but 10 or maybe 20 (!) times faster, cause the jam at the roboport would be much lower and more items can be placed at a time.

That again would require the robot to know which jobs it should be working on which again would require it go over all of the jobs and check them. Which as I said before would be horrible for performance.

[ssilk]

Why? This can be much simpler:
When placing a blueprint/ghost: Count the number of "open" items, that needs to be transported by construction bots. Per chunk. For each item type. That needs to be done only when there is a change with the ghost-buildings.

When a construction bot is ready to pick up an item:
Is there are a large number of similar items in this chunk? Yes? About how many items are already picked up for this? Not enough? Then pick up more than one item. Increase also the counter for picked up items for this chunk.
Otherwise it uses the current algorithm.

When placed the first item: Do I have left more? Is there another item to be placed nearby? If not: search in other chunks. If not: Bring it back to a storage chest.

The trick is, that it doesn't need to be exact, cause in that cases it can use the current behavior.

In the worst case it is one IF more and the counter-stuff per item/chunk (but that seems to be really simple). But it spares in the best case 80% of bots, which reduces the CPU load also significantly.

[Rseding91]

Why? This can be much simpler:
When placing a blueprint/ghost: Count the number of "open" items, that needs to be transported by construction bots. Per chunk. For each item type. That needs to be done only when there is a change with the ghost-buildings.

When a construction bot is ready to pick up an item:
Is there are a large number of similar items in this chunk? Yes? About how many items are already picked up for this? Not enough? Then pick up more than one item. Increase also the counter for picked up items for this chunk.
Otherwise it uses the current algorithm.

When placed the first item: Do I have left more? Is there another item to be placed nearby? If not: search in other chunks. If not: Bring it back to a storage chest.

The trick is, that it doesn't need to be exact, cause in that cases it can use the current behavior.

In the worst case it is one IF more and the counter-stuff per item/chunk (but that seems to be really simple). But it spares in the best case 80% of bots, which reduces the CPU load also significantly.

Robots can only service things inside the logistic network they're part of. That means each built ghost has to be checked against the network coverage to see if it's acceptable for that logistic network to send a robot.

Logistic networks change and move around (the player/tanks/trains). Batching them per-chunk also doesn't work due to all of those reasons plus just outside a chunk might be another ghost so they would have to scan a 3x3 around every target they get which would be an even bigger hit in performance.

The proper solution is: just build more robots. It's easy, it works, and the performance works great.

[ssilk]

Ok, I think we need to bring up also game-play performance. That is, that the number of bots influence how crowed the roboports are.
This is what I see: Place one concrete takes 15 seconds. Place ten also.
Place 100 takes just a bit longer (20 seconds).
Place 200 takes just a bit longer (30 seconds).
Place 300: Uhhhhhhhhh... that takes hours. And my factory won't produce anything. Uahhhh. Why is this now so crowded?

I think this moment, when all roboports are so full, that the robots discharge while waiting and everything slows down is not a very good game element.
Plus: Factorio gameplay is slow and everything, which slows it down even more should be avoided.

In that perspective I think what is needed is some kind of solution to reduce the number of bots that wait for charging after placing mass of items, cause that cannot be foreseen by the player (other things can or they are not so critical or grow slower). Carrying more than an item would solve this issue effectively, but there are surely some more solutions.

[Rseding91]

Ok, I think we need to bring up also game-play performance. That is, that the number of bots influence how crowed the roboports are.
This is what I see: Place one concrete takes 15 seconds. Place ten also.
Place 100 takes just a bit longer (20 seconds).
Place 200 takes just a bit longer (30 seconds).
Place 300: Uhhhhhhhhh... that takes hours. And my factory won't produce anything. Uahhhh. Why is this now so crowded?

I think this moment, when all roboports are so full, that the robots discharge while waiting and everything slows down is not a very good game element.
Plus: Factorio gameplay is slow and everything, which slows it down even more should be avoided.

In that perspective I think what is needed is some kind of solution to reduce the number of bots that wait for charging after placing mass of items, cause that cannot be foreseen by the player (other things can or they are not so critical or grow slower). Carrying more than an item would solve this issue effectively, but there are surely some more solutions.

There's already a solution to that: build more roboports.

[Xeanoa]

There's already a solution to that: build more roboports.

How about making Roboports effective enough that you don't need clusters of 5-10 at a time?

[Mendel]

I would always just place concrete by hand. This is relatively fast when using increased brush size (with numpad +) and exoskeletons to run around placing stuff fast.

I guess I just haven´t encountered a real convincing situation where I should place concrete by robots.

[Roxor128]

I would like to see concrete(or any tile) to have a lower priority when the system checks where it can dispatch robots to. Iterate over all other ghosts first, if you still have robots without a job, send them off to build concrete.

Would be faster to just sort the build queue every 30 seconds and have the bots work through it in order.

"Sort" by what? Also again that would be horrible on performance if you had to touch every single thing every 30 seconds multiple times.

I feel stupid. I might feel less stupid if I knew how the ghost-build system worked, though.

I assumed it was just a list of things that need building, with subsets assigned to roboport networks in range, and so could be sorted by some field.

[ssilk]

There's already a solution to that: build more roboports.

Reseding, this is a stupid answer. Because with the same argument we could say that for logistic bots, too. And the result in gameplay when we remove the cargo stacksize bonus from the logistic bots would not be much more different than yet: We just need more roboports and bots.

I would say the stack-bonus for bots was intruduced to avoid having such many robots and roboports and - logically - this means this should (!) work for construction bots, too.

[Optera]

Make Roboports able to fast load 8 bots instead of slowly charge 4. Doesn't take any cpu time and considerably reduces up bot queues.

However that won't solve the issue of even some medium sized areas with ~2.5k floor tiles will take forever for bots to place down. For efficient blueprinting either tiles need to get lower priority than entities which is cpu intensive or give blueprints an option to not place tiles. That way you can stamp down only entities first and once they are built stamp down again with floors enabled.

[Stevetrov]

My ideas to solve these problems:

To have lower priority for concrete stone etc you cuold store the different ghosts in seperate queues one for high and one for low priority. The when a bot is available you only considerthe low prority queue when there is nothing else to do.

As for placing multiple concrete with one bot, you could make it so a concrete job is a 1xN strip of concrete, where N is the current carrying capacity. Then single bot can be assigned the whole job. This is a bit more fiddly and there are a few corner cases that would need to be handled. Like strips crossing roboport network boundary and bots not picking up enough to complete the job.

[ssilk]

I think this is a good idea, cause some time ago I also said, that there needs to be separate queues: For the roboports and power (must be first queue when constructing and last when deconstructing), the belts, trains, assemblies, chests etc.

[raidho36]

Bots are supposedly already checking the distance to find the nearest object to build. To put another way, they calculate the penalty for doing it and choose the action with smallest penalty. Just add a priority penalty during this step, which makes robot first consider all normal priority jobs since they have no additional penalty on them.

I can't believe someone made "it will hurt performance" argument over this. Are YOU a programmer, sir?

[Rseding91]

Bots are supposedly already checking the distance to find the nearest object to build. To put another way, they calculate the penalty for doing it and choose the action with smallest penalty. Just add a priority penalty during this step, which makes robot first consider all normal priority jobs since they have no additional penalty on them.

I can't believe someone made "it will hurt performance" argument over this. Are YOU a programmer, sir?

It's the complete opposite: a job finds the nearest robot. Robots don't find the nearest job.

Say you have 30,000 concrete to be built and the game goes to send a robot out. It has to check every single roboport to see if one can send a robot and then find the nearest job for it to be sent to. That would be 'count of robots' * 30,000 per robot sent checks. And then the next tick the same number of checks.

Compare to now it's: find robot in logistic network ('count of robots') -> dispatch.