Concrete stacks way too low.

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

[bobucles]

Reducing travel time for goods isn't very difficult on the player end. For moderate distances place down requester chests, and fill them with concrete. Let the logistic bots do their thing and transform the chests to yellow when full. Taa daa, you just got twice the bots on the job, are making good use of cargo buffs, and cut construction time to a more linear growth.

For long distance heavy transport use supply trains, just like anything else.

Either way the major bottleneck is the fact concrete construction easily amounts to thousands of construction jobs, if not tens of thousands. Cutting down that number is a solid first step. For example if concrete works as a 2x2 tile like with train tracks, you just cut the job load by 3/4. Using the full 5 units of cargo cuts the workload 4/5. Do both things, and you've suddenly made construction bots 20 times more powerful at placing concrete. That's HUGE and likely more than adequate for giving a good feel to things.

Concrete is a material that gets placed by thousands of units at a time. Improving the stack size would be a nice thing.

[Klonan]

This is getting off-topic

This thread is about the stack size of concrete, not a discussion about the effectivity of construction robots and how they place entities/tiles

[ssilk]

TL;DR: I calculated it through and found my error. You're right: increasing the stacksize for that would help.

Longer explanation:

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?

Hum.
When I thought about it I saw, that theoretical you must be right: It's just linear.

But why do I feel, that the growth is quadratic? (You must know, that it is a very big part of my job to find performance issues. So I can say that: If I feel it is quadratic growth, then it is not just a feeling, it's based on my experience.)

I thought a lot about it this morning and here are my results: The growth is not really quadratic, but also not really linear. The reasons are
- with a a growing base the area grows quadratic to the perimeter. I mean: With a growing base a player needs to pave more and more area, if he wants to keep all paved -> quadratic growth
- the distance to the area, that needs to be paved grows linearly with an increasing factory -> linear growth
- upwards from a minimal distance to that area (if the factory gets bigger than some special size) the bots need to reload regulary -> linear growth
- with the distance the number of bots needs to raise. More bots, less time. -> linear deduction

So. When I thought about it here I thought: O. K. This is not really quadratic growth. Only the first point, but that depends on the players behavior and is not a game issue itself and that was for MY playing not the case. [I tested that very thoroughly: If you make equal areas and waited, until it is paved the next area in the same distance doesn't need longer. That was the point, where I suggested this https://forums.factorio.com/forum/vie ... 10#p109401 ]

Did I be really wrong? My feeling says it is non-linear but there is no obvious quadratic relativity to the distance here.
I came to the conclusion, that my feelings wheren't wrong. And so I continued to search.

The key-idea for me was, the last point: With the distance we need more and more bots. More bots in the logistic network hit a very special problem, because with the number of bots the chance rises, that a bot needs to wait before recharge.

I researched this behavior also very thoroughly - longer time ago, see down for more (*).
I don't want to write everything down now. Everybody has seen such situations: robots queue at one roboport, eventually begin to go to other roboports. Everything is queued. The robots begin to discharge completely and take much longer to recharge.

To make long things short, this adds chaotic growth!

I mean: the recharging works linearly up to a limit of X bots per second per roboport (the distance plays also a bit of rule), after that the waiting time/queue length rises eventual to minutes or even endless (the queue never releases any more). That it cannot resolve from this state has many reasons, for example that with the growing queue, the robots need more power and need longer for recharging. It depends on the number of bots and roboports and the amount of transport-work, not the distance. Sometimes one roboport more can release a situation, sometimes not, it depends on many factors.

What I saw feel, that it takes longer and longer was in truth the waiting time for the recharge.

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?

O. K. I meant with reducing the distance not to increase the travel speed. I meant really reducing the distances. There are enough ideas here:
- Say we have a "Zeppelin" (or a BIG TRANSPORT ROBOT, flying roboports or an UFO, or some other big flying object with much area), that brings the the needed things to the center of a destination area, that would radically reduce the distances.
- The mentioned thread brought in the idea of rockets, that sends stacks of items to the center of the building area by rockets.

But with my knowledge I learned now above, it is so, that indeed an increase of the stacksize would have the effect that you need not only 5 times less distance, but also 5 times less robots.

And that is the point! With 5 time less robots that idea will work, because with 5 times less bots you have a 5 times lower impact to the rechargers. And as I shown above: that will reduce the chance to behave chaotic drastically

--------------------------------
OFF-TOPIC

(*)
To explain that I need to introduce now some terms:
- transport-work: Item I needs to be transported to a point with distance D. Transport work is then I * D. Example: 1000 concrete tiles needs to be transportet 100 tiles. Transport work is 1000 * 100 = 100000 itemtiles.
- queue-waiting time or queue-length: The time a robot needs to wait before recharge
- charges per second: average charges of a roboport per second
- average recharge-distance: Distance a robot needs to travel before he can recharge

The rest can then be drawd on a paper. The result will look about so:

Code: Select all

        ^
        |                                       . . . .   <- non-resolving queue
  t     |                    # # # # # # # # #  
  i 1000|                    # # # # # # # # #
  m     |                    # chaotic area  #
  e     |                    # # # # # # # # #
     100|                    # # # # # # # # #   <- longer queues on roboports
  s     |                    #
  e     |              . . .
  c   10|       . . .                            <- more or less linear growth
        |. . .
       -+-------------------------------------------------------------->
                                                         transport-work

That is for example a network with 1000 bots. The interesting part is, where the chaotic area in this diagram begins: That is when I "feel" it behaves quadratic.

For 200 bots (5 times less) it will not happen:

Code: Select all

        ^
        |                                       
  t     |                    
  i10000|                    
  m     |                    
  e     |                                         . . . . . . . . . 
    1000|                             . . . . . . 
  s     |                     . . . . 
  e     |              . . .
  c  100|       . . .      
        |. . .
       -+-------------------------------------------------------------->
                                                         transport-work

Everything lasts of course much longer, but it behaves more or less linearly.

[bobucles]

This thread is about the stack size of concrete, not a discussion about the effectivity of construction robots and how they place entities/tiles

The discussion is still about concrete. It's just including a discussion on bots as well as manual plopping. After all, the main reason players lay concrete manually is because construction bots have so much trouble doing it!

ssilk brings up an interesting point. Bots recharge at the end of a small job, so the extra time spent on maintenance does not normally impact a typical task. Concrete laying is such a huge job no matter what, that huge swarms of bots will have to recharge their batteries along the way. This mid flight refueling will dramatically increase the time required to finish laying concrete. If the area has inadequate charging, the efficiency of the swarm will suddenly tank. It doesn't matter if you have a hundred or a thousand construction bots if they all have to wait in line for a recharge!

Once again the solution is to increase the efficiency of laying concrete. Charging stations won't be as big of a choke point as each individual charge moves more concrete. More efficient bots might even finish on the first pass, making the recharge time a moot point. A concrete job that finishes on the first pass would happen in mere seconds, compared it potentially timing out if the same job requires 2 or more breaks to recharge.

[roman566]

You know what would speed it up even more? Robots not having to fly through the entire factory but taking concrete from a storage next to the place where it is to be placed, but for that to work, player has to be able to carry it there. It would be very easy with an increased stack size, hint hint.

[bobucles]

Robots not having to fly through the entire factory but taking concrete from a storage next to the place where it is to be placed, but for that to work, player has to be able to carry it there.

You can haul long distance by train, plop down requester chests to exploit spare logistic power, or decentralize your concrete production. Extra player capacity is only a portion of the picture.

[Peter34]

This is getting off-topic

This thread is about the stack size of concrete, not a discussion about the effectivity of construction robots and how they place entities/tiles

No, actually.

The core of this thread was always the problem of getting the robots to cover large surface areas with Brick or Concrete. The OP's one proposed solution to solving that problem is to greatly increase stack size so that doing this one thing without the aid of bots becomes feasible, but that means it's still very valid to counter the OP's proposed solution by positing a bot-based one, which would indeed involve tweaks to game mechanics other than stack size. Especially since a bot-based solution to factory floor decoration (/improvement) is by definition much more in Factorio's spirit than a manual solution.

I like the suggestion to have Concrete (and Brick) cover a 2x2 area per shot. Already with that, that one swell foop, one bot can cover 4 tiles per trip instead of one.

Construction bots could also be changed to be able to carry 2 of the same item per trip. Now it's 8 tiles covered per trip. Or there could be a tech upgrade, separate from Logistic Bot slots, and costing more and progressing less aggressively, that gives Construction bots +1 twice to carry capacity, so that initially each bot can cover 4 tiles per trip, but fully upgraded 12 tiles per trip.

Or Construction Bot-carriable items could be divided into Small and Large, using Large for items like RoboPorts, Assembly Machines and so forth, and Small for Inserters, Walls, Bricks and Concrete and the various Electric Poles. Construction Bots then remain limited to always carrying only one item of Large classification, but for Small items their carry capacity equals that of the Logistics Bots, although they can only ever carry itentical items, e.g. 4 Medium Electric Poles, or 5 Stone Brick, or whatever the Logi Bot limit currently is.

[roman566]

Decentralizing production? WATER!!! If concrete did not require it, yeah, it would work perfectly. Place dozen factories next to the spot, have robots deliver bricks and iron, wait some time and start building. But it requires water. Which cannot be carried by bots. That means long and annoying pipe placing.

Trains work on long distance, because usually you can just blast everything between point A and point B. When the factory is between point A and point B, blasting it to pieces to lay down the tracks is not very cost-efficient. Building tracks around base just to carry concrete? Yeah... I think I will just run.

And we reach construction bots...

Ssilk assumed that bots have to fly for 100 titles... Out of curiosity I checked the distance the bots would have to travel. In my case the closer part of the construction would be between 500-700 tiles. 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.
While bots were flying to get concrete, I went there myself and grabbed a full inventory of it. Then I went back to the construction spot.
I started to build concrete path well before the first construction bot arrived. Having to recharge in mid flight decreased their efficiency enormously.
Then I started to place the concrete, 2.6k in a straight path.
I went back to see how bots are doing...
The answer? badly. Very, very badly. Not even half of it was done.

Construction bots are slower than player with PAMKII and on concrete. Much, much slower. They have to recharge midflight which increases the construction time. With more of them, the recharging cue goes bigger and bigger. Then they have to recharge on their way back. When the distance increases, they will have to recharge twice. Use logistic bots to carry it closer? They suffer from the same bottleneck as construction bots - roboports and recharging.

To make construction bots feasible here we would need :
1. Longer flight without recharging.
2. Special recharger that can affect dozens of bots at the same time AND do not require them to stop to recharge.
3. Ability to carry more than one item.
4. Moar speed! Bots should be much faster than the player.

Until at least three out of those four points happen, placing concrete with bots on large areas won't be feasible. That is why I am postulating to increase the size of concrete stack. When construction bots get a mayor upgrade the devs can roll back the size to 100, until that happens I would appreciate increasing that size.

[hitzu]

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

[ssilk]

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