Logistic Network Needs to be smarter

[Escadin]

@Qon

You know, if you do have greater insight in how to avoid issues with bot AI then share them and don't just blame people for not having any. There is nothing I could take away from your post despite it's length. Looks like I do need to go into detail after all.

The problems I have are:

• Logistic bots don't check whether tasks are still active. Often I find them carry out a delivery to a requester chest or similar and then only find out on arrival their task has been canceled. At least, when flying greater distances they should stay informed. No idea how you supposedly solve this. I know the devs easily could.
• No distance checks for task handling. For example, if you have storage chests at the edges of your factory, and occasionally you dump some wood in them then bots will often ignore the wood right at their roboport and go on a 2minute trip to get some from the edge of their network. Inb4 "Just don't have wood at the edge" - No. That wouldn't cover the functionality I desire. Looking forward to your solution.
• Construction bots always start constructing blue prints from the far edge. But why? This could be handled a lot better, for example, starting at the close edge at least would make your personal robots more responsive when you're moving while they construct.
• Construction bots are extremely hesitant - if not outright unable - to construct entities from passive provider chests even though they technically have access to them.
• Bots don't distribute items evenly. There is no equivialnt of a "splitter". For example, when filling trains with requester chests bots will just dump all items in the first chest until it's full and only then move on to the next. The only solutions I can think of are either a) Don't load from requester chests or b) massively overdo the amount of bots so they can fill the first chest in a second. Why shouldn't the LN be able to handle such a simple task?
• Recharging bots don't equally fill the queue of available ports if there aren't enough to charge all bots at once. Even if there are enough ports in one place, bots sometimes ignore some of them and rather queue up than taking the free slots.
• There are no distance checks for repair tasks. Thus, it's impossible to hook your network to your fence repair network (for example to occasionally carry oil barrels there, or replace repair kits which are both very low throughput jobs perfect for LN). Well it is possible but then the next time your wall takes damage the construction bots right at the fence are only issued the task by chance. Often, it will be a construction bot from the far edge of your base which means your wall will be destroyed until it arrives. That's just plain stupid behaviour.
• Construction bots try to replace mines right in the middle of the ongoing alien attack wave. What's even worse, standing there they will take damage from groundfire and trigger even more repair bots to join the suicide party. However, mines are best used infront your defenses so the only solution is not to use them at all or manually replace them (but who wants that in a game like Factorio?).

This list is not complete.

[Qon]

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?

The only way that box would be full if if you fill it with an inserter while the bots are flying towards it, exacerbated if your materials have to be routed long distances. The logistics system alone will never do this since a requester chest basically counts items on their way by bot as if they are already in the chest.

I do 2 things to avoid this problem.

• I avoid filling requester/storage chests with inserters and emptying providers/storage with inserters. Either use logistics bots or inserters for the task. Avoid doing both for the same task if possible. Mixing belts and bots work fine if you use inserters to remove from requester chests and insert to provider chests. Storage chests should basically never have inserters connected to them in any way.
• I make sure that bulk transfer of items only need to move short distances, as always with bots. If bots spend less time in the air moving things then the timeframe for their task being invalidated is shortened problems are less likely.

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.

Sounds like a storage chest problem combined with inserters to/from storage chests. I generally try to limit the amount of material I buffer, because buffers usually just hide bottlenecks and don't improve production.
I'm not completely sure how bots deal with storage chests at different far away locations. Without further testing I can only say that a buffer outpost would work in it's own separate logistics network.

The way that storage chests are filled (roughly):
If there are chests with that item already with some empty space, pick the closest one.
Else if there are empty chests, pick the closest one.
Else if there are chests with empty space, pick the closest one.
Else, panic and cry for player attention!

This means that empty chests that are closer have lower priority than chests that already have some of the same item and are closer. There might be a distance where empty chests are prioritized higher than chests with the same item, I don't know. But if not, that could cause issues for you.

But they will never fly to a chest and realize it's full when they arrive unless you stuffed it with inserters while they were flying towards it.

So again, don't use inserters with storage chests. Avoid buffers for the most part. Train stations need some buffers, maybe have those buffers on their own network if the requester/provider chests directly connected to the train are not enough. A single chest have more storage than a wagon though, so you can stor 16.8 trains (48 * 14 / 40) in a train station buffer without any storage chests. You probably don't need those storage chests.

Qon
You know, if you do have greater insight in how to avoid issues with bot AI then share them and don't just blame people for not having any. There is nothing I could take away from your post despite it's length. Looks like I do need to go into detail after all.

It wasn't meant as a tutorial, I can't just brain dump everything I know without an extraordinary amount of time, effort and the correct place for such a thing. Yes, you do need to go into detail with your problems if you want detailed answers.

The problems I have are:

• Logistic bots don't check whether tasks are still active. Often I find them carry out a delivery to a requester chest or similar and then only find out on arrival their task has been canceled. At least, when flying greater distances they should stay informed. No idea how you supposedly solve this. I know the devs easily could.

Answered above.

• No distance checks for task handling. For example, if you have storage chests at the edges of your factory, and occasionally you dump some wood in them then bots will often ignore the wood right at their roboport and go on a 2minute trip to get some from the edge of their network. Inb4 "Just don't have wood at the edge" - No. That wouldn't cover the functionality I desire. Looking forward to your solution.
• Construction bots are extremely hesitant - if not outright unable - to construct entities from passive provider chests even though they technically have access to them.

They prefer the closest items. But different chest types have different priorities that can override the distance checks.
I believe the robots prefer to take items from active providers first, then storage chests, then passive providers. They send items to requester chests first, then storage chests. They might also prefer taking items out of chests like they fill them. So reverse order of filling, taking items from full chests last. Not sure since I don't use storage chests that much.

If you want wood at the edges of your network, use passive providers. You have very little control over storage chests since bots are free to do what they want with them. I place all my storage chests in a single location in each logistics network if I do use them. Or don't have wood at the edge of your logistics network. I said the size of the network is not the problem. That doesn't mean you can do whatever though. The design of the network (what is in it) is important. If you place a stray wood chest in the middle of nowhere and then bots will use it even if you wish they didn't.

> Inb4 "Just don't have wood at the edge" - No. That wouldn't cover the functionality I desire.

Well maybe they can't do everything you want them to do. I wished I could use rockets for transporting items, so I asked for someone to mod that it. The base game doesn't have to be changed for that.

• Bots don't distribute items evenly. There is no equivialnt of a "splitter". For example, when filling trains with requester chests bots will just dump all items in the first chest until it's full and only then move on to the next. The only solutions I can think of are either a) Don't load from requester chests or b) massively overdo the amount of bots so they can fill the first chest in a second. Why shouldn't the LN be able to handle such a simple task?

They do distribute "evenly", but not by equalizing the chests. Full details require more words...

Sounds like you are requesting full single material chests.

Solution: Simply request less items in the requester chests. You only need 3 stacks (40 / 14) of the chest to be full to fill a train i you have 14 input requester chests. Once one task is complete the bots can only go on with the next one. So less items requested will force the bots to distribute equally to all chests quickly. This way all requester chest will have 3 stacks at about the time you would otherwise have filled 1 chest. The bots have time to fill up the chests with new material before the next train arrives if the distances are short. Full requester chests only give you more buffers. If 14 chests with 3 stacks each isn't enough then your problem is low throughput somewhere else.

• Construction bots always start constructing blue prints from the far edge.
• There are no distance checks for repair tasks.
• Construction bots try to replace mines right in the middle of the ongoing alien attack wave.

More intelligence from the construction bots is a completely different topic. I can only say that I don't mind con bots being smarter and better. "No distance checks" sounds like a false statement. You probably didn't have repair packs available at the correct locations or similar. There's a mod that makes con bots immune to fire.

• Recharging bots don't equally fill the queue of available ports if there aren't enough to charge all bots at once. Even if there are enough ports in one place, bots sometimes ignore some of them and rather queue up than taking the free slots.

[/list]

There's a distance to queue length formula for roboport charging prio somewhere on the wiki. If you have enough roboports densly enough and you don't overload the bots then you will not have problems. Their capacity isn't unlimited though. Take this into account when designing your production cells. Place more roboports and minimise the distance robots have to travel. Make sure there's balance within the network so that the short paths aren't clogged/starved so that bots have to travel to other production areas to steal resources. This is a big topic though since it means you might potentially have to take into account everything within the network.

[Escadin]

More intelligence from the construction bots is a completely different topic. I can only say that I don't mind con bots being smarter and better. "No distance checks" sounds like a false statement. You probably didn't have repair packs available at the correct locations or similar. There's a mod that makes con bots immune to fire.

As you can see, distance doesn't really matter to them. I gave both roboports the same amount of bots and repair kits:

Picture

20170607150440_1.jpg (589.53 KiB) Viewed 7522 times

And no, this isn't a completely different topic. Construction bots are part of this thread

Regarding your other suggestions:
What it boils down to, if I understand correctly, is a lot of the stuff I complain about cannot or should not be done and then my network works fine, right? I mean... okay. If you think this isn't necessary then that is fine.

I for one would like a more systematic approach which provides the player with more control over bot behaviour and handles a lot of the functionality robots provide better. The goal of this discussion is exactly that we don't have to "avoid the badly executed functionality".
The game allows you use inserters in conjuction with LN => There should be a way to make it work and work well.
The game allows you to span a huge network (again, some mechanics even encourage it like personal requester slots) => There should be a way to make it work and work well.

I also don't see why very large / time consuming tasks can't be completed concurrently. If I have 8000 logistic bots then loading 5 chests simultaneously shouldn't be an issue even if it's not place and forget. "Avoid issueing huge tasks" is not an adequate solution here. The system allows me to make huge task so it also should offer the necessary tools to make it work.

Another problem not mentioned in the above list is the inconsistency when seperate networks overlap, for example your base network and your personal mobile network. Placing a blueprint in your factory where both networks are present causes completely inconsistent behaviour in regards which bots take what item from player or base and use it to complete what task.
I'd love to see a checkbox by the personal requester slots which toggles whether bots prefer your inventory or the items available in the LN when constructing.


As it stands now, there is a lot the robots could can technically can do. However, the execution is often crude to the point where avoiding either robots or part of their functionality is the best solution. This shouldn't be the case.
There are already quite a few suggestions on how to accomplish that in this thread.

[Bauer]

Logistic example.gif (294.29 KiB) Viewed 7512 times

I think you are mistaken (or my 0.15 is broken).

All bots fly to one chest, after xx arrivals the chest is full and all bots fly to the next chest. And it is by no means the closest one.

[Nich]

You shouldn't be using activie providers at the train station. You are simply wasting bots time. They have to move it from the active provider into storage. Then later when it is actually needed they have to move it again. In addition you are building up an unnecessary buffer. It doesn't matter if trains unload slowly because boxes are not ballanced as long as you have another train in the cue to take its place you only need enough buffer to get the trains swapped.

[Manron]

The way that storage chests are filled (roughly):
If there are chests with that item already with some empty space, pick the closest one.
Else if there are empty chests, pick the closest one.
Else if there are chests with empty space, pick the closest one.
Else, panic and cry for player attention!

you almost got it right.

Storage chests are filled:

1) storage chest that already has the same item
2) empty storage chest that was build first (yes, it is build order, not distance or anything!)
3) not-empty storage chest that does not have the item already.

in contrast, storage chests are emptied based on distance to the requester (chest, ghost or player)

as a conclusion: build storage chests manually in circles around the provider, from the inside out. do not use construction bots to build a storage. it will btw even out after the storage was completely filled, as the requester will pull from the closest storage, and delivery will then go to those chests if everything else is filled.

[Killcreek2]

You shouldn't be using activie providers at the train station. You are simply wasting bots time. They have to move it from the active provider into storage. Then later when it is actually needed they have to move it again. In addition you are building up an unnecessary buffer. It doesn't matter if trains unload slowly because boxes are not ballanced as long as you have another train in the cue to take its place you only need enough buffer to get the trains swapped.

I disagree: Active providers at unloading stations allow all train wagons to empty evenly.
If you only use passive chests, then the bots empty them one at a time, often closest wagon first. If demand increases later, they cannot keep up, as they do not have the full chest bandwidth available [as the item levels are uneven and many may be empty].

As long as you set a limit on the inserters pulling from the train into the local buffer, they do not over- or under-work and all wagons are unloaded evenly at all times. You only need a couple of storage chests present, to act as a buffer when the trains swap in/out. During normal high-throughput operations, items are taken directly from the active providers to the requester chests, the buffer storage is only used rarely [& should be located halfway between anyway].

It works beautifully well, if you set it up right. Wish I could make a vid... pics don't really do it justice: http://i.imgur.com/JfBqgY3.png
[That pictured depot is outputting to 14 almost-compressed red belts [at max draw], from only 3 total train wagons].


I kinda have to agree with Qon: Logistic networks are only as smart as the effort the player puts in to designing them ...

[Ace_W]

I would like a way to assign, or otherwise designate, a bot area via the roboports.


Like area 1, area 2, ect.. And have a way to automatically assign a group of bots to it.
At work so I don't have any PhotoShop. But id want the areas to overlap too. And be nameable.

That would allow something like the train unload to be assigned a group. The smelters to overlap and be assigned a different group. And have a mall group. Bus group. Sciencegroup. Wall group.


Would probably solve a bunch of problems.

[Qon]

More intelligence from the construction bots is a completely different topic. I can only say that I don't mind con bots being smarter and better. "No distance checks" sounds like a false statement. You probably didn't have repair packs available at the correct locations or similar. There's a mod that makes con bots immune to fire.

As you can see, distance doesn't really matter to them. I gave both roboports the same amount of bots and repair kits:

Picture

20170607150440_1.jpg

And no, this isn't a completely different topic. Construction bots are part of this thread

I meant different topic, not necessarily different forum thread. My opinion is different for different kinds of bots. For construction bots unlimited intelligence is fine, and I don't really have an opposing opinion that can contribute to the discussion. Fine by me, whatever, would be nice. I'm not saying that it's not a part of the thread.

For logistics bots, way too many don't understand them at all and then complain when they don't do as they want even though they do exactly what the player told them to. The rules are not easily accessible, that is one problem. Another is that logistics bots are a chaotic system that is hard to comprehend without a lot of experience and effort. And the fact that their capacity is so massive contributes to making horrible designs seem correct enough that you don't really get to know what works unless you push it's limts.

Well the walls are within the contruction area of the roboport that released the bots. And just because the closest bots possible were not the ones to be sent doesn't mean that "distance doesn't really matter". In this case the distance was negligable enough to not matter.

Regarding your other suggestions:
What it boils down to, if I understand correctly, is a lot of the stuff I complain about cannot or should not be done and then my network works fine, right? I mean... okay. If you think this isn't necessary then that is fine.

I for one would like a more systematic approach which provides the player with more control over bot behaviour and handles a lot of the functionality robots provide better.

In some cases yes. If you use a storage chest where a passive provider should be used or use inserters with storage chests and find problems that I could forsee because I understand how they work, then yes you should use the tools correctly instead of blaming the tools.

However, I don't use storage chests much at all because they give you such a small amount of control. If the AI doesn't properly prioritise distance then they basically can't really be used in multiple locations in your base. If so, then that is one weakness that I could agree would need improvement. Another thing that would be nice is a "requesting storage chest" that acts like a storage chest for requester chests and active/passive provider chests. But it has a higher storage priority for the requested items than normal storage chests, so bots prefer using the requesting storage chests over normal storage chests. This means that you have storage chests where the player decides what the bots should/can store in them.

The goal of this discussion is exactly that we don't have to "avoid the badly executed functionality".

Some things considered by "badly executed functionality" by a novice might actually be a case of incorrect tool use. But you might also be right. Depends on the specifics of what functianality we are discussing. Things I tell you to avoid aren't necessarily bad functionality, but bad tool usage.

The game allows you use inserters in conjuction with LN => There should be a way to make it work and work well.
The game allows you to span a huge network (again, some mechanics even encourage it like personal requester slots) => There should be a way to make it work and work well.

Well it's possible to make it work well. There are ways to make it dysfunctional. It's up to you to do the right thing.

Just having everything in the same logistics network is not always correct. By having everything in the same network you tell the bots that they are allowed to do whatever they want. If you don't like that they have that freedom, don't give it to them and split your network responsibly. Splitting networks is one of the tools given to you by the game that can be overused and underused.

By calculating the throughput of the items sent into the logistics network and items inserted into requester chests with inserters you can balance the two so that requester chest isn't completely filled by the inserter before the bots arrive. If you want an example of one way to solve it.

I also don't see why very large / time consuming tasks can't be completed concurrently. If I have 8000 logistic bots then loading 5 chests simultaneously shouldn't be an issue even if it's not place and forget. "Avoid issueing huge tasks" is not an adequate solution here. The system allows me to make huge task so it also should offer the necessary tools to make it work.

I think you are talking about your requester chests at your train stations again. Maybe the tools to succeed are actually available?
If the amount of items in the network are not enough to satisfy all requests then bots will be sent out evenly (within a margin of error provided by complications such as bot carrying capacity etc) to requester chest. If possible, close by bots will be given the tasks and they will prefer source chests closer to target chests.

If the amount of bots available is not enough then that might cause your issues. I usually have enough bots in my network for my needs so I'm just speculating. Maybe they are evenly prioritising all chests, it's just that the jobs connected to some chests don't have any free bots to complete the tasks. It could be that you don't have enough bots for your very large task. The necessary tool might be to bring more bots to the network. I can't really tell just from vague descriptions though.

5 full requester chests is 24k items if it's plates. If you have fully upgraded bots then 8k might be enough. But do you have 160 roboports (8k / 50, a guidline for how many roboports to bots to use) at your train station? Probably not since you can't fit that many that close to your train station. Overloaded roboports causes congestions that just further increase the problem. The bots and roboports don't have unlimited capacity. Just because you can issue huge tasks don't mean the logistics network can easily just handle it. Maybe the tools you are requesting are just straight up buffs to the robots and not actually more fine control? Less roboports can work though for spiky tasks if there's enough time to recover so I can't say for sure.

Another problem not mentioned in the above list is the inconsistency when seperate networks overlap, for example your base network and your personal mobile network. Placing a blueprint in your factory where both networks are present causes completely inconsistent behaviour in regards which bots take what item from player or base and use it to complete what task.
I'd love to see a checkbox by the personal requester slots which toggles whether bots prefer your inventory or the items available in the LN when constructing.

They prefer your items if they can do it by themselves immediatly (with the number of bots available in your inventory and controlled by your personal roboports) and if it's within your personal contruction area. Anything beyond that is filled in by the local roboport ground network. Seems fairly consistent to me.

As it stands now, there is a lot the robots could can technically can do. However, the execution is often crude to the point where avoiding either robots or part of their functionality is the best solution. This shouldn't be the case.
There are already quite a few suggestions on how to accomplish that in this thread.

I don't really agree. Avoiding to use a tool incorrectly isn't really "avoiding functionality". Avoiding storage chests is really the only part where I can agree that it is a fitting description.

[Qon]

you almost got it right.

Storage chests are filled:

1) storage chest that already has the same item
2) empty storage chest that was build first (yes, it is build order, not distance or anything!)
3) not-empty storage chest that does not have the item already.

in contrast, storage chests are emptied based on distance to the requester (chest, ghost or player)

as a conclusion: build storage chests manually in circles around the provider, from the inside out. do not use construction bots to build a storage. it will btw even out after the storage was completely filled, as the requester will pull from the closest storage, and delivery will then go to those chests if everything else is filled.

Wow, build order strikes again! Good to know. That just makes storage chests even more useless for me, since I only build with blueprints at the scale I'm building factories atm.

[Escadin]

2) empty storage chest that was build first (yes, it is build order, not distance or anything!)

So once you built a storage chest you can never touch it again or you'll ruin your priority queue. Ingenius!

Well the walls are within the contruction area of the roboport that released the bots. And just because the closest bots possible were not the ones to be sent doesn't mean that "distance doesn't really matter". In this case the distance was negligable enough to not matter.

It was an example setup to prove that this is not a "wrong statement". I have seen bots fly ALL across the base (easily 20 roboports) to repair because the local bots who had repair packs couldn't be bothered. There is just no argueing around this fact.

Also:

If the amount of items in the network are not enough to satisfy all requests then bots will be sent out evenly (within a margin of error provided by complications such as bot carrying capacity etc) to requester chest. If possible, close by bots will be given the tasks and they will prefer source chests closer to target chests.

If the amount of bots available is not enough then that might cause your issues. I usually have enough bots in my network for my needs so I'm just speculating. Maybe they are evenly prioritising all chests, it's just that the jobs connected to some chests don't have any free bots to complete the tasks. It could be that you don't have enough bots for your very large task. The necessary tool might be to bring more bots to the network. I can't really tell just from vague descriptions though.

5 full requester chests is 24k items if it's plates. If you have fully upgraded bots then 8k might be enough. But do you have 160 roboports (8k / 50, a guidline for how many roboports to bots to use) at your train station? Probably not since you can't fit that many that close to your train station. Overloaded roboports causes congestions that just further increase the problem. The bots and roboports don't have unlimited capacity. Just because you can issue huge tasks don't mean the logistics network can easily just handle it. Maybe the tools you are requesting are just straight up buffs to the robots and not actually more fine control? Less roboports can work though for spiky tasks if there's enough time to recover so I can't say for sure.

No they don't run jobs in parallel either. I can prove you wrong again here. What I assume you see is that if a task can be completed in one pass because you have more than enough robots for the task then obviously it's no longer up for distribution the second those leave their port and other bots are free to start their own tasks.
That is not what I'm talking about as it is clearly sequential task handling. I am talking about jobs that need more than one pass of your available bots. There you can see the difference and if I understand your suggestion here correctly it is once again to not let these tasks happen or bring more and more bots.

The problem is, this is ridiculously ineffecient. It's like saying, if your belts can't transport your items in a single rotation - add more belt lines until they can. Nevermind their inability to pipeline resources efficiently. It's also very counterproductive regarding optimization. A perfect example of "the tool is broken rather than used wrong"- Really, not everything is a skill question and even if you can find in-game work arounds for bugs or bad design doesn't mean it should stay that way forever.

Of course, improving the AI and handling of robots would eventually mean buffing them. However, this doesn't mean they are to be robbed of any complexity or difficulty. I think my suggestions have been pretty clear on the point that I want a more systematic and consistent interaction between bots and player. Not a "bots do everything so I don't have to think" one.

Although, I understand you feel entitled to your position as it took a lot of learning and playhours to figure out how to work with the wonky AI and behaviours. Do you really want that to stand in the way of progress? I mean "I figured out how to work around half this stuff and the other half just shouldn't be done" is not really an arguement against changing the system. I'm sorry if that summary doesn't actually match your POV. Perhaps I misunderstood you.

One reason why it needs to be changed is because the exact mechanics regarding prioritization and task scheduling are never explained and they are very unintuitive as well. That's probably just because they never intended the player to bother with it. I think there is a pretty good chance they thought the combination of different chest types is enough control and all the player has to learn while the rest will be handled by the AI well enough. They never intended you to go through all this trouble. The system likely just doesn't live up to expectations.

The other reasons are the myriad of optimization and efficiency issues that have come up in our discussion, like for example the lack of distance checks or reliance on massively oversized bot swarms or artificially small networks to hide the poor task scheduling.
When it comes to that, I would rather have to program my own scheduler in curcuits than give up on the potential functionality or network size.

-----

Ideally, I would personally wish for a system where the player has to set up working areas and traversal routes (like a hovering ropeway with roboports as poles). Network flow is constant and dictated by bot count but still has to be fine tuned to your factories demand and potential spikes. There should be methods to seperate networks occupying the same area and especially traversal routes should stay static and avoid mixing.

Task scheduling should get a massive overhaul to avoid all those worst cases it constantly produces right now. Additionally, the (for new players) confusing chest system should be replaced with an interface that let's you set up delivery and other purpose routes between chests.
Further mechanisms could be added as well like priority beacons (with circuit network connection). Also, bots / wokring areas should be aware of enemy presence and offer an override to whether they engage those areas while enemies are present or not.

Imo, that would provide the player with a lot more tools to create something interesting with the network, potentially reduce the required bot count per factory and make handling and design much more intuitive.

Yes, it would potentially turn them into an all around superior version of belts for late game. However, given that they require high science packs and the fact that this happens all throughout the game without negative consequences, I don't really see the problem here.
For example, I usually still use steel furnaces all game long even though electric furnaces are technically better for a variety of reasons. Yet, I've never seen anybody complain about that. Personally, I would continue to use belts not only to reach the tech level required for robots in the first place but also because I love balancers and oceans of ore flowing across the planet's surface.

[BLuehasia]

I also want the ability to have more than one network within a network

so the robo ports going along the train tracks dont link up with the outpost bases and my main base. so the robo ports on the train tracks can keep the tracks maintained from biter attacks

[Manron]

2) empty storage chest that was build first (yes, it is build order, not distance or anything!)

So once you built a storage chest you can never touch it again or you'll ruin your priority queue. Ingenius!

you can always put a fish in those you dont want to be used to make then become non-empty, or you can prime your storage chests with a single desired item.

[Qon]

Well the walls are within the contruction area of the roboport that released the bots. And just because the closest bots possible were not the ones to be sent doesn't mean that "distance doesn't really matter". In this case the distance was negligable enough to not matter.

It was an example setup to prove that this is not a "wrong statement". I have seen bots fly ALL across the base (easily 20 roboports) to repair because the local bots who had repair packs couldn't be bothered. There is just no argueing around this fact.

In my experience bots that are close by repair damaged structures. I don't know why your experience differs. Was a while since I built ordinary bases. Maybe I'm wrong.

Also:

If the amount of items in the network are not enough to satisfy all requests then bots will be sent out evenly (within a margin of error provided by complications such as bot carrying capacity etc) to requester chest. If possible, close by bots will be given the tasks and they will prefer source chests closer to target chests.

If the amount of bots available is not enough then that might cause your issues. I usually have enough bots in my network for my needs so I'm just speculating. Maybe they are evenly prioritising all chests, it's just that the jobs connected to some chests don't have any free bots to complete the tasks. It could be that you don't have enough bots for your very large task. The necessary tool might be to bring more bots to the network. I can't really tell just from vague descriptions though.

5 full requester chests is 24k items if it's plates. If you have fully upgraded bots then 8k might be enough. But do you have 160 roboports (8k / 50, a guidline for how many roboports to bots to use) at your train station? Probably not since you can't fit that many that close to your train station. Overloaded roboports causes congestions that just further increase the problem. The bots and roboports don't have unlimited capacity. Just because you can issue huge tasks don't mean the logistics network can easily just handle it. Maybe the tools you are requesting are just straight up buffs to the robots and not actually more fine control? Less roboports can work though for spiky tasks if there's enough time to recover so I can't say for sure.

No they don't run jobs in parallel either. I can prove you wrong again here. What I assume you see is that if a task can be completed in one pass because you have more than enough robots for the task then obviously it's no longer up for distribution the second those leave their port and other bots are free to start their own tasks.
That is not what I'm talking about as it is clearly sequential task handling. I am talking about jobs that need more than one pass of your available bots. There you can see the difference and if I understand your suggestion here correctly it is once again to not let these tasks happen or bring more and more bots.

Well you said 8k bots, so it's a single pass, right? I'm a bit confused now.

The problem is, this is ridiculously ineffecient. It's like saying, if your belts can't transport your items in a single rotation - add more belt lines until they can. Nevermind their inability to pipeline resources efficiently. It's also very counterproductive regarding optimization. A perfect example of "the tool is broken rather than used wrong"- Really, not everything is a skill question and even if you can find in-game work arounds for bugs or bad design doesn't mean it should stay that way forever.

I'm a bit qonfused about the exact specifications about the sitiuation we are discussing. Is it about your train station still? Can't really answer without knowing more about your train station and base.

Of course, improving the AI and handling of robots would eventually mean buffing them. However, this doesn't mean they are to be robbed of any complexity or difficulty. I think my suggestions have been pretty clear on the point that I want a more systematic and consistent interaction between bots and player. Not a "bots do everything so I don't have to think" one.

Yes you say you want more control, but I'm not qonvinced that the situations you have trouble with are due to lack of control. They seem solvable to me with the current amount of control to me. So before you can give realistic suggestion on what additions to the amount of fine control you have over bots you have to learn what is already available in the game.

Although, I understand you feel entitled to your position as it took a lot of learning and playhours to figure out how to work with the wonky AI and behaviours. Do you really want that to stand in the way of progress? I mean "I figured out how to work around half this stuff and the other half just shouldn't be done" is not really an arguement against changing the system. I'm sorry if that summary doesn't actually match your POV. Perhaps I misunderstood you.

Maybe you did misunderstand me. Do I want to stand in the way of progress? If progress means people who don't understand the current system changes it to something that magically solves their (already solvable) logistics problems then yes. But that doesn't sound like progress to me. That is just buffing robots until they are so overpowered that there are no downsides or considerations at all. I agree that there are room for improvements. But we can't really discuss it in detail if you insist on doing something wrong while calling you design right and the system wrong. Especially if we are on on a high level discussion about using general vague "tools" instead of specific designs illustrated with pictures, numbers, blueprints and saves.

One reason why it needs to be changed is because the exact mechanics regarding prioritization and task scheduling are never explained and they are very unintuitive as well. That's probably just because they never intended the player to bother with it. I think there is a pretty good chance they thought the combination of different chest types is enough control and all the player has to learn while the rest will be handled by the AI well enough. They never intended you to go through all this trouble. The system likely just doesn't live up to expectations.

Well I agree that more explanaions would be good. The game is still not complete and they recently made a tutorial system. A logistics robot tutorial is most likely already planned. And the AI handles it well enough in most cases if you don't try to push it too hard.

Moving buffers is one thing that easily pushes any logistics system to it's limits though.

The other reasons are the myriad of optimization and efficiency issues that have come up in our discussion, like for example the lack of distance checks or reliance on massively oversized bot swarms or arteficially small networks to hide the poor task scheduling.

The task scheduler is "simple", not "poor". Making it "advanced" can be an improvement for the game, depending on how one changes it.

Ideally, I would personally wish for a system where the player has to set up working areas and traversal routes (like a hovering ropeway with roboports as poles). Network flow is constant and dictated by bot count but still has to be fine tuned to your factories demand and potential spikes. There should be methods to seperate networks occupying the same area and especially traversal routes should stay static and avoid mixing.

Task scheduling should get a massive overhaul to avoid all those worst cases it constantly produces right now. Additionally, the (for new players) confusing chest system should be replaced with an interface that let's you set up delivery and other purpose routes between chests.
Further mechanisms could be added as well like priority beacons (with circuit network connection). Also, bots / wokring areas should be aware of enemy presence and offer an override to whether they engage those areas while enemies are present or not.

The ability to disconnect roboports close to eachother, a bit like electric poles, might be nice. Not sure how it would help me or you with any specific problem though.

Working areas and traversal routes? I can't really comment without details. Sounds like something that gives you more control. While giving the player more control is nice up to a point, I think it still should be mostly automatic. Something to be managed through design instead of explicitly assigning specific bots to specific routes. That's what you have trains and belts for. Though trains lack some automation aspects and force you to micromanage them a bit too much. Would be nice if trains could be set up to act more like logistics robots.

It sounds like you want change logistics bots towards small flying trains by introducing the downsides of trains to bots. Too much explicit control. Not enough high level control. Trains and stations can't be blueprinted. Every single train has to be manually set up to go to the right stations. Every train station needs to be named individually. Train lines are rigid and don't account for what's available where and what is necessary where. They can't rereoute to fuel depots automatically when low on fuel. Add an iron outpost and you have to manually change the scheduling of maybe several trains to include the new outpost. It's a lot of things that can't be automated and add up when you get a big train network.

If you do it wrong the you are just making it more tedious. But these suggestions don't sound like like improvements to the AI like you were talking about before. It sounds more like removing the AI and giving the player the task to schedule all the bots by himself. Then I would rather have an AI that is a bit too smart.

Yes, it would potentially turn them into an all around superior version of belts for late game.

They are already superior.

[Escadin]

Of course, improving the AI and handling of robots would eventually mean buffing them. However, this doesn't mean they are to be robbed of any complexity or difficulty. I think my suggestions have been pretty clear on the point that I want a more systematic and consistent interaction between bots and player. Not a "bots do everything so I don't have to think" one.

Yes you say you want more control, but I'm not qonvinced that the situations you have trouble with are due to lack of control. They seem solvable to me with the current amount of control to me. So before you can give realistic suggestion on what additions to the amount of fine control you have over bots you have to learn what is already available in the game.

Although, I understand you feel entitled to your position as it took a lot of learning and playhours to figure out how to work with the wonky AI and behaviours. Do you really want that to stand in the way of progress? I mean "I figured out how to work around half this stuff and the other half just shouldn't be done" is not really an arguement against changing the system. I'm sorry if that summary doesn't actually match your POV. Perhaps I misunderstood you.

Maybe you did misunderstand me. Do I want to stand in the way of progress? If progress means people who don't understand the current system changes it to something that magically solves their (already solvable) logistics problems then yes. But that doesn't sound like progress to me. That is just buffing robots until they are so overpowered that there are no downsides or considerations at all. I agree that there are room for improvements. But we can't really discuss it in detail if you insist on doing something wrong while calling you design right and the system wrong. Especially if we are on on a high level discussion about using general vague "tools" instead of specific designs illustrated with pictures, numbers, blueprints and saves.

One reason why it needs to be changed is because the exact mechanics regarding prioritization and task scheduling are never explained and they are very unintuitive as well. That's probably just because they never intended the player to bother with it. I think there is a pretty good chance they thought the combination of different chest types is enough control and all the player has to learn while the rest will be handled by the AI well enough. They never intended you to go through all this trouble. The system likely just doesn't live up to expectations.

Well I agree that more explanaions would be good. The game is still not complete and they recently made a tutorial system. A logistics robot tutorial is most likely already planned. And the AI handles it well enough in most cases if you don't try to push it too hard.

Moving buffers is one thing that easily pushes any logistics system to it's limits though.

Look, we have already gone through a number of very specific situations where
1) The player has no control over what happens
2) You didn't even know/believe it happens and robots behave that way (So much for people who don't understand the current system)
3) AI most definitely doesn't handle it well enough

And even when there is control, it's often some obscure magic thing like putting a fish in a chest to magically prevent it from being prioritized based on the order in which you built it (Just imagine them putting that in a tutorial, lol). Or dumping so many bots in the network the problematic mechanics don't even come into play. Or marking something I and perhaps some other people would like to do as bad practice, like for example having multiple storage areas in one network. That's not to say the system leaves you without any control tbh.

I don't have a specific factory design that gives me trouble. My trouble is with the current concept of how logistic and construction bots function itself. It's too basic and too prone to worst case behaviour for my taste.

[Qon]

Look, we have already gone through a number of very specific situations where
1) The player has no control over what happens
2) You didn't even know/believe it happens and robots behave that way (So much for people who don't understand the current system)
3) AI most definitely doesn't handle it well enough

I don't know what you are referring to in your list. If this is about construction bots then I've already said that it is a different topic for me. If it's logistics bots then I still can't agree if I don't know what you are talking about.

And even when there is control, it's often some obscure magic thing like putting a fish in a chest to magically prevent it from being prioritized based on the order in which you built it (Just imagine them putting that in a tutorial, lol). Or dumping so many bots in the network the problematic mechanics don't even come into play. Or marking something I and perhaps some other people would like to do as bad practice, like for example having multiple storage areas in one network. That's not to say the system leaves you without any control tbh.

I disagree. I didn't say anthing about build order, fish or dumping bots in the network to hide "problematic mechanics". Obscure magic that actually doesn't work, not my style.

[British_Petroleum]

I think it's fun trying to get the robots to avoid doing silly things. Most important things i think is knowing the chest priorities, and knowing that the bots will favour storing an item in a storage chest that already has that type of item stored there, as already mentioned. Say if you want barrels stored in a particular storage chest, you can make a setup that makes sure there's always at least 1 barrel in that chest, so logistics bots will always store barrels there, rather than a random storage chest on the other side of the factory

[ratchetfreak]

The problem with priming chests is that eventually the chest will be emptied of the item you primed it with, after that it's back in the build order priority queue

I don't want to have to babysit the storage chests to keep optimal distribution

[Bauer]

You shouldn't be using activie providers at the train station. You are simply wasting bots time. They have to move it from the active provider into storage. Then later when it is actually needed they have to move it again. In addition you are building up an unnecessary buffer. It doesn't matter if trains unload slowly because boxes are not ballanced as long as you have another train in the cue to take its place you only need enough buffer to get the trains swapped.

I unload various goods into the same active provides chests. The unloading of the train stopps when a certain amount in present in the logistic network + the stuff that is in the provider chests. Hence, I need to the trains to unload quickly, because the next trains needs to come with goods that might be needed more urgently. Therefor, the chest need to get emptied quickly, which is why I'm using active provider chests. I also need some buffer because the train travelling time is fluctuating due to jams, construction works, safe player crossings, design failures leading to grid locks *sigh*, etc.

Since the loading/unloading station is a seperate network, there are no long distances and bot time is no big issue. It would my life much easier if the bots would bring the stuff to the closest storage chest and not to the oldest (empty) one.

In fact my biggest problem is that I very carefully have to handle my automatic trash. Because I do not want it to end up in the storage chests at the train stations...

[Nich]

You shouldn't be using activie providers at the train station. You are simply wasting bots time. They have to move it from the active provider into storage. Then later when it is actually needed they have to move it again. In addition you are building up an unnecessary buffer. It doesn't matter if trains unload slowly because boxes are not ballanced as long as you have another train in the cue to take its place you only need enough buffer to get the trains swapped.

I unload various goods into the same active provides chests. The unloading of the train stopps when a certain amount in present in the logistic network + the stuff that is in the provider chests. Hence, I need to the trains to unload quickly, because the next trains needs to come with goods that might be needed more urgently. Therefor, the chest need to get emptied quickly, which is why I'm using active provider chests. I also need some buffer because the train travelling time is fluctuating due to jams, construction works, safe player crossings, design failures leading to grid locks *sigh*, etc.

Since the loading/unloading station is a seperate network, there are no long distances and bot time is no big issue. It would my life much easier if the bots would bring the stuff to the closest storage chest and not to the oldest (empty) one.

In fact my biggest problem is that I very carefully have to handle my automatic trash. Because I do not want it to end up in the storage chests at the train stations...

If you are using the station for one resource steady state for the furthest boxes would be empty (not enough raw recourse bandwidth) or full (too much raw resource bandwidth. Assuming worst case scenario of unloading alignment, assuming you have the bandwidth to support production and assuming it takes 4 seconds to swap trains you would have enough buffer to support 13,500 items/second/station which I believe is above the theoretical maximum of trains anyways. I had not considered multiple types of trains coming in. In that case you are probably correct with active providers. However have you considered storing your resources at their destination rather then a storage chest? So for example each green circuit machine should request 4500 iron and each copper wire machine should request 4500 copper? Yes it will take a while to reach SS but you can very easily see how many machines your bandwidth can support. Eventually your station will clog with one resource being delivered too often unless deliveries are controlled by a circuit network.

Edit oh I see you release the train based off a circuit condition

Edit 2: how many stack inserters does it take to fill a blue belt 4 or 6? I use yellow for everything