Roboports

[xplycyt]

Can anyone explain why a roboport holds 350 but can only charge 4 at a time? This seems pretty silly and aesthetically challenging.

[Loewchen]

Because those two values have as much to do with one another as the amount of toast I can fit in my home vs how much I can heat up at a time.

[planetmaker]

Because those two values have as much to do with one another as the amount of toast I can fit in my home vs how much I can heat up at a time.

An now I wish a robot would deliver a steaming-fresh toast hawaii I like the comparison!

[netmand]

It's like owning an electric car (i.e. Tesla) and arriving at the parking lot which has 4 charging spots (that are taken) ... but lots of other empty spaces.

I've wondered why Roboports are the way they are too. There are no non-electric bots to take up those spaces.

The Borg have ports in every slot AFAIK.

[Premu]

It's like owning an electric car (i.e. Tesla) and arriving at the parking lot which has 4 charging spots (that are taken) ... but lots of other empty spaces.

I've wondered why Roboports are the way they are too. There are no non-electric bots to take up those spaces.

The Borg have ports in every slot AFAIK.

This setup makes sense if you use roboports only occasionally for construction or personal deliveries. With that you can still build a lot fast or get a lot of stuff quickly for a short time while getting away with the minimum amount of roboports to cover the whole area. If their batteries are enough they might do their job and reacharge slowly after having finished. Just don't expect it to work continuesly, for that you need far more roboports close by.

[Honktown]

You could increase the charge ports and increase the power delivery... be prepared for the 1 gigawatt recharges when a train stops in

[Impatient]

It is because the charge time is much lower than the time a bot needs to use that power, I guess.

[xplycyt]

It really is just a Factorio joke i guess. Just like when we were told there would be cake...

[pieterhulsen]

Because it would be very overpowered if they had more, without this limitation belts would be even further from the power of robots

[GlassDeviant]

This setup makes sense if you use roboports only occasionally for construction or personal deliveries. With that you can still build a lot fast or get a lot of stuff quickly for a short time while getting away with the minimum amount of roboports to cover the whole area. If their batteries are enough they might do their job and reacharge slowly after having finished. Just don't expect it to work continuesly, for that you need far more roboports close by.

This is why there are several mods that make changes to roboports or add new types.

[mrvn]

Can anyone explain why a roboport holds 350 but can only charge 4 at a time? This seems pretty silly and aesthetically challenging.

That raises the question: How many bots can a roboport charge in the time the bot uses up that power?

[Honktown]

That raises the question: How many bots can a roboport charge in the time the bot uses up that power?

Depends on speed, where it returns, etc. For even moderately sped up robots (like 100%) static cost becomes a rounding error, so at 5 kJ/"meter"? tile?:

Charging energy of a roboport is 1000kW (explicitly that). I don't see an explicit charge port count, but it has four charging offsets, which corresponds to four normal ports. It can charge at 5MW, so 4MW max deliverable is under that limit. 4/.005 = 800 meters per second. Base speed of construction bot is "0.06" (tiles per tick). Speed bonus before space science: 240% (from wiki). 800 / (60 * .06 * 2.4 * n) = n robots. 92.59 = n^2. 9.6 robots per second (is that right? it sounds reasonable, I didn't have /n the first time). Someone check my math.

[Koub]

Can anyone explain why a roboport holds 350 but can only charge 4 at a time? This seems pretty silly and aesthetically challenging.

That raises the question: How many bots can a roboport charge in the time the bot uses up that power?

viewtopic.php?p=428014#p428014
Also the whole discussion is interesting.

[BlueTemplar]

Because those two values have as much to do with one another as the amount of toast I can fit in my home vs how much I can heat up at a time.

An now I wish a robot would deliver a steaming-fresh toast hawaii I like the comparison!

Well, at least they can already deliver drinks !

[TruePikachu]

Because those two values have as much to do with one another as the amount of toast I can fit in my home vs how much I can heat up at a time.

An now I wish a robot would deliver a steaming-fresh toast hawaii I like the comparison!

Well, at least they can already deliver drinks !

Nothing like a steaming hot barrel of sulfuric acid!

[mrvn]

That raises the question: How many bots can a roboport charge in the time the bot uses up that power?

Depends on speed, where it returns, etc. For even moderately sped up robots (like 100%) static cost becomes a rounding error, so at 5 kJ/"meter"? tile?:

Charging energy of a roboport is 1000kW (explicitly that). I don't see an explicit charge port count, but it has four charging offsets, which corresponds to four normal ports. It can charge at 5MW, so 4MW max deliverable is under that limit. 4/.005 = 800 meters per second. Base speed of construction bot is "0.06" (tiles per tick). Speed bonus before space science: 240% (from wiki). 800 / (60 * .06 * 2.4 * n) = n robots. 92.59 = n^2. 9.6 robots per second (is that right? it sounds reasonable, I didn't have /n the first time). Someone check my math.

Your math is wrong. At least the unit "robots per second". The result should be just "robots". I think also dropped in an extra "n" in the last part. Should be 800 m/s / (60 ticks/s * .06 m/tick * 2.4) = 92.59 robots. Notice how the meter, seconds and ticks all cancel out.

But 92.59 seems a bit high. I don't think a single roboport can sustain 92.59 construction bots placing stuff all around it.

There should also be 2 answers to the question:

1) number of robots that can be charged without running out of power (unstable, any disruption will move into the second case)
2) number of robots that can be charged when they have run out of power and are waiting at the worst possible spot

The difference here being the time it takes the bots to move up to the charging pad. That time between the waiting positions and the charging pad is lost to charging and needs to be factored in too. So number 1 is the best case scenario and unstable. Number 2 is the worst case scenario but could recover to case 1 with some idle time.

[Honktown]

That raises the question: How many bots can a roboport charge in the time the bot uses up that power?

Depends on speed, where it returns, etc. For even moderately sped up robots (like 100%) static cost becomes a rounding error, so at 5 kJ/"meter"? tile?:

Charging energy of a roboport is 1000kW (explicitly that). I don't see an explicit charge port count, but it has four charging offsets, which corresponds to four normal ports. It can charge at 5MW, so 4MW max deliverable is under that limit. 4/.005 = 800 meters per second. Base speed of construction bot is "0.06" (tiles per tick). Speed bonus before space science: 240% (from wiki). 800 / (60 * .06 * 2.4 * n) = n robots. 92.59 = n^2. 9.6 robots per second (is that right? it sounds reasonable, I didn't have /n the first time). Someone check my math.

Your math is wrong. At least the unit "robots per second". The result should be just "robots". I think also dropped in an extra "n" in the last part. Should be 800 m/s / (60 ticks/s * .06 m/tick * 2.4) = 92.59 robots. Notice how the meter, seconds and ticks all cancel out.

But 92.59 seems a bit high. I don't think a single roboport can sustain 92.59 construction bots placing stuff all around it.

There should also be 2 answers to the question:

1) number of robots that can be charged without running out of power (unstable, any disruption will move into the second case)
2) number of robots that can be charged when they have run out of power and are waiting at the worst possible spot

The difference here being the time it takes the bots to move up to the charging pad. That time between the waiting positions and the charging pad is lost to charging and needs to be factored in too. So number 1 is the best case scenario and unstable. Number 2 is the worst case scenario but could recover to case 1 with some idle time.

Robots vs robots/sec just depends on whether or not we're counting time. I'd prefer a unit of robots/s because that's what we're looking for: max robots supportable* per second.

I originally got 90-whatever, but I felt it was far too high. I think there should be an "n-robots" term on both sides, since the robots chargeable per unit time is a dependent on the count of robots chargeable - a higher density means more energy consumed, curving down the amount we can support.

1v2 is a point, but if we're considering ALL factors, there's a minimum number of robots chargeable: moving things exactly at their round trip fast distance supported (most drain per trip/least time spent dilly-dallying) and the maximum: robots are going to a destination they can't reach, and are therefore taking the longest possible time to return to a roboport. I'd rather look for something at least approximately reasonable under general conditions - no slow travel, speed is high enough so that static cost is less than 5-10% total energy used, etc.

Edit: guess depends on how one looks at the problem. I'm thinking of "unit-of-work" kind of thinking. "n-per-roboport" is equally valid.

[mrvn]

That raises the question: How many bots can a roboport charge in the time the bot uses up that power?

Depends on speed, where it returns, etc. For even moderately sped up robots (like 100%) static cost becomes a rounding error, so at 5 kJ/"meter"? tile?:

Charging energy of a roboport is 1000kW (explicitly that). I don't see an explicit charge port count, but it has four charging offsets, which corresponds to four normal ports. It can charge at 5MW, so 4MW max deliverable is under that limit. 4/.005 = 800 meters per second. Base speed of construction bot is "0.06" (tiles per tick). Speed bonus before space science: 240% (from wiki). 800 / (60 * .06 * 2.4 * n) = n robots. 92.59 = n^2. 9.6 robots per second (is that right? it sounds reasonable, I didn't have /n the first time). Someone check my math.

Your math is wrong. At least the unit "robots per second". The result should be just "robots". I think also dropped in an extra "n" in the last part. Should be 800 m/s / (60 ticks/s * .06 m/tick * 2.4) = 92.59 robots. Notice how the meter, seconds and ticks all cancel out.

But 92.59 seems a bit high. I don't think a single roboport can sustain 92.59 construction bots placing stuff all around it.

There should also be 2 answers to the question:

1) number of robots that can be charged without running out of power (unstable, any disruption will move into the second case)
2) number of robots that can be charged when they have run out of power and are waiting at the worst possible spot

The difference here being the time it takes the bots to move up to the charging pad. That time between the waiting positions and the charging pad is lost to charging and needs to be factored in too. So number 1 is the best case scenario and unstable. Number 2 is the worst case scenario but could recover to case 1 with some idle time.

Robots vs robots/sec just depends on whether or not we're counting time. I'd prefer a unit of robots/s because that's what we're looking for: max robots supportable* per second.

I originally got 90-whatever, but I felt it was far too high. I think there should be an "n-robots" term on both sides, since the robots chargeable per unit time is a dependent on the count of robots chargeable - a higher density means more energy consumed, curving down the amount we can support.

1v2 is a point, but if we're considering ALL factors, there's a minimum number of robots chargeable: moving things exactly at their round trip fast distance supported (most drain per trip/least time spent dilly-dallying) and the maximum: robots are going to a destination they can't reach, and are therefore taking the longest possible time to return to a roboport. I'd rather look for something at least approximately reasonable under general conditions - no slow travel, speed is high enough so that static cost is less than 5-10% total energy used, etc.

Edit: guess depends on how one looks at the problem. I'm thinking of "unit-of-work" kind of thinking. "n-per-roboport" is equally valid.

robots/s makes little sense. That's just the charging speed / time to charge. For that to be useful you then also need to know how often a bot needs to charge.

The question for me was: How many robots can you stage at a roboport without a queue building up?

Note: 1v2 isn't about bots running out of energy out in the wild. That happens too but then your roboports aren't planted dense enough. I ment the case that a robot has arrived at the roboport in the outer ring where bot wait to charge and runs out of energy right that tick. Even in that case I want no queue forming around the roboport (assuming bots arrive at a constant rate).

[Honktown]

...

We may both have calculated wrong.

With 4 logistic robots being delivered 4 MW total, for no queue to form, the remaining robots can consume power at most at a rate of 4MW. With 5kJ/m as the consumption of logistic bots, and speed as S, the remaining bots supportable n, the equation would be is 4 MW = .005 MJ/(meter-robots) * ( S m/s) * n robots for logistic bots. For 240% speed and a base rate of 3 tiles (meters) per second, that's 4 = .005 * (2.4 * 3) * n., 4 = .036n, ~111 = n, for a total of 111+4 = 115 bots. For 240% bonus speed and a base rate of 3 tiles (meters) per second, that's 4 = .005 * (3.4 * 3) * n., 4 = .051n, ~78 = n, for a total of 78+4 = 82 bots. The general equation would be n = [800/(3 * (1 + percent speed bonus))] + 4. Does that sound right? Needs testing. At infinite speed, that goes to 4 bots supportable, which makes sense.

[Nemo4809]

Maybe the charging port count and charging in general is to limit the range of the bots.

You can have 350 construction bots and have it dismantle a 350 piece structure nigh instantly - although they all have to charge before returning into the roboport.

Transporting 350 items over long distances via logistic bots though would be very slow as they have to keep recharging along the way with only 4 ports per roboport.