Logistic Network Needs to be smarter

[Escadin]

I mean the bots are dumb AF. There is a lot that could be done to improve their behaviour like letting them observe their tasks to get an update should it no longer be required or various distance checks when it comes to deciding which bot is issued a task and which task it should be. Better task scheduling couldn't hurt either. And of course, a little more control over their AI. Like, additional entities (beacons etc) that allow is to guide them and give us more control over their behaviour.
I don't want to go too much into detail here since this is not supposed to be a suggestion.

The question is: Would that be feasable at all? I mean not only with the scope of their release schedule but also from an optimization point of view. Would it be a bad thing if we generally had to build less bots (with larger cargo) but they're smarter and more efficient in return? Is there any time left for them to implement this until release?

[Syrchalis]

First improvement I would put on the list is to make bots not cut corners. While shorter, it makes it impossible to connect outposts to your network, because the robots will not go along the tracks of the train that might have turrets and are secure, but they go the direct route which can get them killed easily. So basically they should try to stay within the construction area of the robotports when traveling.

[theRustyKnife]

I think the bots are dumb for a good reason: performance. The way they are now, they're really efficient in terms of CPU time, so tens of thousands of them can be used without too many issues. If they were to be smarter, they would have to calculate many more things, thus taking a lot longer than the current system where simply the closest (?) bot is sent to do the task and flies straight to the target no matter what.

Indeed, I wouldn't mind them being smarter either, but I'm certainly willing to make the sacrifice for performance.

That's just my thought tho - I don't know how the game's code actually works, but I think this is a likely scenario.

Cheers TRK

[Escadin]

First improvement I would put on the list is to make bots not cut corners. While shorter, it makes it impossible to connect outposts to your network, because the robots will not go along the tracks of the train that might have turrets and are secure, but they go the direct route which can get them killed easily. So basically they should try to stay within the construction area of the robotports when traveling.

What I would love to see in this regard is a guiding system that the player can install. I.e. a bunch of entities that give you control over some aspects of the AI. Essentially, they could act as the corner pieces of belts making bots behave like belts but you only have to place on entity every X tiles instead of the usual full coverage. That would also include equivialents of splitters that force bots to evenly distribute their cargo.

[Escadin]

I think the bots are dumb for a good reason: performance. The way they are now, they're really efficient in terms of CPU time, so tens of thousands of them can be used without too many issues. If they were to be smarter, they would have to calculate many more things, thus taking a lot longer than the current system where simply the closest (?) bot is sent to do the task and flies straight to the target no matter what.

Indeed, I wouldn't mind them being smarter either, but I'm certainly willing to make the sacrifice for performance.

That's just my thought tho - I don't know how the game's code actually works, but I think this is a likely scenario.

Cheers TRK

That's what I asked. And also, why I ask if having less bots but smarter and with more cargo would be an acceptable alternative.

I have no idea how they programmed the bots either. I know, that I would have tried to copy the concept of Java's threadpooling and completionservice and then make the scheduler based on distance checks and longest-queue-first (for the task queue) with a priority spike for repairs.

[theRustyKnife]

having less bots but smarter and with more cargo would be an acceptable alternative.

That's a good point and it might indeed work quite well. The only other reason I can see then is the complexity of coding such AI. I'm pretty sure the devs have better things to work on, but that doesn't mean this shouldn't be at least considered.
Maybe Ideas and suggestions would be a better place for this?

[quinor]

Bots are supposed to be dumb so that they require some thinking to use and don't replace trains and belts completely. As long as you're using them properly (networks over small areas, convex networks etc), they behave just fine.

[Escadin]

How could they ever replace trains with their speed or belts with their tech requirement?

[theRustyKnife]

How could they ever replace trains with their speed or belts with their tech requirement?

Well, I suppose there are people willing to tear down their factory to replace all belts with bots. Then again, those people probably already use bots for everything already...
Trains are so superior in terms of raw throughput, that I don't think bots will ever have a chance in replacing them. Unless they were buffed like crazy, but that's not what this is about.

Additionally, if you're really worried about balancing, you could just make them suck tons of power, to the point where that would be the limiting factor in how many bots you can have.

Cheers TRK

[bobucles]

You can solve most of these problems by just building smarter. If you need long distance travel use trains or belts. Don't trust bots with huge networks. They work best when they're servicing a smaller area.

[OdinYggd]

First improvement I would put on the list is to make bots not cut corners. While shorter, it makes it impossible to connect outposts to your network, because the robots will not go along the tracks of the train that might have turrets and are secure, but they go the direct route which can get them killed easily. So basically they should try to stay within the construction area of the robotports when traveling.

What I would love to see in this regard is a guiding system that the player can install. I.e. a bunch of entities that give you control over some aspects of the AI. Essentially, they could act as the corner pieces of belts making bots behave like belts but you only have to place on entity every X tiles instead of the usual full coverage. That would also include equivialents of splitters that force bots to evenly distribute their cargo.

Or a 'restricted area' transmitter that you can place in order to prevent the bots from pathfinding across it.

If their path would take them into the restricted area, the bot aborts the job and the job is returned to the queue in the hopes that another bot in the system could eventually fill it.

This shouldn't result in a major penalty in computation, but that alone would have some snags in which if there are no bots with line of sight to the obstacle jobs waiting in that area will never be filled.


But you really really REALLY should not have large logistic networks. For optimum logistic performance, the logistics area should not exceed 4-6 roboport spans of coverage in any direction. Exceeding that makes the bots take a long time to arrive and encourages charging port congestion when half the bots in the system deliver to the same place and then must queue up at the nearest roboport to recharge.

Use trains to link separate 4x4 grid logistic networks, or build bridge sections where items are requested from one network and active provider into another. These bridges can be easily blueprinted for convenience.

[Escadin]

Not all problem with bots stem from the size of their network.
The decision making when faced with multiple sources and/or multiple targets for a tasks (construction or transport, regardless) is as crude as it can be and will amost always cause a worst case in my experience. The only solution is to have some form of scheduling that includes but is not limited to distance calculations. No amount of segmenting your network can adress that.
Plus, they improved the charging behaviour but given enough bots they still will clog up the queue of a select few roborts out of the many you have clustered where they are charging. In my experience at least...

Side Q: Do bridge sections even work for generic transport? The only solution I can imagine only works for "specific" pre-defined items.

Additionally, the travel distance shouldn't matter if it's an outside/niche job where belts or trains are overkill. Like occasionally transporting solid fuel to train stations all across your base. Setting this up makes it inevetible to span a coherent network all across your base. Unless, of course, you design your fundamental base layout (trainstations, refinery, chem plants) with that in mind which defeats the purpose of setting up bots in the first place.

And let's not forget that personal logistic slots encourage the hell out of covering your entire production area with one big network so you can actually get the requested items delievered.


---

I also don't see what is wrong with making logistic network an alternative to belts (for production areas at least). Combining trains with logistic bots to smelt ore, ship it off in cargo wagons and then again use bots to feed the assemblers should be a viable end-game choice. The required technology is already almost space tier so it's not like this "trivializes" the game. Most of the game that the majority of players experience happens before space science. Especially since the science rework and with recipe difficulty settings.

It's also not that I am too lazy to use belts. I already do. I just would like a different approach every now and then.

[Escadin]

Thinking about your reply OdinYggd, I wonder if the logistic network would be better of if transport bots wouldn't leave their roboport coverage area. I mean imagine they cannot transfer from one port to another and instead you have to setup a storage chest at the next port.
When a transport task comes in the drones will then work like a bucket-brigade.

The obviosu downside: You need to make sure there are always the same amount of bots in every connected roboport or else you'll end up with bottlenecks. However, fixing this could be be automized either by the player or the game.
Player: All we need is the network to broadcast the amount of hooked up roboports together with all the other information.

Game: Bots DO transfer but only very rarely to equalize the network - not to complete tasks.

[Ranakastrasz]

Thinking about your reply OdinYggd, I wonder if the logistic network would be better of if transport bots wouldn't leave their roboport coverage area. I mean imagine they cannot transfer from one port to another and instead you have to setup a storage chest at the next port.
When a transport task comes in the drones will then work like a bucket-brigade.

The obviosu downside: You need to make sure there are always the same amount of bots in every connected roboport or else you'll end up with bottlenecks. However, fixing this could be be automized either by the player or the game.
Player: All we need is the network to broadcast the amount of hooked up roboports together with all the other information.

Game: Bots DO transfer but only very rarely to equalize the network - not to complete tasks.

that would be great. Maybe set roboports each have a minimum robot count they can accept, and robots fly themselves to other roboports if they have too many.

Roboports would be mostly localized. if you want two roboports to share resources you couldn't, and would instead have to supply resources to both.

[Escadin]

Roboports would be mostly localized. if you want two roboports to share resources you couldn't, and would instead have to supply resources to both.

That's not quite what I meant. Roboports would still share resources but instead of having a single bot travel across the entire expanded area you'd have a chain of bots carrying the item from port to port. I.e. first bot carries it from first to second port, drops it off and returns home. Second bot picks it up and carries it from second to third port and so on until they reach their originial destination.
Also, the game could check whether the task is still relevant/active at every "checkpoint"(roboport).

That way, items could move through the entire network but individual bots would never leave their port - other than to equalize bot destribution.


An advantage of this would be that the network stays "balanced" at all times and regardless of tasks. Bots don't travel past their max distance and completion of tasks can be pipelined for optimization. Possibly, this could make finding the shortest distance / route easier since an already existing datastructure can express it in number of jumps like a graph. That would mean a more systematic and structured approach for the player as well.
I don't think the logistic system does any of that right now.

[Killcreek2]

Roboports would still share resources but instead of having a single bot travel across the entire expanded area you'd have a chain of bots carrying the item from port to port. I.e. first bot carries it from first to second port, drops it off and returns home. Second bot picks it up and carries it from second to third port and so on until they reach their originial destination.

You have just described exactly how the bridge / relay system works ingame, between separate logistic networks.

I have a wall design that works exactly like this. It uses 2x constant combinators at the depot hub to set required stock levels of 25+ item types for the entire wall system, and between each logi network is a bridge of 1x decider combinator, 1x requester chest, & 1x active provider chest. That is really all you need to make the system work.

The player shoppe in one of my worlds has materials delivered from the main bus in a similar fashion: Items from the bus to shop input boxes via one network, with the shop using its own internal network. Throughput can be very good over short distances.
Converting it to 2-way delivery or multi-way is a bit more complex, but 100% possible in vanilla. You can set it up in a cell-like structure, with different inputs at different points, and the products will spread themselves between the logi network cells as needed.

[Escadin]

Can you post a string please? And how does the circuit network know what to relais?

[Killcreek2]

Can you post a string please? And how does the circuit network know what to relais?

Ok, simple description first:
The constant combinators at the depot hub output a global "stock control signal" along the entire wall via a long green wire.
Each roboport section has a supply chest, the contents of only that section are sent via red wire to the combinator at the bridge on the input side. This compares the local stock levels in that section [red] to the global stock control signal [green].
If there is less in stock than required, that item signal is sent to the requester chest and a bot will then deliver it from the nearby network.
That nearby network will then request the [now missing] item from the next network, and repeat, all the way back to the depot hub which will in turn take those items from the supply train.
I also have a set of combinators at each roboport, to limit the numbers of bots allowed in each port, and automagically replace any that get destroyed.

Sample Blueprint

Code: Select all

0eNrtXUtv40YS/isBjwtrwH6TPuSye0wuSS7BIjAomZaJSKSWojw7O/B/X5KyLYrsYldVbA0G0cW2LPJTVde7u1j6Gi03h3xXF2UT3X6NilVV7qPbf3+N9sW6zDbd/5ovuzy6jYom30Y3UZltu1d1tax2Vd1EzzdRUd7n/41uxfMN5zb5/MdNlJdN0RT58aP7F1/uysN2mdct7tvdm2pd7JtitVg95vtmUef/ObS/22tuol21bwGqsvvkFnRhxCdzE31p/xL2k2k/rWWsqavN3TJ/zJ6Kqu4uXBX16lA0d9vqPr+rHu6qXV5nRxRxvKXMV93rfXe16H7U+f2QxqJ9JdzNG1L3umdoXed5Obkyef7j+blbphGL8o3Fh6xlrCj3eQ3wFY/4ui/qI43RrfUgK2jxsvamp3yxq6un4t77UTqdLiFqPSAuNUTLvqnqbJ17aJCGR4MZfHwvE4gmw6BJ82jSY5pSgCbLUfj4YvouY6y+SwFw6LD6TtT2hK3tgidTkMOUrFdcVRfxSK9UDNAkYjpRlkdUOqYJWifB8e7mgsqu0MquIRbR3n0StALqLvje3UimwoNc0r27YyqXGHt3JSGi6O7dOSZRY/euFESUnaZDU3/u7AsV6kP1W5lz/RYjLnQ8fh9g6uTSs7poHrd5v9bVdlmUWbvW8ymaBng8Qd21b98Xb+w8FPW+uZskm09F3Rza/7zRcrxikWerx+j4Gfsm61LdRet3BisW/aO9pzo0uwMZ9ZmYGd1EEnobWttTWNvm98Vhu8g37afV7QLvqk0+nyUqihKrkfTHqe1YO2wC57qeS/3cpRhzkOYi5qBlwBwczhxkTDaH+O9mDX3uBFuDhZZWEK2BaQsynleFZPTaCdAWrOdSP28SYQvyMpHBBPg3FmkKimoK5u9nCno+MIBrq4m2MIi5NGNQ88ogxpHDaTgyCM+1fvYMwhycu4w5pIFQKJHmYKnB3J32Ydqk3YvpyJgyiElOOmRyhsneF7HQvohMySQJHkkGoEDFRAqk5BEwrp8dVOEoajSUKY8iAe0qKEmkwCkmBWNFcaCYFJGkJGaSBFKgyfmfS44UpOPKX35sCPypi3/7vMPA3/R7d9MwTC5mwuT5EcBbId659IYUJqfFKhRjQmWttbMBV0EuSBm2XEV8YcH+zhHsz99EsGKcIXf2g5T09MpXwfqvh+oKdQrMD8Wmyeu5Yxh32qyNWTuQrWSabPXn3et9RUnKMH+NoNVFmYMM7PKA0Qa9cb8YbO5NFF/7oPl79wNppP5kRqWcI5UTC+kH7zKPlXgiH+GRz020zOrza99O2ujbD05D0rIf66Z+47ipf/HdVF/q1YeeufdwVWPZwK7KcyXPVWnBFm96Yen+kyPd376ZdD3b3ZAwA9sj1vEyDC3JspXummEEzXZcUWmFlrSima0GRavYor0WBYQte1CQgc39fuMBNlkNFXtao7MiaWhZkTacxEWaSyUuWgUSF0tMXCzdRNQ1smEk5dBmEjj0czHTTBxbttekNCBcG9ieT2Fp2/eKbn+hgDu11AEFnE4JxfmgQe97KM7HYUkGzpyh4tyQiz6pr4lj8ORrLA6DrvcMsd4zUMeQEVzJXvNGwvk2KMdAqdcfzsAB0UAB0aAbA6lpo1F4dyntd+UtTTzvLY1FekvNDlfSBqKV4WTtl0vajQgsoaMl7YactMvkmtfxgg86i/dcyQw+jivda0U2b4YWLctAeu8UMwAlVNE6c80ryI1CoFgDLUV9f8NMgyTUYmRSrlivhcCMXJN5aUkDCzqh+WIL+WIbYzNG6vGr5TyHc7kD0vEKjuOi1bSUxZJPWVx6TVlQKYsJiGamTVq/l5kQyp/B8z7fRfmTBgxB4sofq7kGcM3qZvXfoo+jbOA4ylle+LeGXdmejAGobO2p1FsW62D/bSKOaISWSpdMWsspzV+TQ3gPmH/VHIkzF+AM2QAy6UpEPjRlExK13aYJUQ4i8ZyOQpo8WeYE29NtUxIjis6ITTyzACBGkmCXgOcszPuEe0ziS8YMdbJp4LRVYJ87coJCLd2opW/LFJCBGz/P7r3Zz4aksCEZzkl4nrWH+BDBgwNPFe9lS1HYUhzP5MIbTchndpymENttgVN1yfcYACSD8WNJEv0MgTMUPhydDyXxj0y5MdmhYtRBrYOOFMATyXFLGrGt4aXN0YexnFp/9SdalgHQkDBosDwanO+hBC9RpyDZ1Fm57x6EWyzzTTP/tBim7k9iArQbQvvABAHM0OiUBGgVolMRwASNTk2AjkFo73Abg4e2KQ3a4qH122N+crJZ6IN2BGgHUu2FThhmgdoNS1gGh4JOWQYX+xU5FQwwCItiYQm0mj7tShXDLeAWU3McDg7acBwOtLaWAQZhOYbzwrGccNwiDjrl+C5gBUQcM5wsSlVFLBiEIqEJBmYTGjTBwk6Tn2KMkxUxwcaMIGITjOw0FQKJTYlpKRGbE9SQ0AknXiKxU06Yx2ELgk1qS8QWjHAsMX5JCMmAFjhoxQjOQMYqhGaASQjMMMKmxInKMqCR6+kYQRRcz4QBBq4nJV3UpPWUMSMmI6EFAxonKikZURRJtWLEfiS0ZgRoSMGkYYBBCiY59ZnAMe3OT76ysgnNM3jBNxNV8B8EHo9gganSs6d+q+rQjWTqbGB2xvTsKfgriBlMnKaA/OSnxJBAfvZTcjzhQ++sCZmgz7PEYIAPUrDuPQV7fqi6b6oyX3zONpvBQmjS6PB11uTDVQyI8/zmh037u3msq895vWgOdZ03AyzxhqUwhBzKKcSJHI2A2GR7Hx0yoF3nIN7RNj6mLAJsuhnsQ3IIpF2xyxdNtVjX7d33XhiBGhWf77KiXuyy1Z+AL9AoavJ6VZTrRU/NfrHN1tn/ivJMk+IBpqFa5OToExzrLQbzq5AWaT/OIgOtAV6xYTQbah7zAUo64OsuPNd4/c0uPjSMdt3nq261QlAYax43KnEN+bwvkGvE2Wp12B42IEcJAmNfbbLOfst848VIMebbO+z956J5ndM41smY+K0TPGe037aha9EGkZ0fg6TJL01FvjiIUTpfg5IPy9CTC8BxKcY4mePgguTC/cTTeZ7yo8d5+hdThZoXhVLIydqDEX/7w7Jlq2cFbLbqLALdG2Mn+SS+fW1y7zQWKuz0cCW5GpZ+cw37NqPE1XQE6/zjAgSFU3MBbmZLo1e9cJbyAvrecuh0rdrusron8zb6kS2HDmj35a53qXcPdbU9NvVGt63bzUlCkuivBlKeEWzz/gP8JobB8EnEJLvXHFNIZJLJ6OjHeUDwWxyU+Quz4d74E6TJnkpircUOqtw6K9aPbdqbFRufhz52+fVTrUP7MoNReyHYlwmTONjTrkBRt/lDv4yzy6aAPanBTL0ggRpP4GB0XRBWEmAFHpYgpcG0rhCsJUhpMCkqCGsJsGcbnEXZVVO7GUzriayboxM4fi/buve6y/7vrDvh0mkSq1QK0/4S2j53/q7PXm8H3zN3E22yZVsU3Ea/tgn1Jv/hl5f8/Idf8k32pX3/qS1ij6edWktjkzROkufn/wP1fCsq

Instructions & notes for the blueprint, please read before using:

Readme

1: Build via personal construction bots in an open area away from other logistic networks.
2: Connect it to a power grid & manually load 1 logi bot into each roboport.
3: Put some stacks of wanted items into the iron chest pretending to be a train wagon. [Include some logi & cons bots too.]
4: Sit back and watch.

+ You can change the stock item types &/or levels by adjusting the constant combinators at the hub.
+ The hub has an extra x2 combinator at the train bridge, so it will stock double the regular amount of items, to act as a buffer when the supply train is elsewhere.
+ The letter signals are min/max numbers for the logi & cons bots per roboport, used by the combinator control block in each section. Setting min equal or higher than max results in amusing derpy behaviour.

[Qon]

So many players say "Bots make the game so easy, they remove the design and logistics challenge from the game".
Then they build an aweful zero effort bot base and blame the bot AI for their own mistakes when it doesn't work.
If the bots fail, don't blame the bots. Blame your design.

I mean the bots are dumb AF. There is a lot that could be done to improve their behaviour

I think they work fine. Their weakness is long distance high volume transport, but that's why you have trains. They are dumb enough to force you, the designer of your base, to think before you use them for high volume tasks though. I don't think that's a downside really.

The actual problem: They struggle with repairing railways when they have to fly over large hostile areas, which I don't know how to deal with really except building one enclosed megasquare containing your whole rail network and keeping natives out. That isn't a graceful and quick solution either. Maybe trains with roboport equipment will one day solve that problem.

But you really really REALLY should not have large logistic networks. For optimum logistic performance, the logistics area should not exceed 4-6 roboport spans of coverage in any direction. Exceeding that makes the bots take a long time to arrive and encourages charging port congestion when half the bots in the system deliver to the same place and then must queue up at the nearest roboport to recharge.

No, wrong. If your base is designed correctly with bot behaviour in mind, then any size is possible. Separating your logistics networks is just one way to solve the problem of rising complexity when you have more connected production areas.

For optimum logistic performance, you need to understand the workings, strengths and weaknesses of bots. No magical rules, just knowledge. If you are fine with non-optimal performance then many tiny networks is probably a good enough solution in many cases.

Not all problem with bots stem from the size of their network.

I would say that it's never the size of the network that causes the problems. The problems come from not taking everything within the network into account when building the large network. Separating the networks does not solve your problems because the networks are smaller. It solves your problems because when you can't build a single network properly, using bots less helps you because bots and big networks are hard to use and belts and trains are "easy". When you separate your networks you force yourself to use other simpler methods than bots for logistics.

It's not big sizes, it's that everything within a single logistics networks have the potential to affect everything else in the network and bots will take long paths if the short paths within cells can't be taken because you starved machines of input/blocked output/misbalanced the production cells.

The decision making when faced with multiple sources and/or multiple targets for a tasks (construction or transport, regardless) is as crude as it can be and will amost always cause a worst case in my experience. The only solution is to have some form of scheduling that includes but is not limited to distance calculations. No amount of segmenting your network can adress that.

Are you talking about scheduling as a solution in game that the player implements, or some update that you believe the developers need to add to the game for bot AI?

Plus, they improved the charging behaviour but given enough bots they still will clog up the queue of a select few roborts out of the many you have clustered where they are charging. In my experience at least...

If the bots aren't given enough roboports to charge in spiky high traffic areas then they will clog up. You probably don't have enough roboports in your big network. 4 charging ports per roboport means you need more than 1 every 50 tiles if you are going to use bots for bulk logistics.

[Bauer]

Qon wrote:
No, wrong. If your base is designed correctly with bot behaviour in mind, then any size is possible. Separating your logistics networks is just one way to solve the problem of rising complexity when you have more connected production areas.

For optimum logistic performance, you need to understand the workings, strengths and weaknesses of bots. No magical rules, just knowledge. If you are fine with non-optimal performance then many tiny networks is probably a good enough solution in many cases.

When delivering stuff to storage chests, bots can be really stupid. All bots fly to one box, they realize that the box is full only when arriving. Then they decide what box is the second best option to delivery to. So all bot continue flying to another (random) chest that could be very far away. That can mess up the complete system. What is your solution for this? How can you design in order to avoid this mess?

This is why I use only small networks, e.g. close to a train station for train loading/unload, storage, sorting and transfer to/from belts. Otherwise, if your train delivers 20 k iron plates and the bots decide that the chest 1000 tiles away is the one, just to realize that it's full only when they arrive to fly to the next one that will also be full when they arrive. It's really aweful to abserve this crazy ballet when there are 20 empty boxes next door to the station. Plus the fact that the iron plates most like will also be used close the station. So the flying caravan all comes back.

PS: I like the bot how they are. You need to think and they are not long distance. Because I also like trains...
PPS: I'm just curious how Qon solves this problem intelligently.