Scale worker robot speed research

[Qon]

P.S. In case it wasn't clear, when I say "prioritize by level of discharge" I mean the bots with less charge remaining go first.

Don't you want bots with more charge to go first? They have more to lose by waiting. The bots with low or 0 charge don't use energy (or don't soon) so if they wait longer it doesn't get worse over time.

But does this theoretical issue have practical consequences? In what factory is higher speed research an actual measurable drawback?

[BlakeMW]

I kind of agree that it'd be nice to have a efficiency improvement on the higher level speed techs, it doesn't have to be a huge amount.

-5% per infinite robot speed would be "throwing a bone" without really solving the problem, so that'd good if the problem should stay a problem but becoming slightly less of a problem.
-10% per infinite robot speed would do much more, because then after researching 5 levels the robots would be using half as much juice, that's significant.

Presumably it'd be capped to -80% like efficiency modules so at some, actually absurdly high, level it'd stop providing efficiency bonuses.

[Qon]

I kind of agree that it'd be nice to have a efficiency improvement on the higher level speed techs, it doesn't have to be a huge amount.

-5% per infinite robot speed would be "throwing a bone" without really solving the problem, so that'd good if the problem should stay a problem but becoming slightly less of a problem.
-10% per infinite robot speed would do much more, because then after researching 5 levels the robots would be using half as much juice, that's significant.

If that's for logistics bots also then 50% energy saved would mean you can also reduce number of roboports by 50% (simplifying base design) or you get 200% the throughput.
Or for -80% you get away with 20% the number of roboports or 500% throughput.

I'm against buffing logistics bots throughput to 500% of the current values. Not only do they already have like 5 times the throughput compared to belts already but they also make base design even simpler.

[Theikkru]

Don't you want bots with more charge to go first?[...]
But does this theoretical issue have practical consequences? In what factory is higher speed research an actual measurable drawback?

The practical problem to be addressed is the case where a large number of robots arrive at a roboport in a random order with different levels of charge. With first-come-first-serve, it's possible for some low charge robots to get unlucky with queueing and end up far back enough that they drain out while waiting in line (which then clogs up the charging queue because that discharged bot takes forever limping onto the charger, possibly causing cascade starvation). Robot speed research causes bots to queue up at roboports more frequently (since they spend less time in transit), making it more likely that that happens. The reason this is a significant problem is that it's entirely dependent upon the effectively random order in which bots arrive at port, and is therefore outside user control.

The queue prioritization fix addresses that problem. The idea is that with discharge prioritization, if it is at all possible to charge all the bots before any of them run out, ordering by lowest charge first will guarantee that that happens, regardless of their order of arrival (so speed research no longer matters), since the bots that are going to run out first get charged first. This makes charging behavior a lot more reliable, in that the only times bots would be drained in queue is if they either drained on the way there, or the roboport is completely overloaded with queued bots, and there was no possibility it could have been prevented. Both of these cases are clear red flags that there are not enough roboports to handle the situation, so drained bots become a good indication of failure (as opposed to just a random occurrence).

Ordering by greatest charge first would actually be less efficient and more problematic. It would be less efficient because bots with more charge would have to swap in and out of the charger at far greater rates than those with less charge, so more roboport time is wasted on what is effectively a form of thrashing (see my previous post for the mathematical equations on this). Worse, it would be problematic because robots that have drained are shunted to last priority, and if that roboport has any significant amount of sustained traffic, they could be stalled out indefinitely in queue. If any of those robots happen to be holding an important item, that would consequently stall the delivery of that item indefinitely as well.

In short, lowest charge first is a try hard, fail fast order, whereas highest charge first fails gradually over a wide range of workloads (in both directions). As any computer software or systems engineer will tell you, the former is preferable.

[Qon]

Robot speed research causes bots to queue up at roboports more frequently (since they spend less time in transit), making it more likely that that happens.

Wrong. That's only true if you keep using the same amount of bots, that means scaling up your orders for your logistics bots to have higher throughput when you research higher speeds. It is true from the perspective of the bots, yes. But that is irrelevant since the frequency of the bots visiting the roboport stays the same (or decreases a tiny amount since bots can fly farther) with a constant load because less bots will be active to complete your orders.

If you increase throughput then yes you will increase load on your roboports, but that is true regardless of speed research. Analyze from the perspective of the factory/roboports and not from the perspective of the bots.

Skimming through the rest of your post I see that it is your attempt at trying to solve this irrelevant non-problem so I won't address it.

[Theikkru]

The total workload on the roboport is the same or slightly lower, but it is not distributed the same; because the bots fly faster, they make it back to the roboport faster (and closer in time to each other), so they will spend more time queued at the roboport (rather than in transit) because the roboport's rate of charging and handling the bots does not change. 300 bots that arrive at port over 10 seconds will spend less total time in queue than if they arrive over 5 seconds. This concentration of bots at the queue is what causes the problem.

Also, the problem I'm addressing is a general inefficiency regarding roboport queueing behavior, so while you may argue whether or not worker robot speed research worsens it, it is inappropriate to summarily dismiss the queueing problem itself as non-existent without understanding it.

[bobucles]

The practical problem to be addressed is the case where a large number of robots arrive at a roboport in a random order with different levels of charge.
...
...
In short, lowest charge first is a try hard, fail fast order, whereas highest charge first fails gradually over a wide range of workloads (in both directions)

The ideal outcome is to pick bots with just barely enough energy to dash to the charge pad. Skip all bots below the threshold (they will crawl and slow things down), and continue queueing bots above the threshold. Unfortunately it sounds like a pretty dumb algorithm, because it means searching for low charge (but not TOO low) bots all the time. Sorting a list is FAR more expensive than walking through a queue with no conditions so as far as solutions go it's pretty bad.

All of a charging pad's lost time is a result of the "next in line" bot needing to travel the distance to the pad. A simpler solution is make sure the next bot is closer to the pad to begin with. If the next bot is inches away from the charge pad, its speed doesn't matter. The queued bot will hit the pad in no time and charger inefficiency becomes moot. In terms of game design there would effectively be 4 "ghost" charging pads directly behind the real pads. Extra bots will fill those slots and wait for their ghost's pair to become ready. The UPS cost is not too bad because each charge event moves a pair of bots instead of one, but obviously there is more work involved. It also may not solve the slowest of bots, but it will reduce the most painful scenario by roughly half.

[Theikkru]

The ideal outcome is to pick bots with just barely enough energy to dash to the charge pad. Skip all bots below the threshold (they will crawl and slow things down), and continue queueing bots above the threshold. Unfortunately it sounds like a pretty dumb algorithm, because it means searching for low charge (but not TOO low) bots all the time. Sorting a list is FAR more expensive than walking through a queue with no conditions so as far as solutions go it's pretty bad.

Well as I was saying before, I don't think it's necessary (or necessarily a good idea) to try to deliver the "ideal" outcome; just leave out the threshold bit, since the crawling would only occur if the roboports are completely overloaded, and that problem should be the responsibility of the Factorian, not the roboport. Besides, leaving out the drained bots would suffer from the same stalling problem as the highest-charge-first order; items held by drained bots could stall in queue.
Implementing the simple "lowest charge first" would be far less intensive, since the "search" part would be offloaded to the shuffling of new bots into the queue (which is only time-sensitive for the first queue position or so). The roboport could then just pull from the queue in order.

[Chao]

A lot of suggestions seem to be around trying to adjust the algorithms for bot charging. I don't think any of these will give a great solution but worse, for heavily bot based factories it could have a huge impact on UPS. Simple queues You're looking at O(1) for adding a new bot. Once you start inserting into ordered queues you are at best looking at O(n), depending on the approach add in to that if you need to recalculate values and resort the list you're potentially looking at O(n log n) with the base calculation itself being longer.

I think there's 2 changes that could be made without being a huge buff to bots.

First, don't have the bots move from the queue to the charging point under its own power. Have the port "drag" them in, this at least deals with the worst case scenario of dead bots causing deadlocks.

My preferred alternative, though some may still think it's too much of a buff as it will improve through put. Have the roboport generate a low level wireless charging area. Anything in the queue by the port gets enough charge while waiting to balance out its drain. You could even have this passive charge at a penalty of some multiplier so there's a minor nerf in needing to handle bot surges for poorly laid out roboports where a large order can clog a port.

[Theikkru]

A lot of suggestions seem to be around trying to adjust the algorithms for bot charging. I don't think any of these will give a great solution but worse, for heavily bot based factories it could have a huge impact on UPS. Simple queues You're looking at O(1) for adding a new bot. Once you start inserting into ordered queues you are at best looking at O(n), depending on the approach add in to that if you need to recalculate values and resort the list you're potentially looking at O(n log n) with the base calculation itself being longer.

What I suggested was adding to a charge-ordered queue, which can be accomplished with a binary search at O(log(n)), significantly faster than O(n). Further, in practice, n is capped at a reasonably low number, because, as others have pointed out, the only situation in which you'd have n＞1000 or so (keep in mind these are queues for individual roboports) is if your base is coming down with a case of terminal deadlock. If that's happening, roboport queueing UPS is going to be neither a limiting factor, nor your biggest concern.

I do like your wireless charging area idea, since the "punishment" for overloading your bot system is shifted rather than removed altogether.

[Chao]

A lot of suggestions seem to be around trying to adjust the algorithms for bot charging. I don't think any of these will give a great solution but worse, for heavily bot based factories it could have a huge impact on UPS. Simple queues You're looking at O(1) for adding a new bot. Once you start inserting into ordered queues you are at best looking at O(n), depending on the approach add in to that if you need to recalculate values and resort the list you're potentially looking at O(n log n) with the base calculation itself being longer.

What I suggested was adding to a charge-ordered queue, which can be accomplished with a binary search at O(log(n)), significantly faster than O(n). Further, in practice, n is capped at a reasonably low number, because, as others have pointed out, the only situation in which you'd have n＞1000 or so (keep in mind these are queues for individual roboports) is if your base is coming down with a case of terminal deadlock. If that's happening, roboport queueing UPS is going to be neither a limiting factor, nor your biggest concern.

I do like your wireless charging area idea, since the "punishment" for overloading your bot system is shifted rather than removed altogether.

Yep you're right, I got the bounds on that wrong, O(log n) isn't too bad.

The idea of shifting a punishment fits in well with factorio's approach, it's now no longer a "punishment" but a potential new bottleneck.

[Theikkru]

Bottleneck! Yes, that's the term we want. The point is to convert hard limits imposed by untenable factors into bottlenecks that can be resolved with scaling or clever design, not to just make things easier by buffing numbers or removing limiting factors entirely.

[bobucles]

My preferred alternative, though some may still think it's too much of a buff as it will improve through put. Have the roboport generate a low level wireless charging area.

A constantly active AoE aura effect is anything but O(1).

[Qon]

My preferred alternative, though some may still think it's too much of a buff as it will improve through put. Have the roboport generate a low level wireless charging area.

A constantly active AoE aura effect is anything but O(1).

A constantly active aoe effect as described could possibly improve ups. The effect would be same as hover drain and the bots in queue dont move and have no job except waiting. The only thing that changes about them is their energy level. That means the effect would be that you can just stop updating anu queueing bots completely once they arrive at the port queue and just drain a multiple of the enqueued bots from the roboport.

[Chao]

My preferred alternative, though some may still think it's too much of a buff as it will improve through put. Have the roboport generate a low level wireless charging area.

A constantly active AoE aura effect is anything but O(1).

A constantly active aoe effect as described could possibly improve ups. The effect would be same as hover drain and the bots in queue dont move and have no job except waiting. The only thing that changes about them is their energy level. That means the effect would be that you can just stop updating anu queueing bots completely once they arrive at the port queue and just drain a multiple of the enqueued bots from the roboport.

Exactly this. Describing it as an AoE effect is flavour for how it acts. If you have n bots queued at a roboport that's n bots you don't have to update energy on each update and a single energy check on the roboport regardless of the size of n.

[Theikkru]

The one caveat I see is that the transmission efficiency for the standby field would have to be something miserable like 5% or dependent upon n in order for people to actually care about its cost (and for the change to not just be a massive buff to roboports/bots).

[Koub]

I'd rather have a "bot charging efficiency" added on top, so that if one invests time and resources, bots can spend less time charging, thus mitigating the weird result of having mots spend more and more of their time queuing for recharge as you research bot speed.

[Qon]

I'd rather have a "mot charging efficiency" added on top, so that if one invests time and resources, mots can spend less time charging, thus mitigating the weird result of having mots spend more and more of their time queuing for recharge as you research mot speed.

How much more throughput do you think logistics mots should have? Double? 500%? 20 000%? Just tell me what you think is a reasonable number and we can discuss that first. No point in discussing how to achieve it if we have no decided goal for how strong these throughput buffs should be.

I think logistics mots should stay as they are, no buffs to their throughput at least. Construction mots can get buffed beyond reason and then some, imo.

[Koub]

Actually, bots used in short spikes wouldn't see much difference : from the user standpoint, a bot queuing for recharge and an idle bot waiting for new orders can't be told apart.
The difference would become visible when the bot will be needed over the roboport capacity to recharge them.

What I would like is not buff throughput as much as I would like not to have to pave the factory with roboports just to keep up with the increased consumption per second.

I'd like roboports to support a similar number of bots whatever the bot speed tech level. Or at least, even if the "roboports needed to sustain X bots" number is not constant, at least make it capped, so that at very high levels of bot speed tech, you don't need an absurd number of roboports to meet the remand in recharge time.

The idea in itself is not absurd : IRL, progress is made to allow always faster charging speed for batteries (in electric cars, smartphones, ...).

[Qon]

Actually, bots used in short spikes wouldn't see much difference : from the user standpoint, a bot queuing for recharge and an idle bot waiting for new orders can't be told apart.
The difference would become visible when the bot will be needed over the roboport capacity to recharge them.

Exactly. When you are using logistics bots only and no belts the bots would become even better as constant mass transport.

What I would like is not buff throughput as much as I would like not to have to pave the factory with roboports just to keep up with the increased consumption per second.

These come together, you can't choose one unless you also propose some seriously dramatic new change like making roboports impossible to place at any distance closer than their max range. Read what I wrote earlier in this thread, I've said this before.

I'd like roboports to support a similar number of bots whatever the bot speed tech level. Or at least, even if the "roboports needed to sustain X bots" number is not constant, at least make it capped, so that at very high levels of bot speed tech, you don't need an absurd number of roboports to meet the remand in recharge time.

You have misunderstood roboports function and purpose. They exist to take space on the ground. You don't need an absurd amount of them, it's the complete opposite. And you need slightly less roboports with higher speed. I've said this several times now.

The idea in itself is not absurd : IRL, progress is made to allow always faster charging speed for batteries (in electric cars, smartphones, ...).

It's absurd because the change you propose does not even remotely do what you state that you want it to do. It's absurd because you don't know what the current research does. It's also somewhat absurd to use 'realism' as an argument for a balance change because if you do you have to consider other silly points such as that the tiny bots carry around refineries, trains and fission reactors as easily as pieces of wire. Let's not go there.