Robots are stupid ? They dying en mass.

[Okami]

Yesterday I build a new Storage Area with an Item sorter in my Base, replacing all the old Storage Chests with Active Provider Chests, to get things carried to the new Area.

This is what happened. Some Big swarms of Logistic Robots came from everywhere. 580 pcs, all busy grabbing and flying. But then they needed to recharge and every single robots bunched up in front of the same Roboport. It seems the Port can charge only 4 bots a time, so lots of bots run out of power and went down. I lost over 100 bots in less then 2 min. Sad Days for my little transport Armada.

And even in normal Day Duty, some bots always dying. Should I do something different ? I mean I have 23 roboports...need more ? Or maybe should the recharging changed ?

[sillyfly]

I don't think the robots are being stupid, or that the charging mechanic is fundamentally flawed. It makes sense that only a few robots may be charged by a single roboport at a time. I assume the problem is charging throughput - you have all your robots at the same place, all needing recharge. They don't have enough electricity left to make it to farther ports, so they all queue up near the closest one.

I would try putting more roboports close by to where you need lots or robots flying at the same time. This way the robots have lots of close by options to charge, and don't need to all queue up by the only port that they can safely reach.

[kovarex]

We also might reduce the idle power consumption radically.
This way, the player would still be punished by not having the roboport covarage thick enough by longer waiting times, but the robots would die because of it rarely.

[Garm]

Another problem - they greatly prefer closer roboports, sometimes staying in queue longer at nearby one instead of travelling to the next one near. Because of that multiple roboports per specific area are needed unfortunately.

[Okami]

They don't have enough electricity left to make it to farther ports,

I think they have, the next roboports are not far away (half screen size), and they have about 30-40KW left.

they greatly prefer closer roboports, sometimes staying in queue longer at nearby one instead of travelling to the next one near

This may be it. I'll try it out

[kovarex]

There is number, that specifies the ratio of <distance to different roboport>/<queue size of robots waiting> optimum.
Currently, to choose the more distant roboport, The distance must be at most <Number of robots in the queue and on the way> / 2.
So to choose roboport that is 10 tiles more distant, it has to have 20 less robots waiting in the queue.

This number should probably be changed as well, maybe it should be one in queue per one tile.

[ssilk]

Well, that must be tested a bit, perhaps more factor 1.5 or so, but I think the direction is right.

[Zourin]

That may not be a bad idea to extend the 'look for gas' range on them. Some areas, like roboticized train stations, are notorious for having piles of robots activate simultaneously and you can easily predict the need for more than one roboport to service them.

For everywhere else, you may have roboports parked at maximum range for general coverage. Sudden, long distance spikes in demand can cause this. Another possible logical patch job would be having bots decide to recharge *before* they pick up items if they're below half and there's no queue. That can desynchronize recharge needs considerably and prevent long queues. Bots would favor an early no-queue recharge over having to stand in line at the last minute.

[tralala]

I think robots should be able to "park" themselves inside the Roboport if all charging stations are occupied and thus prevent themselves from dying. They should do so in case they can't reach the next roboport with the remaining energy.
If the roboport is full they still would die (but that would require extreme circumstances).

[BurnHard]

1.) No idle power consumption (yeah, not realistic, but neither are the belts)
2.) Much more spreading to other roboports, depending on robo-speed

[Garm]

There is number, that specifies the ratio of <distance to different roboport>/<queue size of robots waiting> optimum.
Currently, to choose the more distant roboport, The distance must be at most <Number of robots in the queue and on the way> / 2.
So to choose roboport that is 10 tiles more distant, it has to have 20 less robots waiting in the queue.

This number should probably be changed as well, maybe it should be one in queue per one tile.

Well it appears the average charging time is somewhat static (I haven't noticed a lot of deviations in time between drones) AND knowing the drone speed (level of tech researched) I believe it could be possible to modify this formula to compare time. In fact it might be possible to calculate best option for each drone individually:

for example when drone decides to recharge it can request something similar as:

Drone time = Tdx = Distance to Port X * Drone speed;

Port time = Tpx = # drones queued * charge time coefficient;

Weighted time to X = Tdx * W, where W = Tpx/Tdx within interval of [1,Tpx]

OR just compare Tpx and Tdx and use larger one.


With this each drone can parse all roboports within the network and opt for most optimal one. In order to decrease amount of useless calculations drone can start from closest roboport and work its way up until one of the ports yields Tdx instead of Tpx or there are no more ports. Then compare each value and use smallest.