Concrete stacks way too low.

[ssilk]

The idea was about outposts. Where you don't have a connected logistic network.

The problem with placing the stones/concrete is also a different: In my opinion in the beginning it's nice and I think people will do it a lot. But it gets a little bit boring after some time.

What I would like would be, that the computer places the concrete for me. I make the borders and a "device" looks for empty space and places the concrete inside of it.

@bobbingabout: With the speed it is so: The bots are not thought for this and even with the double speed they will not be much better for this job. Even with five times more stacksize: Not thought for that!
The problem are the long distances they need to travel around. That immediately locks all the bots for this one job. As said: Not thought for that.

[Klonan]

I think balance wise, it makes sense for concrete to stack to 200

Lets see:

Stone = 50
Stone Brick = 100
Concrete = 100

But for instance, for another production chain:

Copper ore = 50
Copper plate = 100
Copper wire = 200

or even

Iron ore = 50
Iron plate = 100
Electronic circuit = 200

[bobucles]

I have around 5000+ logistic robots MK4 (They're like, 4 times the speed of normal ones) and just as many construction robots.

It's a bit telling that you need to have an order of magnitude extra construction power to handle concrete, compared to trying to place factory blueprints.

[lancar]

200 should be fine, I think. 100 is too low, I agree. Same goes for Bricks (for consistency, since they're used for pavement too).

[keyboardhack]

We are still talking about enough concrete to fill an entire tile which is quite a lot. You don't need a lot of robots to place concrete in a short amount of time. 50 robots can lay a quite large field of concrete in a very short time. This is factorio and if something becomes repetitive then there is ways to automate it.

[hitzu]

We are still talking about enough concrete to fill an entire tile which is quite a lot. You don't need a lot of robots to place concrete in a short amount of time. 50 robots can lay a quite large field of concrete in a very short time. This is factorio and if something becomes repetitive then there is ways to automate it.

Ok, let's do some rough math.
Imagine we have one roboport that construction area covers 100x100 tiles. I will not bother with circles and will calculate "radius" for sqares. We have 4 tiles at a distance 1 sqare from the center, 12 tiles at the distance 2, 20 tiles at the distance 3 ... 396 tiles at the distance 50. Let's multiply all 10k tiles by their distances from the center and then multiply by 2, because robots must return to pick up new piece of material. We got a magic number 676600 - the total number of squares that bots should travel back and forth. Divide it by 50 robots and by 3.6 tiles/sec (this is fully upgraded robot speed according to wiki). We've got 3759 seconds or 63 minutes.

Sounds quite confusing even for me. I shrank angular distances, assuming that they are just one tile lenght, but in reality they should be longer and I didn't count the time when robots recharge so the total construction time should be even greater...
I am a bad mathematician

[SirRichie]

Thank you for that estimate using real grounded data!

As it is now, that obviously is too much. You might of coures increase your construction bots to 200, which would bring down the time to about 63/4 = 16 minutes, which is still a lot and usually longer than ghosts live.

If you were to be able to utilize the stack size of robots (as I suggested) this would now become 16/5 = 3.2 which is an ok number I think.

[Melfish]

The problem i had with construction robots was the robotport, as it just cant handle the amount of robots.
A 10x10 area requires 100 robots...
I tried to add extra ports (almost tripled them) but just ended up placing everything myself.

[ssilk]

We've got 3759 seconds or 63 minutes.
Sounds quite confusing even for me. I shrank angular distances, assuming that they are just one tile lenght, but in reality they should be longer and I didn't count the time when robots recharge so the total construction time should be even greater...
I am a bad mathematician

Even if the mathematics would not be super-correct, that matches with my experiences: it is impossible to built large areas of plates by bots, even if you have gigantic amounts of bots.

As I said: The better way would be to have a device which looks,

- are enough construction bots available and if so
- it marks a small area (5x5 or 10x10?) for construction of stone/concrete.
- Then it repeats until the whole area is filled.

Which means also: I need to mark only the boundaries. Like in MS-Paint: Make an closed area and then select the "fill"-tool. All withing this area is filled with the wanted stuff. So I suggest a "fill"-tool for Factorio.

[lancar]

The most straightforward solution for the deployment speed would just be to add research for construction robots to carry more than one item, just like Logistics.

[Klonan]

The most straightforward solution for the deployment speed would just be to add research for construction robots to carry more than one item, just like Logistics.

Actually construction bots carry more than 1 item, for instance if you deconstruct a chest, the bots will carry multiple items from that chest into storage, its just doesn't work when placing items down

[SirRichie]

Actually construction bots carry more than 1 item, for instance if you deconstruct a chest, the bots will carry multiple items from that chest into storage, its just doesn't work when placing items down

Which is exactly the problem...

[ssilk]

The most straightforward solution for the deployment speed would just be to add research for construction robots to carry more than one item, just like Logistics.

As said, that would not solve the problem. See calculation above. The problem is not much better, if the bots take 5 times less, it then takes only 12 minutes instead of 60.

Hmmm. This is a bit far related, but I try it:

Informatics has a concept called "complexity". The situation in this case is O(n^2) (complexity rises quadratic with the size of to placed plates). Introducing a 5 times bigger stacksize bonus makes it to O(n^2 / 5). Which can then immediatelly replaced with O(n^2) (because on the long term "/5" shortens out).

What we need is a complexity more like O(log(n)).

http://stackoverflow.com/questions/2307 ... an-exactly

Actually construction bots carry more than 1 item, for instance if you deconstruct a chest, the bots will carry multiple items from that chest into storage, its just doesn't work when placing items down

It's then not an item, it's an entity. The stacksize bonus for bots is about items, not entities.

[roman566]

The bottom line is that construction robots are bad at making large paths of concrete. Hence why player has to do it by hand and that's why I am postulating to make it easier and increase the size of concrete stack to 1k.

[bobucles]

The problem is not much better, if the bots take 5 times less, it then takes only 12 minutes instead of 60.

But that is in fact an ENORMOUS change. There are no other items that have to be mass constructed like concrete, it is clearly an order of magnitude above anything else. Cutting the construction time to 1/5 means 500 bots tomorrow do the work of 2500 bots today. That is nothing to scoff at.

In terms of raw calculations, concrete is rarely placed in single file. It is frequently done as huge build requests, which means assigning bots is EASY. Just assign the construction requests <stacksize> at a time instead of 1. The bots will roll out a small line of concrete before returning to base. Taa daa. Bonus points for actively assigning adjacent concrete requests, though it's not really necessary.

[hitzu]

The problem is not much better, if the bots take 5 times less, it then takes only 12 minutes instead of 60.

But that is in fact an ENORMOUS change. There are no other items that have to be mass constructed like concrete, it is clearly an order of magnitude above anything else. Cutting the construction time to 1/5 means 500 bots tomorrow do the work of 2500 bots today. That is nothing to scoff at.

The reality would be worse. Having 5 items in a pocket of a bot doesn't mean that all 5 of them will be placed simultanously. Moreover every bot have in its memory just one task at a time, so after placing one piece of concrete robot will take another task and I'm sure he will choose the most remote place to travel.
I suspect the time gain would be about 200-250% but not 500%.

[SirRichie]

ssilk, if you are going to do complexity analysis, then please do it right:

• you have to define what n is. Since you end up with n^2, I assume your n is the edge length of the square that is placed. I'd suggest n to be the number of concrete tiles, but let's assume it is the edge length.
• You are right in that the overall complexity class is not O(n^2), because you will end up with n^2 tiles to fill with concrete. Assuming that each tile takes the same amount of time to fill (roughly speaking) let's you end up with O(n^2) time complexity.
• Coming up with something with O(n logn) time complexity is the natural reflex of a computer scientist who has dealt with complexities before. But this is not computer science, it is game design. The implication of O(n logn) time compared to O(n^2) tiles (no way around that... a square is a square) would mean that the more tiles you put in a blueprint, the quicker the bots place each tile. Now that sounds weird
• It is right that constant factors are taken out of consideration when talking about complexity classes, because their influence diminishes in the long run. But n=100 is not really "the long run" (that's more like n >= 100000). Thus, the constant factor (/5) does play a significant role, as our 12 minutes instead of 60 minutes (or bobocules 2500 bots) show very well.

The reality would be worse. Having 5 items in a pocket of a bot doesn't mean that all 5 of them will be placed simultanously.

Why not? Why can't they place them on adjacent tiles?

Moreover every bot have in its memory just one task at a time,

Says who? Even if true: why can't a task be "place 5 concrete tiles"?

so after placing one piece of concrete robot will take another task and I'm sure he will choose the most remote place to travel.

Any proof for that assumption? At the moment, the closest bots will serve construction requests. So it is easy to make them serve the closest tile.

The problem is not much better, if the bots take 5 times less, it then takes only 12 minutes instead of 60.

But that is in fact an ENORMOUS change. There are no other items that have to be mass constructed like concrete, it is clearly an order of magnitude above anything else. Cutting the construction time to 1/5 means 500 bots tomorrow do the work of 2500 bots today. That is nothing to scoff at.

In terms of raw calculations, concrete is rarely placed in single file. It is frequently done as huge build requests, which means assigning bots is EASY. Just assign the construction requests <stacksize> at a time instead of 1. The bots will roll out a small line of concrete before returning to base. Taa daa. Bonus points for actively assigning adjacent concrete requests, though it's not really necessary.

100% agreed

[hitzu]

Ok, let's assume that new bots have larger pockets and their AI is rewritten. I suppose that you don't want to limit this only for concrete ans stone, otherwise it would look stupid and will lead to the tons of forum whining, right? So now our bots can carry any 5 entities at the time - assemblers, belts, inserters, rails Etc. Our bots became 5 times more powerful for every task. This would break the balance, but we could fix this by making them more expensive and more power consuming, just like it was with 0.12 turrets. So now we have less bots because we connot produce them as much as earlier, that is good for CPU, but 10 bots would work as fast as 50 old bots. But the problem is still here - you can reduce the work time only by increasing the number of bots, just as earlier. Nothing changed except the number of bots and btw we made non improved bots weaker.

[ssilk]

you have to define what n is. Since you end up with n^2, I assume your n is the edge length of the square that is placed.

No. I said already it's far related.

N is for me the number of items to be placed and N^2 is for me the fact, that the travel-time for the bots behave like so with growing radius/distance.
For me it is just a picture I misuse here. Sorry for that.


I only want to reflect with this (bad) example, that this problem can be compared a bit to complexity in informatics and that there is basically no difference if you do a job 5 times faster, because it helps a bit, but is still too slow. It needs to grow "somehow logarithmic" instead of "somehow quadratic".

The logical conclusion is: we need to decrease the travel-time, and not increase the amount of transported items. The personal roboport for example is exactly made to fulfill that.

But for the other constructions like here the personal roboport is not useable; I saw that already half a year ago coming and that brings me to https://forums.factorio.com/forum/vie ... =5&t=13200

[SirRichie]

N is for me the number of items to be placed and N^2 is for me the fact, that the travel-time for the bots behave like so with growing radius/distance.

Ok, you say that you used complexity as a metaphor, I understand that, because above statement is somewhat off.
Yes travel time increases, but in a linear way, so speaking with complexity, you'd say that if N is the distance, then the travel time has complexity O(N).

and that there is basically no difference if you do a job 5 times faster, because it helps a bit, but is still too slow. It needs to grow "somehow logarithmic" instead of "somehow quadratic".

I really think it makes a huge difference. Taking 12 minutes instead of 60 is a huge difference for me. Also, what do you say grows quadratically?

The logical conclusion is: we need to decrease the travel-time, and not increase the amount of transported items.

I do not get that. You say that making the placing of items 5 times faster (due to the stack size) does not really solve the problem, because it is a constant divider. But you suggest increasing the travel speed, by... say... a factor of 5. So again you'd make things 5 times faster, resulting in the exact same time benefit.
Where is the difference?