Improvment to Roboports Charging

[PirateofAE]

Right now with how the bots find a Charging port to charge, It doesn't seem to take into account, the Rate of charge/Number of pads, that a Charging point has.
Example, with bobs mods, Which has a 1 Pad Range extender, 4 and 9 pad Charging pads(that dont extend range).



If a Line of bots comes to this setup, it more less splits 50/50 between the two charging points, The Tower, with its one slow pad, and the 4 pad with a bit better charge rate. The 4 Pad clears its Que far far faster than the Tower, Yet the bots already holding for the tower, don't seem to go look i can charge at the 4 pad instead waiting for this 20+ Que.

My suggestion is thus, At close Range, 2-5 Tile separation, Charging points work collaboratively, Ie instead of this scenario of a 1 pad and 4 pad Q, its a combined 5 pad Q, (A vanilla scenario would be two roboports like this would be a 8 Pad Q instead of two 4 pad ques)

[bobingabout]

Alternatively, take the number of pads + charge rate into consideration when joining the queue in the first place, so instead of a 50/50 split, it would be somewhere between 10/90 and 20/80 for the LZE/Charging pad.

[ratchetfreak]

Alternatively, take the number of pads + charge rate into consideration when joining the queue in the first place, so instead of a 50/50 split, it would be somewhere between 10/90 and 20/80 for the LZE/Charging pad.

or periodically check if free charge pads are available nearby when in a long queue.

[PirateofAE]

Alternatively, take the number of pads + charge rate into consideration when joining the queue in the first place, so instead of a 50/50 split, it would be somewhere between 10/90 and 20/80 for the LZE/Charging pad.

Alternatively, take the number of pads + charge rate into consideration when joining the queue in the first place, so instead of a 50/50 split, it would be somewhere between 10/90 and 20/80 for the LZE/Charging pad.

or periodically check if free charge pads are available nearby when in a long queue.

Both valid other ideas/options

[bobucles]

The biggest hinderance to the charging process happens after bots completely dry out. Normally those last 2 tiles to the pad are quick when a bot blasts its last bit of energy to refill. But after going flat, those same two tiles become a massive burden. The roboport charging process is nearly cut in half once those bots start running in empty.

Fix that and roboports will be FAR more effective.

[OldVamp]

It seems like roboports should have more charging pads
they hold 350 bots, if it followed the same ratio as a personal roboport (1/5) it would have 70 charging pads
could they have at least 8-16?

[Photoloss]

The biggest hinderance to the charging process happens after bots completely dry out. Normally those last 2 tiles to the pad are quick when a bot blasts its last bit of energy to refill. But after going flat, those same two tiles become a massive burden. The roboport charging process is nearly cut in half once those bots start running in empty.

Fix that and roboports will be FAR more effective.

Not just that, bots miscalculate the distance to the nearest port and go flat before even reaching the queue ring. Not sure if this is a consequence of the 0.13 changes but it certainly seems more prevalent now.

[Rseding91]

Robots finding and going to charge is already the most expensive thing CPU wise robots do with finding a roboport to station at being right behind that and you want to increase the CPU cost by some large factor?

Probably never going to happen.

[Dark_star]

Does a traveling Bot when it reaches some value (like 10%) charge remaining, do a calculation of distance/energy-use to target vs energy remaining. If short then look for nearest charging station ?
Note: still problem of moving target (character) calculation.

[Rseding91]

Does a traveling Bot when it reaches some value (like 10%) charge remaining, do a calculation of distance/energy-use to target vs energy remaining. If short then look for nearest charging station ?
Note: still problem of moving target (character) calculation.

No, that would add even more cost to using robots. They go off the prototype property that says "when below X percent power, go to charge".

[ssilk]

Well, this showed me, that this problem needs a fundamental (not like discussed here) change or should be hold like it is. Anything between is a waste of development-time.

[bobucles]

If bots look for the lowest nearby queue they should do okay'ish. A faster charging station will naturally feed bots more quickly and thus have a consistently lower charging queue, thus taking in the rest of the bots.

The only issue I have with bots is that bots with energy charge faster than empty bots. IMO any bot should approach a station at full speed.

[Ghoulish]

The only issue I have with bots is that bots with energy charge faster than empty bots. IMO any bot should approach a station at full speed.

I surmise that robots slow down when out of charge just to make things more life like? Which is fair enough. However your point is valid in that it would be better if they did not slow down. There might well be a balancing reason behind the slowing down of robots too, can anyone think of one?

I would like to see bot charging looked at, as it does seem to be a little less than optimal, though I did read what Rseding91 said about cpu usage.. And appreciate the fact that because I am not a coder/dev I really don't understand the complexities involved. However, Faster charging pads (upgraded pads via research) Would be something that would greatly help, and wouldn't add any additional load, so this at least to me seems to be a needed feature, and would give another thing to research, which would be great too.

Though I think there is a balance issue, the old bots vs. belts debate - if you buff bots, what about belts?

[malecord]

They go off the prototype property that says "when below X percent power, go to charge".

Really? I thought it was "when you're 1 pixel away from destination, turn back and go to charge"

[bobucles]

Really? I thought it was "when you're 1 pixel away from destination, turn back and go to charge"

If a bot is X distance away from its target with Y charge, then it can implicitly know whether it needs a charge or not as the energy required is a simple matter of distance + required time. It may be quicker to do the check once rather than checking every tick update to see if it's low enough. Obviously this sort of calculation will screw up if there are any effects that snare or obstruct bots, or if the target moves. If the time or distance to the target is unpredictable, then they won't know if their battery can make the trip or not.

Once a destination is chosen, it is also possible to predict exactly WHERE a bot will need to seek out a charging station. So a bot going long distance can rally directly to a charging station near its destination, instead of waiting for the need.

I surmise that robots slow down when out of charge just to make things more life like?

Perhaps I was too unclear. I mean those last 2 tiles where the bot hovers around waiting for a charge. If the bot has enough energy, it can move directly to the charge pad with minimal downtime on the pad. If the bot is empty, it has to limp the entire distance. If you have seen a roboport with happy bots vs. one with empty bots, the difference in the number of charges/minute is pretty major. A bot limping over to the opposite corner's charging pad can take as much time as two normal bots or maybe worse.

That's why the difference between an okay network and an always charging network can seem so extreme. An okay network charges bots twice as quickly as a strained network, which obviously only strains it further.

That's why I think bots should rush those last few tiles regardless of their charge status. Or I dunno. It is a kind of annoying thing IMO.

[ssilk]

Hm. I repeat it: It's not worth going deep into this and change here a bit and there a bit. I will make nothing better (so much better, that it is worth the afford).

What we need instead is a basic change in how bots find the paths for their tasks.
And that has so many needs and wants, that I think here is the limit for a community to make suggestions.

BTW: A related issue is described here: viewtopic.php?f=18&t=29217 Logistic Bots stuck in far parts of Base
See also other links here.