Scale worker robot speed research

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

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

I wouldn't mind : if I have invested so much in upgrading my robots, I don't want them to be only effective the few first (tens of) seconds before their efficiency is crippled by queuing for a recharge.

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.

Fine, I take both then. I'm not asking for the bots to be as effective for long bulk logistic requests as for short burst spikes, but I want some coherence. Currently, robot speed tech has an adequate result on logistic bursts, but not on slightly longer to fulfill requests for a given number of bots and roboports.

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.

I haven't misunderstood anything, I just don't want to be compelled to research a very expensive tech and on top of that allocate an increasing part of the factory to roboports, just to be able to benefit fully from my research.

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.

Your argument is invalid. The fact that there are similitudes with real life does not make the mechanism I suggest incompatible with a game. There are things that do correlate to real life in the game ; should they be removed from the game just because too realist ? I never asked for a purely realistic game. What I said is that if it makes sense in real life, it wasn't absurd considering it for the game. Period.
The change I'm asking for is totally related with what I want it to do : I want to be able to sustain a given population of bots with a given number of roboports, no matter how many robot speed tech I research. I don't want to add roboports every level of bot speed I research to benefit fully from my research.

[Qon]

Fine, I take both then. I'm not asking for the bots to be as effective for long bulk logistic requests as for short burst spikes, but I want some coherence. Currently, robot speed tech has an adequate result on logistic bursts, but not on slightly longer to fulfill requests for a given number of bots and roboports.

Finally, you admit to being for logistics bot throughput buffs. Thanks for the honesty, at last. Now we might be able to have a fruitful discussion that doesn't go in circles.

Maybe we should agree to disagree on that point though. I don't think you will make any convincing arguments for why bots should be more OP than just that it's your preference. Since the current bots can already handle the highest throughput modules and beaconed recipes at scale, I don't see the point until we have even faster ways to craft items where that would be needed.

If you want bot throughput to skyrocket, does that mean you are for massive buffs for trains and belts as well? Otherwise, belts will be completely useless compared to bots and with the changes you propose you might also reach a stage where bots are superior to trains at long distance transport as well. I think adding loaders is a better buff to trains and belts than straight throughput buffs. At least to see where we are at then and not overbuff. But belts are kind of slow and clumsy so buffing them might be reasonable. Splitters should also be connectable to circuit network so we can change filters on the fly and make some compact and interesting belt routing stuff with them.

I wouldn't mind some belt buffs. Would be nice if they caught up to bots in some regards. Buffing bots would make that pretty much impossible though.

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

Your argument is invalid. The fact that there are similitudes with real life does not make the mechanism I suggest incompatible with a game. There are things that do correlate to real life in the game ; should they be removed from the game just because too realist ? research.

That's not my argument. That's a strawman of my argument. Have fun knocking down the thing I didn't say. Your argument is invalid.

[Koub]

Fine, I take both then. I'm not asking for the bots to be as effective for long bulk logistic requests as for short burst spikes, but I want some coherence. Currently, robot speed tech has an adequate result on logistic bursts, but not on slightly longer to fulfill requests for a given number of bots and roboports.

Finally, you admit to being for logistics bot throughput buffs. Thanks for the honesty, at last. Now we might be able to have a fruitful discussion that doesn't go in circles.

Maybe we should agree to disagree on that point though. I don't think you will make any convincing arguments for why bots should be more OP than just that it's your preference. Since the current bots can already handle the highest throughput modules and beaconed recipes at scale, I don't see the point until we have even faster ways to craft items where that would be needed.

If you want bot throughput to skyrocket, does that mean you are for massive buffs for trains and belts as well? Otherwise, belts will be completely useless compared to bots and with the changes you propose you might also reach a stage where bots are superior to trains at long distance transport as well. I think adding loaders is a better buff to trains and belts than straight throughput buffs. At least to see where we are at then and not overbuff. But belts are kind of slow and clumsy so buffing them might be reasonable. Splitters should also be connectable to circuit network so we can change filters on the fly and make some compact and interesting belt routing stuff with them.

I wouldn't mind some belt buffs. Would be nice if they caught up to bots in some regards. Buffing bots would make that pretty much impossible though.

Actually, I'd be OK just removing the whole "bot speed" unlimited research branch. As I said, my goal is NOT to explicitely buff bots, but to restore some balance between the result of this research its cost. It's as if the fire rate of the weapons/turrets decreased with each damage upgrade researched, and there wasn't any tech for buffing firing speed.

And I also never said belts or trains shouldn't get buffs. I'm just focussing on the original topic : I'd like the robot speed research to be better balanced, either by itself, or by the addition of a parallel branch allowing for better time efficiency at recharging so that the aforementionned research has effects more in line with the investment it requires. The way bots consume their energy could be more related to time, and not (only) distance.

There are many solutions to that specific balance issue, not all of them buff bots. I just don't want to dismiss any change a priori just because it could end up buffing bots in some scenarii.

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

Your argument is invalid. The fact that there are similitudes with real life does not make the mechanism I suggest incompatible with a game. There are things that do correlate to real life in the game ; should they be removed from the game just because too realist ? research.

That's not my argument. That's a strawman of my argument. Have fun knocking down the thing I didn't say. Your argument is invalid.

If you didn't want to be the the target of a strawman sophism, why did you use it on me first hand ?

[Ext3h]

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.

Aren't you assuming that it actually results in an effectively unbound boost? If only the charging process is boosted, but not the power draw of the Roboport itself (recharge of internal buffer), then the response to bursts (unavoidable with the dispatch logic) is improved, up to the point where the Roboport's internal buffer is drained.

You have a hard limit on throughput though, simply as speed research causes bot operation cost to converge to pure "energy per tile" instead of "energy per second", so at a 5MW internal buffer recharge rate of the Roboport, you have a hard cap of 800-900 tiles per second in terms of bandwidth per Roboport. In other terms, one Roboport caps out at the equivalent of 74 express belt tiles (doesn't matter if parallel or sequential) for full-duplex routes, 37 tiles on half-duplex routes.

That limit actually holds regardless of changes to the charging system (AoE, increased charge speed, decreased downtimes by improved queuing animation etc.), but all these proposed changes to charging serve to improve the burst response. It also holds regardless of the internal buffer size of a Roboport.

Anything which decreases the charging duration also aids with latency in long range routes which also already require "sufficient" Roboports to start with. Given how Robots react to concave shapes that's a lot of Roboports you have to place down even on "rare" routes, so that's already a significant downside over train / belts / any other form of properly routed transport. (The pathfinding for concave layouts is a different topic though.)

There is a minor boost hidden in there though, and that is the fact that the internal buffer recharge rate is currently left completely untapped. 5MW internal recharge rate, but only 4x1MW output and a duty cycle of usually significantly less than 100%, you can't even remotely tap into that. In the current state, a single Roboport running at a realistic 75% duty cycle (3 charging pads on average in constant use), equals only 22-25 blue belt tiles in half duplex operation, and even that if only placed in-line with the transport route. Increasing load to the 4th pad isn't realistic for sustained operation, robot systems can't handle the resulting back pressure.

If you insist on keeping that 16 tiles footprint to equivalent 22-25 tiles of express belts ratio, then the knob to ensure that is the internal buffer recharge rate, nothing else.

[Qon]

If you didn't want to be the the target of a strawman sophism, why did you use it on me first hand ?

Just saying it doesn't make it true.

Aren't you assuming that it actually results in an effectively unbound boost? If only the charging process is boosted, but not the power draw of the Roboport itself (recharge of internal buffer), then the response to bursts (unavoidable with the dispatch logic) is improved, up to the point where the Roboport's internal buffer is drained.

Efficiency has been used in several ways throughout the thread. In some posts it was explained to mean that bots would fly with less energy/tile or use less energy from the roboport while also having a larger battery but charge is as quickly or similar variations. And Koub doesn't want them to hit a limit where they are suddenly all charging waiting for energy. So while efficiency with the definition you are assuming would indeed mean you hit a limit a bit later down the line, Koub would then suggest increasing the internal buffer recharge rate to match to avoid that limit or his suggestion would be somewhat pointless in alleviating the number of roboports needed.

So that's another point you are raising as critiscism against Koub for not understanding what his suggestion would actually accomplish.

[Koub]

So that's another point you are raising as critiscism against Koub for not understanding what his suggestion would actually accomplish.

Trying to ridicule me by making me seem stupid and unable to understand what I'm asking for is kind of insulting, but I'll ignore that and focus on the discussion.

Currently, the roboports can output 4x1MW, therefore they can recharge 4 robots with 1.5 MJ internal buffer in 1.5s at a time. They do have an internal buffer, but it's useless, unless in case of power shortage : the roboports can output exactly at 80% the rate they can recharge (4MW output, 5MW input).

A tech that would increase at the same time internal recharge rate and robot recharge rate shouldn't be that much difficult to create. And if you want consistency, instead on focusing on the roboports, a "fast battery charging" tech could extend that principle to anything with internal electric buffer and can recharge/discharge (including accumulators, portable batteries, ...). Problem solved.

[bobucles]

Buffing the charge rate will dramatically change the average logistic behavior of the roboport. That will change base layouts, as a few upgraded robos will be able to handle the same logistic demands as many low tier versions. It'd be the same thing if belts had a speed upgrade.

Bot speed doesn't do too much to change roboport efficiency. The biggest change occurs in an overloaded network, when slow bots drag things down. But for all other times, a super fast bot will move roughly the same amount of items as a bunch of slow bots, so there is not much difference for blueprints.

[Qon]

So that's another point you are raising as critiscism against Koub for not understanding what his suggestion would actually accomplish.

Trying to ridicule me by making me seem stupid and unable to understand what I'm asking for is kind of insulting, but I'll ignore that and focus on the discussion.

No. I disagree with your position. And you don't seem to put as much effort into your thought process for the ideas and posts in this thread as your moderation effort. You might be an excellent moderator and diplomat, but you can still be wrong on other topics. I appreciate that you are staying level headed even if you think I meant to insult you, just another of your virtues that we have come to expect from you. In return, I will try to be more clear that I disagree with your idea and don't intend to attack you as a person. Sorry if my messages came out poorly.

A tech that would increase at the same time internal recharge rate and robot recharge rate shouldn't be that much difficult to create. And if you want consistency, instead on focusing on the roboports, a "fast battery charging" tech could extend that principle to anything with internal electric buffer and can recharge/discharge (including accumulators, portable batteries, ...). Problem solved.

I'm considering if the effects of faster charging might not be as catastrophic as I originally believed. Depending on how far into infinite researches you have to go to start removing roboports you are maybe forced to do a proper robot base before you make one that can only work with enough research. Mining productivity also makes some designs practical only after a certain amount of research. I think the faster charging would have to start at earliest with space science and be balance tested to really give us data on how it would affect base building.

And since I claim that robot bases are already easy to build and that nothing really needs all the throughput bots can currently handle I might have to rethink my position.

If they are already easy to build, does making them easier after infinite research really change anything? Some claim that they aren't able to build effective robot bases. I guess I have to believe these claims. It doesn't seem like a thing someone could gain a lot from lying about. But while there are some considerations to take into account it's not that much of a puzzle for me. There are other aspects of bot factories that I enjoy.

If one wants to build optimally currently you basically remove all belts and use robots and trains only. I would prefer if belts were viable in a megabase. ANd by viable I mean optimal decision in some cases, not just used in a no-bot challenge. But belts don't have to reach the throughput of bots to be viable, they have to reach the throughput of the machines that they supply with materials and have the flexibility to deal with several materials routed to many different places. And beacons are probably the thing that needs to change to make belt bases a reasonable choice, more than belts themselves need to change. It might not be possible to make belts reach bots in throughput and effectiveness. But once belts are not the bottleneck, bots higher throughput is not an advantage. If bots became a better choice than trains at much longer distances than now that would be an issue though.

[Koub]

Well as long as we disagree, then we're doing things right, it's by disagreeing that we can polish a rough idea into a gem of a suggestion (or just drop it because it was a bad idea after all).

Actually, the reflexion you have in the second part of your post is one of the reasons that led me not to discard my idea for balance vs belts reasons. I don't think such a change would massively make people switch from belts to bots. It would make things less tedious for those who have chosen heavily bot based builds (so more fun for them), while not changing much those who prefer mostly belt with light or no bot usage.

I did a quick and dirty 3600 tick throughput test in editor/creative mod with all research (except cargo size ) to test the influence of the worker speed research.
At tech level 10 (5th infinite research), I had 2.07 times the throughput of the bots without any upgrade (while speed multiplier was 6.65)
At tech level 5 (last finite research), I had 1.70 times the throughput of the bots without any upgrade (while speed multiplier was 3.4)
I'm all for diminishing returns, but the infinite research is not balanced for its cost.

Compared to that, the 4 levels of cargo size upgrade cost almost nothing, and have a huge bang for buck value throughput wise.

On a second though, logistic bots mostly benefit from cargo size upgrade, while construction bots shine the best with speed upgrade.

[Ext3h]

Balance bots vs belts (not a fair comparison btw., you would also need to consider the footprint required for 4MW of power production, and the fact that you can effectively interweave 3 blue + 2 (or 1?) red belts in just 2 tiles), and the cost effectiveness of the research are just two points to consider, but there are more:

User experience, if the system behaves less stable in late game, that's bad user experience.
Like I said earlier, contention / deadlocks are fundamentally a consequence of the dispatch logic, which deals no respect to overloads along the route and dispatches a constant number of robots, despite effectively needing less robots with increased research level.

Actually fixing the contention issues around roboports would require significant work on the dispatch scheduling and path finding for worker robots. If that was given, "you need to build more roboports" becomes a valid solution. However, that is some pretty advanced path finding problem we are talking about (remotely related to flow field based path finding with dynamic cost stamps), so it's neither easy to solve programmatically, nor is it coming as cheap as the current implementation at run time.

So, with the issue at hand that constraining the throughput by roboports isn't working so well, due to implementation details which are most likely too expensive to address, trying to uphold the balance in terms of throughput per footprint inevitably comes at a worsened user experience.