[0.8.x] Logistics Robots

[TGS]

The new Roboport is an awesome addition, however with the introduction of the recharging mechanic and the fact that there are only four slots to recharge there seems to be a significant limit on the amount of logistics robots you can have active at a time. Far far below the Roboports actual capacity. If they are extremely active they will all work until they get to around ~50 on their charge then they all queue up for recharging and it seems like if you have 60-80+ for one roboport you will end up losing a few to running out of power.

Not really sure how you'd go about fixing this without altering the graphic of the port. I suppose you could increase the maximum charge capacity and fiddle with the point at which they start going to recharge. Try to stop them bottlenecking all at once. Or you could have a failsafe function where if their power goes below 5% while they're waiting to be recharged they instead dock and remain docked for a certain amount of time. Then they exit fully charged. But that would seem somewhat awkward.

Or you could drastically reduce the costs of the roboports. They are extremely expensive both to build as well as to supply with power, not to mention they are rather massive. So having several in a small area to keep a bunch of bots charged seems rather silly in its own right.

Another possibility would be that instead of having you 'lose' the bots when they reach 0 charge... they could have their speed reduced by 90% or just have some sort of penalty. As much as the bots themselves aren't grossly expensive, losing them due to them running out of power while they're sitting 'queued' up to recharge is a bit silly. They're already out of action not doing their job because they're waiting to recharge, but they don't even manage to get there before disappearing at times.

On a final note I just want to say, I like the mechanic of them requiring charging. That's a good solid mechanic, I just think it needs to be balanced better so that you don't lose drones because your roboport can't supply all of them with power before they run out.

[kovarex]

Hello, we didn't have the time to play the whole game with the roboports so far (just some testing), so I have no idea about the balancing.

There are lot of things that could be altered to make it easier:

• waiting robot would approach the charging spot before the charging of the previous finishes, so the charging place is used 100% of the time, not just ~~50% like now
• Bigger electric capacity of the robots
• Faster recharging
• Smaller energy consumption of the robots
• When choosing robots for charging, the robot with smallest amount of energy should be choosen as next.
• Better reassign to roboports when charging logic.

I'm not sure about the logic with movement penalty.
If it is still an issue, maybe the robot could fall to the ground and stay there for some time, and other robots could recharge it.

[Neotix]

Maybe settle that by adding few tiers of Roboports. Higher tier = more slots and faster charging. Additionally Roboport could have queue slots.

So if you want more bots, you have to build Roboport with higher tier.

[TGS]

Hello, we didn't have the time to play the whole game with the roboports so far (just some testing), so I have no idea about the balancing.

There are lot of things that could be altered to make it easier:

• waiting robot would approach the charging spot before the charging of the previous finishes, so the charging place is used 100% of the time, not just ~~50% like now
• Bigger electric capacity of the robots
• Faster recharging
• Smaller energy consumption of the robots
• When choosing robots for charging, the robot with smallest amount of energy should be choosen as next.
• Better reassign to roboports when charging logic.

I'm not sure about the logic with movement penalty.
If it is still an issue, maybe the robot could fall to the ground and stay there for some time, and other robots could recharge it.

Ah yeah. Thing is that I wasn't too sure on what would have been possibly from a practical coding standpoint. I thought about some of those but figured they might be bloated/clunky. But those are all better solutions to mine I guess, aside from the faster recharging. Though if you kept the recharge rate the same and increased the capacity that would help. I really do like the mechanic as it makes it seem more logical and the robots don't just fly around forever with no limitations. But that being said imo you should never be losing robots because they run out of energy, If the roboport has the capacity for 32x7 (224 bots) then it should have the capacity to keep them all charged. Without having to deploy additional ports.

Waiting robots approaching before the other one is about to finish is a great idea.
Bigger capacity is... probably a cheap but effective fix provided you make sure you make them go to charge with enough time in congested instances.
Smaller consumption should probably be the case anyway. Especially if they aren't moving. Basically if the bot is doing nothing but floating there idling waiting to recharge it should only be using like 10% of its current usage rate or something.
Definitely on the choosing robots with the least amount of energy should get to recharge first..

Not sure what the last point means, other than perhaps give roboports the ability to define certain atributes about the bots? IE a slider of when to go recharge. Perhaps a slider of how many maximum bots can be 'out' at a single time from that roboport.

Though in the next day or two I will test it extensively to see if I can give you more information. It really is an awesome feature. I love the logistics network/system anyway, and now being able to have your own little isolated networks rather than them all being connected to the same network is just... amazing. Really amazing.

[Dysoch]

Maybe settle that by adding few tiers of Roboports. Higher tier = more slots and faster charging. Additionally Roboport could have queue slots.

So if you want more bots, you have to build Roboport with higher tier.

i already have roboport tiers planned for my mod. They are capable of holding more robots, charging alot faster and holding a larger amount of energy (so the charging doesnt halt or stutter soon after it begins)

but bigger roboports(more charging slots), or even a robotport only capable of recharging (but has like 12 or 16 slots) would be nice

[TGS]

The thing is... slots aren't the problem. The charging is. Strictly the charging. Everything else is fine. That's the problem. There are too many slots for the charging capacity. You can probably fill maybe 2 full slots before you start risking losing your bots if they are working consistently.

Basically if you fill 2 slots with 32 bots each (the max) they'll be alright. Anything beyond that seems to risk them running out of energy while 'queued' up for recharging. I will test it more though. How I tested it was brief, but it was using the map editor to give myself a crapload of everything just for testing purposes. I didn't put everything directly in storage chests. So when I filled a bunch of requester chests full of stuff without highly researched bots they were pretty much working constantly. That constant work meant I had over 100 bots in the air working at the same time. That meant I ended up with a fairly large amount of them queuing up for recharge. Some of which sat there so long waiting in the queue that they ran out of energy and disappeared. They didn't even crash, they literally just disappeared.

[inzain]

id like bigger ones with more charging slots as a tiered thing also, now im avoiding your issue by simply placing more roboports beside each other, 3 are capable of fully supporting approx 200 robots without losing any. i have that setup for my unloading station for my trains, they run almost constantly except when recharging, and i havent lost one to it so far. but it looks funky having 3 side by side, so a tiered system with bigger ones, with more recharge points would be awesome to keep the flow going. yeah the letting them drop to the ground and not losing them would be nice too.

[TGS]

id like bigger ones with more charging slots as a tiered thing also, now im avoiding your issue by simply placing more roboports beside each other, 3 are capable of fully supporting approx 200 robots without losing any. i have that setup for my unloading station for my trains, they run almost constantly except when recharging, and i havent lost one to it so far. but it looks funky having 3 side by side, so a tiered system with bigger ones, with more recharge points would be awesome to keep the flow going. yeah the letting them drop to the ground and not losing them would be nice too.

Yeah, that's the thing though. You shouldn't need to have 3 roboports to keep 200 bots flying. Even if you filled one slot with 32 Construction robots in the roboport filling the rest of the slots gives you 192 bots for that port. I'd say you'd be lucky if you could keep 100 of them in the air with that one port alone.

I don't think there should be a change in the way the roboport charges or can charge so much as the bots themselves need to be balanced so that you could fill a roboport full and that one roboport should be able to keep that entire fleet of bots in the air indefinitely (Provided the port itself is also kept charged) which I've noticed also seems to be a problem. In fact that could have been the problem I don't know I haven't had a chance to properly test it again. I was watching the "Electricity" supply of the roboport and when a considerable number of bots were queuing up, that charge was draining quite fast. I can't recall seeing if it dropped completely though.

[Noro]

To make them dock when waiting for recharge seems to me the most logical thing to do.

[ssilk]

Hm. Want to bring in one more aspect: The roboports are a network. 200 bots is not such a problem, when they are spreaded in a larger area, as I use it. In my biggest network are currently about 350 bots and no big problems till now. The problem appears, when all 350 bots go to one chest and transport it to another. Then this isn't gonna work. And that's the point: Even with only 100 this may become a problem. But I'm sure, that also with more than 1000 bots in a network this could work, if the network is well balanced.

So you cannot say: I put 160 bots into a roboport and then this is it. The number depends on how much are used in average!

So I would suggest some new numbers.

It would be very useable to have a "average load" in the logistics network or three types of average loads:
10 secs avg. load, 1 minute avg. load, 10 minutes avg. load. The load is the percentage of used the maximum available bots. 100% load = all bots used.
With this number over a 10 minute average I can be sure that when the load is going over 80% I need to built more bots in this network (which then could be used for the circuit network to automatically built it).

Another important number is the bots per port. 2 ports, 200 bots, then the bots per port is 100. Simple.

If the bots are equally distributed, there is an absolute maximum, a network can handle per port. This brings us to the next number, the distribution: In a more or less well balanced network, all bots are going to be loaded on every port if equally distributed. If not, we have ports, which are under heavy load, and some, which aren't. This number shows this distribution, by measuring the loadings on every port and if the average loads hits nearly the loads on every pole, the distribution is 1. If one port loads 200 bots per minute and the other none, the average is 100 but the distribution is 0, because the distance of both ports is equal or more than the average bots per port.

[JackGruff]

Yes, the queues become noticible when you approach 400 active bots with ports spaced furthest apart.

But the I think the best idea is what Dysoch had, give us a version of the Roboport that is purely charging stations, the "Chargeport". The Chargeport could have 9 stations and bots would consider using them over the Robotport's stations. Maybe you could even have it that Chargeport has to be adjacent to a Roboport so that coding the logic is much simpler for you.

[TGS]

Yes, the queues become noticible when you approach 400 active bots with ports spaced furthest apart.

But the I think the best idea is what Dysoch had, give us a version of the Roboport that is purely charging stations, the "Chargeport". The Chargeport could have 9 stations and bots would consider using them over the Robotport's stations. Maybe you could even have it that Chargeport has to be adjacent to a Roboport so that coding the logic is much simpler for you.

Yeah, I like this idea a lot actually. The only issue I would see is that it would require additional art and given that they actually 'attach' to the prongs it would have to be large'ish'. That being said, it would be very good to have dedicated charging stations that are a lot LOT less expensive in mats. Cause the roboports are quite expensive early on and honestly I'd like to not have to use the expensive ports strictly for charging.

[slpwnd]

Given our shortage of graphical resources the Chargeport is not going to happen (or at least not soon):) But changing robots to be smarter - do not wait for the charging station to be empty to move there - combined with a little bit faster recharghing should help.

[BurnHard]

When I have covered quite a large area with several roboports, I saw, that the logistic robots all flew to the nearest port after finishing work, queing up there. With all the queuing, it would have been a lot faster if the robots would fly to the next free roboport.

I think, rechargetime is already too fast at the moment and could even increase if the robots would be distributed to the next free roboport if the nearest one is having queues.

[kovarex]

When I have covered quite a large area with several roboports, I saw, that the logistic robots all flew to the nearest port after finishing work, queing up there. With all the queuing, it would have been a lot faster if the robots would fly to the next free roboport.

I think, rechargetime is already too fast at the moment and could even increase if the robots would be distributed to the next free roboport if the nearest one is having queues.

That is already done. The further (regards to A) roboport B is chosen when it's queue is smaller than 2 X (tile distance A to B), but maybe the formula could be optimised a bit.

[JackGruff]

combined with a little bit faster recharging should help.

Make it a research! And if you guys are hesitant to add research to the game, just make it expensive.

One last thing: what do you, the developers, think what the load the bots should be able to handle is? Do you expect them to be able to completely replace all belts? Straight from ore through to everything else? Or just some intermediate product and beyond?

[ssilk]

Logistic bots cannot replace belts. They use heavy amounts of energy. Belts don't.

An example: I have currently a factory which consumes 1000-2000 ore and about the same of copper per minute. And I need in average only 120 bots to transport that to the assemblies, because of this belt/inserter-driven production-streets for electric circuits, or other lower items. If I do it differently, which I made in the factory before, I need more than 400 for the same job! Not to speak from the needed energy...

And another thing is, that the logistic bots transport capacity must be calculated in

Code: Select all

   average distance between two chests * speed * loading capacity

While those of belts are

Code: Select all

   speed * density

(I left away some more variables in both formulas due to unneeded complexity here)

This means: Distance with transport belts are not the same problem as with logistic bots. Or logistic bots makes much more sense, if they transport in a really concentrated areas. But that is sometimes difficult to built and most players tend to make the factory area wide.

For balancing: I mean this is not so clear yet. Currently I see many players trying to do too much with logistic bots. I think it should be a bit more expensive. But I don't have a really good idea. Maybe the bots should need more energy, if they take more items? So that the distances they can do get shorter? An research for better bot-accus will help, but that means that the loading stations come to the limit of energy they can use. This means longer loading times, longer queues, more spread of the bots to load, more bots needed to transport, slower transport. There is then a point, where no more bots in an robotic network make sense.

In other words: I think it makes sense to use everything in the right amounts. Some "production streets", for example for the electric circuits, which use belts/inserters only. They can be really as fast, as with logistic bots, if built correctly. And then logistic bots, which take the core materials and use it for the complicated stuff, which is much less items as if you transport everything by bots.

[Balthazar]

Okay was about to make a thread about this but noticed this was up I always use drones when expanding my mining sites, usually setup with a train stop in the middle and then cover every resource deposit in a radius of 4-5 roboport areas with miners. Its very fast and easy to setup and take back down when the miners are depleted, but i've noticed a lot of quirky behavior as well.

I think one of the biggest contributors that you missed is the launch speed; a station can launch its entire drone capacity in about 1 second; if they're launched in response to a train pulling in or new storage being added, any new spike order, most of the drones will follow the same route, and since they all launched in the same 1 second window they will all run out of energy in the exact same spot and at the exact same time, which creates a LOT of the congestion. I have hundreds of ports on a new mining site and the vast majority are always empty, but a few unfortunate ones get massive congestion. (See pic 1) Okay this particular example was kinda forced by putting a bunch of requester chests down, but it typically happens whenever the drones get a big new order, like a train rolling in, removing a bunch of mats from requesty chestys. I think a rework of the routing logic is definitely in order, at least once a link gets congested drones shouldn't spend forever waiting for a slot when there are multiple vacant ports adjacent to the one they're waiting at.

If you're dealing with a high stress net you need silly amounts of roboports; i have this small station for recieving mining shipments then sorting the materials and sending them on to where they need to go and i need this many ports to keep the drones from falling down I was losing drones before i added the 28 ports in the middle.

I don't think reducing the drones energy consumption is a good idea; they're allready a huge benefit over inserters and having them be less energy efficient just seems kind of fair. I also have to say that i dont think increasing the energy capacity will accomplish anything at all; it just delays the congestion since the drones are still going to run out of energy at the same place and time, and recharging will take even longer. The rest of the options you listed all sound good tho, and we could definitely do with more research

Oh and finally, please nerf the overlays when more than one station is around (Pic 3)

[ssilk]

Very good idea! Yes, the output of the logistic bots from the roboports should be a little slower.

I watched the work of the bots this week for over 5 hours. I tried several things with them.

For example I let them move the output of some mines over some distance. I made some notices.
Distance 200 tiles, over 200 bots needed. Distance 150, much less, only 110 bots needed. Distance 100: only 60. With a distance of 300 I needed over 400!!

They don't behave as I stated in my formula in the previous post! There is no linearity, it's a bit quadratic. This is because of the limited load capacity of the roboports. Either the bots wait,or they search path to a Roboport, which is not on the route. In both cases they need more time to transport. This brings in this quadratic growing with the distance.

And that brings me to another idea, As your firs pic nicely shows, the bots use always the shortest path to the destination.

But I think it would be faster, when they use paths over other roboports. I mean they could use a similar algorithm as the internet routing: If one path is full ( because the roboports are full of the loading stations) they should search a way over the other roboports. Which might be longer, but in the end it's much shorter, because it's not so crowded.

[Balthazar]

But I think it would be faster, when they use paths over other roboports. I mean they could use a similar algorithm as the internet routing: If one path is full ( because the roboports are full of the loading stations) they should search a way over the other roboports. Which might be longer, but in the end it's much shorter, because it's not so crowded.

Theres another problem i forgot to mention; when you're trying to connect miners you end up having to cover every possible path the drones can take or you'll lose drones when they fly outside the net. For example a setup like this:

A - - - - B - - - - C
|
|
|
D
|
|
|
E - - - - F - - - - G

Will lose drones if they travel from G to C because they cannot recharge in the area thats not covered by roboports. Your suggestion would fix this and make it much easier to have a branching structure to remote mines without covering the entire map in a massive grid