robot charging improvements / balances

[AartBluestoke]

TL;DR

I would like the number of robots 'seeking charge' to be visible, and robot charging rate to be balanced

What ?

1) I would like a logistics network to show the number of robots 'seeking charge', not just 'total' and 'available' , because a naive assumption is that if you see 50/500 then there are 450 logistics requests being actioned at the moment, except there could be a 200 robot charging pileup in one corner of the base

2) a roboport should only support/hold 100 robots, not 350 (see calcs below; at the moment, at no research a roboport can support 222 robots, assuming 100% of time is spent charging) -- this will push the problem of roboport density out to when some speed research has been done, rather than having a default position of each roboport oversubscribed by 150%.
At worker speed 5 research, this is even wose with the 54kw draw resulting in each 'charging pad' supporting 18 bots, therefore a roboport can't even fully charge 1 stack of bots in flight, while holding 7.

3) it is a feature of high end bot based bases to have to place %many% roboports next to each other in order to get sufficent charging, therefore i propose research for one or more of the following:
a) robot energy capacity (allows 1 roboport to have a higher % of time spent charging, as each robot returns less frequently)
b) roboport charging speed (so that 1 robot can be charged quicker)
c) roboport charging count- if the roboport can hold 350 robots, why can't it charge more than 4?

4) if the research isn't a reasonable request, then a new building for the purpose of charging robots only, but which can't hold them or contribute to the logistics network (this last one is to keep the tick cost down.

Why ?

The current display of 50/500 doesn't let you know that you've got a 200 bot charging pileup in a busy corner with 1 roboport
if you respond to saturated 'bot use' by adding more bots, this doesn't help, as you just end up with more bots seeking charge, and having to travel further wayay, as this is caused by having more bots flying in the vicinity of a roboport than can be charged by it

As a supplimentry issue, to help in situations where you just build 10 roboports next to each other to keep up with the localized robot use (eg: train unloading), a charge rate research, or 'charging at the same time' research, so that 1 roboport can support a higher bot flightpath density

that a roboport can hold 350 bots, and charge 4 at a time doesn't help ...

running the maths ...
1 robot in flight uses (at slowest speed, this is only worse at high tech) 3kw+5kj/m , and 3tiles/second; 18kw.

Assuming the roboport is able to charge 100% of the time on its 4 charging ports (1MW each), then 1 roboport can support 4,000kW charge/18 kw per robot = 222 robots in flight.
This means that any time you have more than about 150 robots working near a single roboport, you can end up with an infinite number of 'bots' charging as more will request power than the roboport can supply

at worker bot speed 5 (+240%) each bot needs 54kw in flight, therefore each charging pad can only support 18 bots, and each 'port theoretical maximum is 72 bots.

[eradicator]

3a) https://mods.factorio.com/mod/Robot_Battery_Research

[Koub]

This long discussion is closely related to the root cause OP is trying to address
Also this suggestion is very similar, at least in what it aims to address.

[AartBluestoke]

I agree with the gist of the earlier discussions; and the calculations i've done do appear there.

My primary suggestions for improvement are different though; suggestions 1,2, and 4 don't increase the asymptotic efficiency of 'bots, just allow the player to manage the observed bottleneck of charging rate better.

Suggestion 4 doesn't alter the efficiency of bots, as it is equal to the current solution of many empty roboports, just with less tick cost as they only need to be taken into account for seeking charge and not other logistics tasks. It also moves efficient solving of this problem from 'just place many roboports' to 'what is the correct roboport/charging pad ratio at this location, for this density of robots.

suggestion 3a is a minor increase to the utility of bots (they are able to travel further before seeking power, but will require more roboport time to recharge; these effects should balance, allowing the 'queue for charging time' animation to be a less significant portion of the total charging cycle.

Suggestion 3b,c does alter the long term utility of bots, however at endgame being able to replace 10 roboport with 1, doesn't change anything, as people already place 10, then complain about the load balancing between them, and i would estimate the increased complexity of the resulting logistics network contributes to tick cost (unmeasured ... some numbers here could be nice for a bot based mega-base, but don't know how to separate out these issues)

It seems silly that there can be more 'bots requesting charging at a port than the port can ever physically provide, even at 100% charging time, that is the core 'balance' issue that i'm trying to address.

Perhaps each 'port could keep a tally of the number of bots requesting charge, so it would know the number of seconds until a charge is available (which bots seeking charge would take into account and travel further away for charge), and reject further charging requests if it is beyond 'infinite' (222/movement speed boost bots queued); the reason being is if there are this many queued, then the currently charging bot will need charging again before the current 'bot seeking charge would get a turn, resulting in an infinite pileup.

[AartBluestoke]

https://mods.factorio.com/mod/Robocharger is the closest mod to what i was thinking of for suggestion 4, although i don't know the balance of a 10'bot charger in 2x2 area vs the intent of the devs.

[Serenity]

Bob's logistic's mod also has a great approach by breaking down the roboport into storage, charging and network antennas. I'd love that in vanilla

[slippycheeze]

2) a roboport should only support/hold 100 robots, not 350 (see calcs below; at the moment, at no research a roboport can support 222 robots, assuming 100% of time is spent charging) -- this will push the problem of roboport density out to when some speed research has been done, rather than having a default position of each roboport oversubscribed by 150%.

The current display of 50/500 doesn't let you know that you've got a 200 bot charging pileup in a busy corner with 1 roboport
if you respond to saturated 'bot use' by adding more bots, this doesn't help, as you just end up with more bots seeking charge, and having to travel further wayay, as this is caused by having more bots flying in the vicinity of a roboport than can be charged by it

Robots don't care about which roboport they were initially put into, they just charge at the closest port -- unless the queue and/or wait time is long enough, in which case they go to the next closest. If you decide to place a roboport with more robots than charge capacity, I'm pretty sure the solution is like placing too many steam engines for your number of boilers: you broke it, you get to keep both parts.

I feel like the requests here are, roughly, "please ensure that the bad assumption that robot logistics are a zero-thought thing is accurate." It seems to me that it comes up a lot: people assume that robot based logistics are trivial, and the point is that you stop using hard things like belts, instead using this easy, zero thought thing.

Which isn't the case, and never was. Robot logistics are gonna suck with poor network design, just like belt transport, and train transport, suck in those cases.

I'm also pretty sure that this being a design challenge is valuable in terms of gameplay, and that scratching at the edges like the "how many robots waiting to charge" metric won't make the challenge go away, just move it. I mean, solve that, and isn't the next question "why do my robots store things in a far away storage chest, when there are empty slots in a close one", and then, "why do robots go into different roboports than I first put them in", or "why do robots path direct over the lake instead of port-hopping around the edge even if it is longer", or one of the other frequently asked questions about network design?

I think that the Robocharger mod you mentioned is the best answer if you want "provide enough charging capacity" to go away as a problem. It, indeed, makes it moot -- and various other mods like Krastorio have their own versions with or without logistic and construction area extension -- but I'm pretty sure it is in the same bucket as adjustable inserter pickup and drop-off direction.

The fact it isn't as easy as it could be is no accident, but intentional design, because constraints require creativity, and creative design is where the fun is in Factorio.

[AartBluestoke]

@slippycheeze, i agree this challenge is part of the built in game.

My problem is that there is not enough information to diagnose some of the problems.

The second problem is that the opaque problem can occur at the base research level, when you are are potentially trying to work out how other logistics challenges (hence change 2) to make it that you don't have to solve all the logistics problems at the same time; charging only becomes an issue as you scale the network, and can't easly be triggered at the base research level (and to be honest, change 2 wouldn't even be noted by almost everyone).

the final issue i was looking to address is that with perfect understanding of how roboports work, the only way to actually make them work at scale is to just throw roboports with hugely more capacity than could ever conceivably be serviced at it:

Do we realy want a game where best practice is: build many robo ports, but your network is stuffed if you ever use more than 5% of the storage capacity you can have? -- that just seems like a trap for no good design reason. My last 2 changes were there to mitagate this issue.

Together these mean that robot charging is an issue that can be better managed, and yes, this will push a higher percentage of the questions to the other questions you mentioned, but isn't that a good thing:
your example of "there are 5 ways that newbies don't understand robots, so lets not give them the information / potential research paths to fix one of them because the others still exist" is not in line with the welcoming community that i enjoy around here.

[slippycheeze]

@slippycheeze, i agree this challenge is part of the built in game.
My problem is that there is not enough information to diagnose some of the problems.

...and, if it isn't clear, I don't hate your idea or anything. I'm not sure some parts are going to produce "better gameplay" if removed, but OTOH, I'm also not a great example of how most people think about this sort of thing so I know I can be a bit off about what is better. Thank goodness Wube don't depend on me for that.

Also, yeah, you called out stuff that is genuinely a potential issue at each stage, no question.

The second problem is that the opaque problem can occur at the base research level, when you are are potentially trying to work out how other logistics challenges (hence change 2) to make it that you don't have to solve all the logistics problems at the same time; charging only becomes an issue as you scale the network, and can't easly be triggered at the base research level (and to be honest, change 2 wouldn't even be noted by almost everyone).

I'm not following you here. If you want to expand, since the devs might hit the same confusion, I don't follow quite what you mean here.

I *think* you are saying that change 2 is about very large™ logistic networks, and isn't a problem for most people. So it is about helping out the, IDK, like, meganetwork-builders. Is that correct? (I mean, like, some group of people build big logistic networks, and I have no good name for them. No judgment or whatever intended.)

the final issue i was looking to address is that with perfect understanding of how roboports work, the only way to actually make them work at scale is to just throw roboports with hugely more capacity than could ever conceivably be serviced at it:

Do we realy want a game where best practice is: build many robo ports, but your network is stuffed if you ever use more than 5% of the storage capacity you can have? -- that just seems like a trap for no good design reason. My last 2 changes were there to mitagate this issue.

I'm not sure, TBH. I mean, I used the robocharger mod, and now the Krastorio equivalent, because I think that is a genuine problem, I figured out how to solve it with the base entities, and now I don't care about it so I use a mod to make it go away. I'm just ... I don't honestly know that it would be any worse with roboports instead of charging stations, if I had planned that mall better in the first place, y'know?

I do have way more roboports than robots at every station I use them for load/unload work -- usually 50 or 100 logistic bots, and two roboports since I use one for automatically managing the count at the station (read robot counts) and a second for reading logistic network content to eventually ship out anything that shouldn't be there with LTN. So ... I definitely feel you on that. If I could read both data from one roboport, I'd totally do that.

Oh, and and practically: having used both robocharger mod (10 x charge ports, no network extension, no robot slots) and krastorio mod (?? but probably around 6-10 charge ports, with network extension, no robot slots), and considered how more charge ports at an existing roboport would change my design, I'd say that the best gameplay I got was "robocharger" -- I'll probably go back to it, even though the graphics are less pretty than krastorio. I long since stopped using their big drone hub, with the 200x logistic and 300x construction range. Turns out that a network that big is annoying to work with, even at a base distributed significant distances between each component, and using trains to move content between them. (I think even a 6 chunk / 192 tile gap between entities worked out annoying with the drone ports because I ended up accidentally hitting the other construction zone when I turned out to be crowded at that size.)

Together these mean that robot charging is an issue that can be better managed, and yes, this will push a higher percentage of the questions to the other questions you mentioned, but isn't that a good thing:
your example of "there are 5 ways that newbies don't understand robots, so lets not give them the information / potential research paths to fix one of them because the others still exist" is not in line with the welcoming community that i enjoy around here.

I'm sorry I gave you that impression -- I wasn't trying to be unwelcoming. I know I have trouble with that, though, so if you can tell me (here, or privately, I don't mind) anything specific that contributed, I'd be very happy to learn how I can do better.

I mean, since that isn't what I wanted to say, I failed in my goal of communicating effectively.