Factorio Forums

Loewchen wrote: Wed Jan 15, 2020 3:12 am 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.

netmand wrote: Wed Jan 15, 2020 3:14 pm 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 wrote: Wed Jan 15, 2020 5:08 pmThis 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.

xplycyt wrote: Wed Jan 15, 2020 2:39 am Can anyone explain why a roboport holds 350 but can only charge 4 at a time? This seems pretty silly and aesthetically challenging.

mrvn wrote: Thu Jan 16, 2020 11:56 am That raises the question: How many bots can a roboport charge in the time the bot uses up that power?

mrvn wrote: Thu Jan 16, 2020 11:56 am

xplycyt wrote: Wed Jan 15, 2020 2:39 am 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?

planetmaker wrote: Wed Jan 15, 2020 2:09 pm

Loewchen wrote: Wed Jan 15, 2020 3:12 am 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!

BlueTemplar wrote: Thu Jan 16, 2020 1:06 pm

planetmaker wrote: Wed Jan 15, 2020 2:09 pm

Loewchen wrote: Wed Jan 15, 2020 3:12 am 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 !

Honktown wrote: Thu Jan 16, 2020 12:23 pm

mrvn wrote: Thu Jan 16, 2020 11:56 am 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.

mrvn wrote: Mon Jan 20, 2020 10:55 am

Honktown wrote: Thu Jan 16, 2020 12:23 pm

mrvn wrote: Thu Jan 16, 2020 11:56 am 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 wrote: Mon Jan 20, 2020 11:27 am

mrvn wrote: Mon Jan 20, 2020 10:55 am

Honktown wrote: Thu Jan 16, 2020 12:23 pm

mrvn wrote: Thu Jan 16, 2020 11:56 am 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 wrote: Mon Jan 20, 2020 12:55 pm ...