Scale worker robot speed research

[Ext3h]

So this is about the Worker robot speed endless research.

In the current state, this research is close to useless for anything except optimizing delays on rare delivery events or keeping up with the players movement speed (up to hard limits, too). It doesn't work at all for increasing throughput in stationary factories. With the research cost increasing at a potency of 2, it's by far too expensive for a technology which has already hit diminishing returns prior to endless research stage.

The main issue is that it's significantly decreasing the time between recharging at roboports, but the recharge time itself remains a constant. As a result, robots zip faster from Roboport to Roboport, but then just pile up there, waiting for their turn to be charged. Eventually you can no longer scale up the number of Roboports (worker robots are not exactly smart about which Roboport they pick for recharging), so you inevitably hit a hard throughput limit.

As it's mentioned on the wiki ( https://wiki.factorio.com/Worker_robot_ ... rsus_range ), the current formula for consumption also doubles as a constraint on the distance a robot can move without recharge.

Now, there would be three possible approaches:

1. Scale the recharge speed with movement speed. Late game, when you can afford that research, both your modular armor and your energy grid should have sufficient spare power left to afford a proportionally increase in power drain from Roboports. Given a constant number of worker robots, and a constant number of Roboports, this would then just result in a net throughput gain without otherwise impacting distance constraints or worker robot energy efficiency per unit traveled * item transported.
2. Scale per-tile movement cost inverse proportionally with the speed bonus. Keeps the pacing for the recharge animation unchanged, but has several implications. Foremost, maximum distance for worker robots effectively increases, and so does the downtime for approaching a recharge station. Also effectively reduces energy cost per distance traveled.
3. Increase recharge rate as per 1st approach, but additionally also increase the internal capacity of worker robots. Maintains constant efficiency, but has otherwise all the benefits of the 2nd approach.

For the sake of just working around the diminishing returns, short term, the 1st approach is entirely sufficient. It still runs into diminishing returns eventually though, as the animation for charging, with enqueuing etc. doesn't scale indefinitely. It also doesn't exactly make robots scale with increasing player movement speed, as you still have that hard ceiling where the robot would need to move more than the available 250 tiles in order to catch up with the moving player.

The 2nd approach provides excessive benefits, by both netting an efficiency increase as well as increased performance simultaneously.

The 3rd approach IMHO provides the best user experience.
The scaled up maximum distance is a welcome improvement for late game. Especially also considering the tendency of robots in networks with concave shapes not to follow the logistic links, but rather to take "shortcuts", so that plays well together.
By reducing the effective frequency at which robots need to recharge, it effectively combats congestion around the charging process.
Scaling the energy consumption per Roboport is in line with other late game mechanics (tier 3 modules etc.).

[Qon]

In the current state, this research is close to useless for anything except optimizing delays on rare delivery events or keeping up with the players movement speed (up to hard limits, too). It doesn't work at all for increasing throughput in stationary factories.

And you don't think that's a deliberate design choice to not buff the throughput of the strongest and easiest logistics option further?
I love using bots, but I don't think they need a throughput buff. I don't want them nerfed either though.

But higher capacity batteries that charge faster and easier to obtain hyperspeed for construction bots I'm all for.

[Ext3h]

And you don't think that's a deliberate design choice to not buff the throughput of the strongest and easiest logistics option further?

Wouldn't call it the easiest though. If you go mega-factory, I had to drop from worker robots back to belts several times, as the robots occasionally tend to just deadlock if there is a burst in throughput, hundreds of bots swarm in all at once, and then all crash at the Roboports for recharging without having done any work yet. Which then in return locks up the local Roboports for a long time, without getting any work done.

It's fairly balanced before you unlock the speed boosts. Maybe annoyingly slow (I mean the part where you have to stand still until they catch up to you), but otherwise working fine. Later on, if you spend resources into that research, it becomes increasingly volatile.

No, I don't think that volatility is intentional.

[Qon]

Wouldn't call it the easiest though. If you go mega-factory, I had to drop from worker robots back to belts several times, as the robots occasionally tend to just deadlock if there is a burst in throughput, hundreds of bots swarm in all at once, and then all crash at the Roboports for recharging without having done any work yet. Which then in return locks up the local Roboports for a long time, without getting any work done.

You say mega-factory and "hundreds" of bots in the same sentence. Are you sure you have a bot based mega-factory and not just something that is big compared to a starter base? Even with infinite bot speed 15 a tiny 1k RPM bot-based factory requires 2000 logistics bots and there's no trouble keeping them charged for me. Before infinite research it used 5000 bots. But the amount of roboports needed is pretty constant since faster flying bots use more energy/second. This is like half the production needed for a 1k SPM (of each) base which is generally in the lower segment of what is considered "mega". If you have a belt base then that sounds more like reasonable numbers. But how can you have bot problems in a belt base

If you have "hundreds" of bots then place roboports closer than their maximum connecting distance to increase recharge capacity in the area. They have way more capacity than belts if not used maximally incorrectly. Used correctly you could have a hundred times more bots active constantly.

[Ext3h]

You say mega-factory and "hundreds" of bots in the same sentence. Are you sure you have a bot based mega-factory and not just something that is big compared to a starter base? Even with infinite bot speed 15 a tiny 1k RPM bot-based factory requires 2000 logistics bots and there's no trouble keeping them charged for me. Before infinite research it used 5000 bots. But the amount of roboports needed is pretty constant since faster flying bots use more energy/second. This is like half the production needed for a 1k SPM (of each) base which is generally in the lower segment of what is considered "mega". If you have a belt base then that sounds more like reasonable numbers. But how can you have bot problems in a belt base

I want to see that 1k RPM factory Suppose you mean the usual 1 RPM / 1k SPM. No, I don't mean the base load of 2-3k robots performing medium distance delivery on a regular base, that part works just fine as you can place enough ports in areas where you know they are passing through. Respectively for anything low volume (anything above green chips), you don't even reach a critical density where a single row of roboports around each factory patch (smaller than 125x125 tiles) would ever be insufficient, regardless of the speed research.

Also, as you noted correctly, your setups kept working with the same number of roboports as the required number of workers was cut to half. Not while being able to maintain the size of the workforce....

Where it always blows up is for tasks such as train unloading (bulk transfer to buffer chests) or building another row (of 1000+) solar panels at once. When all of a sudden, a few hundred additional workers decide to spur to life, only to arrive all simultaneously with a dead battery, and then to hog all the very same ports, as they are to dumb to look for a free one.

Ok, that issue isn't unique high speed levels, but with the relative time spent charging increasing with speed research, it's spinning out of control much faster.

[Qon]

I want to see that 1k RPM factory

Me too my friend, me too!

Ok, that issue isn't unique high speed levels, but with the relative time spent charging increasing with speed research, it's spinning out of control much faster.

Yes more relative time is spent charging. But that isn't a bad thing. They are completing their tasks faster. Since they use energy constantly and per tile traveled the distance per charge actually increases with higher speeds, so they become more energy efficient also. So they use less energy for the same task and you need less roboports with higher speed research. This effect is pretty much 0.000 though since the energy required per second is already low compared to the energy spent moving and each exponential cost upgrade shaves off a tinier and tinier fraction of this "hover" cost that you wouln't notice if it disappeared completely.

[Koub]

Yes more relative time is spent charging. But that isn't a bad thing. They are completing their tasks faster. Since they use energy constantly and per tile traveled the distance per charge actually increases with higher speeds, so they become more energy efficient also. So they use less energy for the same task and you need less roboports with higher speed research. This effect is pretty much 0.000 though since the energy required per second is already low compared to the energy spent moving and each exponential cost upgrade shaves off a tinier and tinier fraction of this "hover" cost that you wouln't notice if it disappeared completely.

This is (emphasis is mine) the real issue for me.

With numbers taken from the wiki, at the beginning, a logistic bot drains continuously 3kW and consumes 5 kJ/tile while moving 3tiles (= meters)/s.
It also has a 1.5 MJ internal buffer
So upon discovery, the logibots consume : 3x5=15kW while working and 3 kW as a drain
A logibot will travel 1.5M/(15k+3k)=83.3s before being empty and needing a 1.5s of charging (roboports seem to be charging at 1MJ/s)
time ratio spend recharging : 1.8%

With the "finite" research (Worker robot speed 5), you have a 240% increase of (340% total) speed, so the logibots move 8.25 m/s (3x3.4)
Now it consumes 5x8.25=51 kW + 3kW as drain
Our logibot now travels 1.5M/(51k+3k)=27.7s before being empty and needing a 1.5s of charging
time ratio spend recharging : 5.1%

With 5th infinite research (speed 10), 565% speed increase the numbers are :
speed 3x3.65=19.95 m/s
consumption 5x19.95=99.75kW + 3kW as drain
max travel time 1.5M/(99.75k+3k) = 14.6s before being empty and needing a 1.5s of charging
time ratio spend recharging : 9.3%

Last with 10th infinite research (speed 15), you get 890% speed increase
speed 3x9.9=29.7 m/s
consumption 5x29.7= 148.5kW +3kW as drain
max travel time 1.5M/(148.5k+3k) = 9.9s before being empty and needing a 1.5s recharge
time ratio spend recharging : 13.2%

One more milestone (less likely to be seen I admit) : At 97 infinite research (102 robot working speed), Your logibots start spending more time recharging than working.
Also maximum distance travel starts at 250m, and asymptotically converges towards 300m with infinitely many research.

Although this makes sense, it also feels frustrating to me : as robot speed increases, you need always more roboports to recharge your starving robots.
I attached a small spreadsheet for those interested by the numbers, feel free to do whatever you want with it .

[Qon]

Yes more relative time is spent charging. But that isn't a bad thing. They are completing their tasks faster.

Although this makes sense, it also feels frustrating to me : as robot speed increases, you need always more roboports to recharge your starving robots.
I attached a small spreadsheet for those interested by the numbers, feel free to do whatever you want with it .

So with my emphasis:

Yes more relative time is spent charging. But that isn't a bad thing. They are completing their tasks faster.

You don't need more roboports as your speed research increases. You need less roboports. As they approach infinite speed they also approach 100% time spent at roboports. But the energy required for your logistics swarms decreases/item transferred 1 tile and the number of bots required approaches 1.

The relative time spent charging is irrelevant for all practical purposes. You need to provide an issue if we are going to discuss anything.

[Koub]

OK I'll try to express it differently. I want my bots to be doing their job continuously with the less downtime possible.

At the beginning, one robot can fly 83.3s before needing a recharge. Every 1.5s, I can refill 4 logibots with a roboport, so during that 83.3s flight, one roboport can manage at most (83.3/1.5)x4 = 222 robots without them queuing for recharge.

Now let's say I have infinite tech 5 (worker speed 10).
Now, my bots have a 14.6s autonomy at full speed. At that speed, my roboport can only refill 38.9 bots without them starting to queue, so if I don't want my bots spending their time queuing for recharge, I'll have to add 5 roboports.

And if we consider a rather courageous Factorian with more than 102 worker speed, he'll have to build more than 1 roboport for every 4 bots for them not to start queuing.

Considering the cost of this infinite tech, I think that the drawbacks (too) quickly exceed the benefits. I'm totally OK for diminishing returns on infinite research, but I feel there is a balancing issue somewhere.

[Qon]

OK I'll try to express it differently. I want my bots to be doing their job continuously with the less downtime possible.

Why?

Also, you don't get more downtime. The research doesn't provide many benefits at all, I can agree with that. It's mostly useless for continuous bulk logistics. But I don't think Wube wants to buff that aspect of the bots anyway.

[bobucles]

We already went over this math many times. Bots pay energy for every tile they cover so even if they go faster, they need more energy to do it. The limit on pure item motion ultimately depends on how much energy the bots can get. If you want more powerful flying logistics then the traits to modify are energy efficiency, carry capacity and recharge rate. There are plenty of roboport and bot boosting mods, but the vanilla tech is more than enough to face the challenges of the game.

Faster bots are more responsive and better for construction tasks. Faster bots aren't necessarily better for maintaining a constant flow of items, but they are vastly more useful for player requests and still reduce the total number of bots needed to saturate a network.

[Qon]

Seems like bobucles gets what I'm saying

[Ext3h]

At the beginning, one robot can fly 83.3s before needing a recharge. Every 1.5s, I can refill 4 logibots with a roboport, so during that 83.3s flight, one roboport can manage at most (83.3/1.5)x4 = 222 robots without them queuing for recharge.

Now let's say I have infinite tech 5 (worker speed 10).
Now, my bots have a 14.6s autonomy at full speed. At that speed, my roboport can only refill 38.9 bots without them starting to queue, so if I don't want my bots spending their time queuing for recharge, I'll have to add 5 roboports.

Thanks for doing the math. That explains pretty well why workers enqueuing becomes a pretty common sight when progressing in that research.

There is also another aspect to this calculation, even though you need less robots for a constant throughput, the dispatch rules remain the same. Meaning if there is e.g, a burst of 4,8k items (like when placing a fresh buffer chest), the game will always try to dispatch 1200 worker robots simultaneously. At no research, that requires 6 roboports per 250 tiles traveled / locally to avoid queues. At infinite tech 5, that requires already 31 roboports for the same task, a number for which load balancing between roboports has long stopped working.

Regardless of the task completing much faster, which realistically doesn't even matter. It's usually just a one-way trip with a full dispatch, unless you are putting a decreasing, hard cap on the total number of bots in each logistic network (which implies splitting logistic networks, just for the sake of maintaining that hard cap).

Queuing then has a direct impact on other routes crossing a blocked roboport, and is usually causing a cascade of fresh (non recycled) robots to be dispatched to compensate for stalled ones.

On top of that, a queue on a roboport also means that robots waiting to partially(!) recharge prior to entering the roboport also further drain their battery by regular idle drain, and have to compensate that by increased charging times. Which then shifts the charge-to-work ratio significantly further towards the bad end, beyond what @Koub has estimated for continuous operation.

There is a sweet spot where so many robots are dispatched concurrently, that the combined idle drain, waiting for the recharge prior to going to sleep, exceeds the available charging rate. So every new task dispatches a fresh bot in place of a waiting one which then also adds to the drain when trying to go idle. A dreaded deadlock which you can't escape without temporarily scaling roboports up (or eco down) to the point where you can afford to waste a full battery charge on every single, trivial task.

Ok, having constructed the cause of the observed deadlock, I have to reconcile my recommendation from the start post. Increasing the battery size + recharge rate together would also increase the power drain from this deadlock scenario.

So to sum it up:

• Speed research is responsible for the high volatility, as it's decreasing the number of sustainable workers per roboport significantly.
• Idle drain while waiting for recharge is the mechanic which causes temporary roboport overloads to manifest into deadlocks.

EDIT: No, idle drain isn't the cause of the deadlock either, it's just increasing the power drain during an ongoing deadlock. What is sustaining the observed deadlocks then? Animation speed for using the charger?

[Qon]

Now we are talking! You presented an actual drawback of the system.

The question though is still: does it actually have noticeable and measurable drawbacks. Can you construct a factory that gets much less throughput or way higher energy consumption (or other metric) when upgraded? And is it actually possible to attain this research level (if it requires 300 years of 60k SPM then it's not actually a problem)? And 3% more energy drain by bots isn't really a concern for a megabase.

An actual deadlock after a burst job where bots get permanently queued up until you shut the factory off manually for a while until they all recharge would qualify as a really good example.

[bobucles]

There is a sweet spot where so many robots are dispatched concurrently, that the combined idle drain, waiting for the recharge prior to going to sleep, exceeds the available charging rate

That's not the sweet spot. That's not even a real thing. Idle drain is not enough to overwhelm roboport recharge rate until you reach over a thousand robots per roboport. Roboports don't have enough inventory for that.

The sweet spot is when robot batteries dry out while waiting for the roboport. A bot without energy moves at a crippled speed and at low tiers will take a very long time to reach the recharge pads. A bot that's crawling isn't charging and the total charge rate of the roboport tanks as a result. When recharge rate goes down, the total item moving capability of the network goes down. So there's a very important tipping point in the network where you want your robots to reach the charge pads BEFORE they run completely dry.

The crawling robot syndrome is mitigated somewhat at higher research levels, since a very fast bot still has a decent crawling pace.

[Koub]

Whatever the bot speed research level, bots drain 3kW, or in other words 3 kJ/s
So for a bot to fully empty itself while hovering, it would have to hover 1.5M/3k = 500s
A bot recharges in 1.5s, so a roboport can recharge 333 robots with each of its 4 slots during that time.
So, if my math is correct, with over 1333 bots per roboport, the bots would spend their full charge waiting for the next recharge, whatever the bot speed research level is.

Now my point is not that bots should be buffed, it's just that the cost is excessive in view of the benefits. As I said :

I feel there is a balancing issue somewhere.

One could tell me "if you think it's useless, just don't research it". This is indeed true, but I feel it would be a shame to let in the game something useless just because of that. All infinite techs should provide at least some reason to want to research them.

[Qon]

One could tell me "if you think it's useless, just don't research it". This is indeed true, but I feel it would be a shame to let in the game something useless just because of that. All infinite techs should provide at least some reason to want to research them.

I agree. But if the research continues to affect both bot types then it can't be useful for continuous load. If the research gave speed to both but also gave construction bots larger battery capacity and faster recharge then that wouldn't be as overpowered. And I'm for pretty much any buffs to construction robots I like Creative mods super construction bots that are so fast that they basically teleport kilometers and use no energy while also being immortal and stack to 1000.

Otherwise if it's easy to achive significantly longer flight distances with and relativly less time spent on recharging then you can suddenly research away roboports and just have minimal roboport density and get even easier factory design and the ability to achieve much higher throughput still.

[Theikkru]

Since the deadlock issue appears to be a thing, I'm going to assume that roboports use a first-come-first-serve rule to recharge bots. This is because the premise of deadlocks being caused by speed research is that bots that would, without the research, still be en-route to the roboport make it to the roboport and clog up the charging queue, starving out other bots on other routine jobs that happen to (try to) use the same roboport, and bogging down the charging process.

The solution to this problem is actually quite simple: change queueing rules at roboports such that the robots are prioritized by level of discharge. That way, the order of arrival becomes irrelevant, and bots arriving at the port with their last gasp would only clog up the queue if there were enough of them that the roboport wouldn't have been able to handle them fast enough in any order.

For further detail on how this works, I'd like to expand on this

if my math is correct, with over 1333 bots per roboport, the bots would spend their full charge waiting for the next recharge

because while the calculation is accurate, it makes some assumptions (e.g. bots arriving with full charge, all bots being charged are empty) that aren't very practical.
In more general terms, bots drain at 3kW, and roboports charge at 4MW, so roboports charge at 1333⅓ times the discharge rate of a bot. This statistic becomes important when you introduce queueing to the problem, because we can determine that a bot WILL starve if there is (current charge)×1333⅓ or more worth of robot discharge in front of it in the queue. For example, if a bot arrives at the port with 10% charge remaining, it would take fewer than 667 bots with 80% charge, 334 bots with 60% charge, 223 bots with 40% charge, or 191 bots with 30% charge ahead of it to cause it to starve in queue (this is optimistic because the bots in front will be draining too, increasing the queued discharge over time).
Worse, there is a penalty for the number of bots in queue because they take time (in sets of 4) to move onto the charger, and during that time the roboport is idle, so the equation is more accurately:
((current charge)－(# of bots in front)÷4×(idle drain rate)×(swap time per bot))×1333⅓≤(# of bots in front)×((full charge)－(average charge of bots in front))
or
(C－N÷4×D×T)×1333⅓≤N×(F－Q)
Of these, we know idle drain D＝3kW or 0.2%/s, full charge F＝1.5MJ or 100%, and we can assume something reasonable for swap time such as T＝0.4s. Some algebraic rearrangement then gets us
N≥1333⅓C÷(F－Q＋333⅓D×T)
＝1333⅓C÷(100%－Q＋26⅔%)
＝1333⅓C÷(1.5MJ－Q＋400kJ)
which lets us estimate (optimistically) how many bots queued in front (N) will starve out a waiting bot if we know its charge (C) and the average charge of the bots in front (Q). With this new equation we discover that the same 10% bot from before will starve out with just 286 bots at 80% charge, 200 bots at 60% charge, or 154 bots at 40% charge in front of it.

Queueing by level of discharge would order the bots so that the bots with higher charge (C) would be the ones with more bots in front (N), so you would only start getting complete drains (∃ bot: N≥1333⅓C÷(F－Q＋333⅓D×T)) if the charge distribution of bots in queue (~Q) were too low for that roboport to deal with in any order.

[bobucles]

The solution to this problem is actually quite simple: change queueing rules at roboports such that the robots are prioritized by level of discharge. That way, the order of arrival becomes irrelevant, and bots arriving at the port with their last gasp would only clog up the queue if there were enough of them that the roboport wouldn't have been able to handle them fast enough in any order.

That'd be neat if roboports prioritized fast bots to keep the charging ports working as fast as possible. Another option is to send the next in line bots a bit faster, so they don't hold up the line so much. The reduced efficiency of slow bots is very painful early on, but it's not a big thing with faster tech.

If there are hundreds of bots lining up for a roboport, the problem is there aren't enough roboports in the first place. Get more.

[Theikkru]

That'd be neat if roboports prioritized fast bots to keep the charging ports working as fast as possible.

If by "fast bots" you mean ones that haven't drained completely, I don't know if that's really necessary, since that would only apply if some bots already ran out of power. The only problem I'm trying to solve is the one where the order of arrival at the roboport alone causes a full drain, i.e. the "that one logibot from downtown halfway down the queue that couldn't wait that long" problem, which is outside user control and different from simply overloading the roboport; I see no problem with the system punishing you for the latter (by queueing up all the drained bots first). As you said,

If there are hundreds of bots lining up for a roboport, the problem is there aren't enough roboports in the first place. Get more.

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.