Logical requests delayed

[Kahnugo]

I reposted the save because it's slightly outdated, but overall it is the same issue (I don't remember exactly what has changed that's relevant to this topic, possibly I've changed the system that determines requests for the water train stations (to prevent it from updating every tick) and maybe changed some passive providers.

When you looked at it, what exactly did you observe and how long. To spot it you might have to look at one of the critical chests for 10-20 seconds to observe it's behaviour, abnormalities shouldn't happen much because the use is fairly constant. The requester chest for water barrels at the upper left connection on the main factory is the one where I noticed it the most at that point I think, either that or some of the most active provider chests from the factory.

It shouldn't actually change the flow much when the trains come in as the buffer rarely dips below 50-60k of each ore, but the chests they take it from will change whenever a train comes it.

It can be a little tricky to spot the idle robots, because they tend to be clumped up in a few roboports out of 5-600. I've just now observed 3 full roboports (350 bots in each) to see if they ever emptied and in 5 mins I never saw a bot leave them (they could have since I wasn't watching 100% on each single one, but they were at 350 every time I looked at them). As I wrote this I tabbed in and I had my first significant spike while watching and 20 robots left one of them while it corrected itself.

The buffer chests are there in advance of turning up production to the point where the distance from the provider chests could prevent enough barrels to be removed from the chests, I'm not entirely sure when/if that would happen, but that's why I have the buffer chests. Btw at the time I think I based the requests entirely on the buffer chests (I could have switched to logistic storage in the save you looked at), so it would likely reduce the request of empty barrels by the barrel assembly machines. Depending on the exact scenario, you could have actually killed the factory :p and that would cause the reduction in activity.
Regardless, the buffer chests aren't supposed to get many deliveries if they're not needed to at the time (it probably suggests I might have changed to active providers in the save, as that required a change to logistic network supply contrary to the content of the buffer chests when deciding the requests of the requester chests) the central issue is the critical connector chests at the factory itself, are they getting serviced or not.

Edit: If there really is not remnants of the issue, I'd be interested in seeing what update times you get on the logistic manager, my pc is fairly mediocre and it might very well have an impact on when you start seeing this.

[Guenni7]

In the save you posted, the buffer chests are all wired and you have around 8K bots in the network.
I will have a closer look and be back in a few minutes...
Back

On my laptop the complete update is around 16.000, Logistic Manager mostly at 2.000 - 2.500, highest value seen 4.000.
The chests upper left are constantly being filled with barrels, but ran empty one time (for some milliseconds).
The empty barrels seem to work too with the active chests, they never reach even 200.

What seems to be the problem is the latency in your network. The requester can only ask for 480 barrels,
the logistic manager dispatches the bots and because you dont know from where in the network they come, they arrive too late.
One more requester could solve that, but if I see it right, all ingoing to the factory building is used.
I don't know satisfactory mod, does it have special requester? A requester which request double the amount would do it too, then there will be more bots "on the way" to serve.

[Kahnugo]

I think I didn't remove the wires for quite some time, but if you check the combinator making the blue signal I think it's connected to a roboport using the logistic supply count. Unless of cause I hadn't done that yet.

I am not 100% sure what you mean by latency in the system. The buffer chests with water barrels around the requester chests at the factory connection are there to prevent the issue of travel time for barrels (priority for source is active provider > buffer/storage > passive provider and closest to requester if equal priority). If you mean the travel time for the bots before they pick up the barrels from the source, that's something I've been having thinking about as a potential bottleneck in the system. I'm not really sure how to detect it properly or how the system handles it, I'm guessing it's the nearest idle bot, which is why I've more or less discounted it as the culprit here, because of the idle robots relatively close by that doesn't get called while it's stalling. Unless it happens to exclusively call idle bots that are waiting to charge (if they don't show up on the ui as either incoming delivery or pickup while still being registered towards the request limit) I have trouble seeing it as the main culprit.
I performed a small test on the subject in a spaced out network with a requester in one end and a provider in the other with coal in it. And it shows up as incoming delivery as soon as the robot is dispatched to pickup the coal for the requester. So I'm confident that the ui is fairly accurate when it comes to assigned robots.

The factorissimo mod doesn't have custom chests for the purpose, I could get larger modded chests to remove the immediate problem, but I'm a bit stubborn about wanting to see how far I get using only vanilla+factorissimo2 gameplay features. The reason I've insisted on single input chests is because I'm using direct transfer between nested factories for the water input so that I don't need to transport that many water barrels by robot internally (the receiver chest on the inside of the main factory also function as an input chest for the nested factory on the inside containing several power plants. That way I only ever need to transport water for a single power plant , 1200MW, on any single factory floor).
I've got 3 internal factories that each has two water input, each water input is connected to another factory in the same manner that contains nested nuclear plants, the plan was to end up having 4-5*6 1200 MW power plants supplied that way. (that is approximately 300k water per second).

I do appreciate you checking out the save, I don't have the opportunity myself to check how it reacts on other systems.

[Guenni7]

I am not 100% sure what you mean by latency in the system. The buffer chests with water barrels around the requester chests at the factory connection are there to prevent the issue of travel time for barrels (priority for source is active provider > buffer/storage > passive provider and closest to requester if equal priority). If you mean the travel time for the bots before they pick up the barrels from the source, that's something I've been having thinking about as a potential bottleneck in the system. I'm not really sure how to detect it properly or how the system handles it, I'm guessing it's the nearest idle bot, which is why I've more or less discounted it as the culprit here, because of the idle robots relatively close by that doesn't get called while it's stalling. Unless it happens to exclusively call idle bots that are waiting to charge (if they don't show up on the ui as either incoming delivery or pickup while still being registered towards the request limit) I have trouble seeing it as the main culprit.
I performed a small test on the subject in a spaced out network with a requester in one end and a provider in the other with coal in it. And it shows up as incoming delivery as soon as the robot is dispatched to pickup the coal for the requester. So I'm confident that the ui is fairly accurate when it comes to assigned robots.

What I mean by latency... ok I try to explain:
Imagine a huge horizontal bot network where a bot needs 10mins to fly from far left to far right.
Now you place a requester with request=1 copper left and a provider with copper on the right.
This will get you one bot traveling from (worst case) the left 10mins to the right, pickup and travel 10mins to the left to deliver.
This is an extreme example for latency, which is between 10 and 20mins.

I understand you want to use the buffer chests to avoid latency, but there're things to consider on your base. You don't only transport barrells, but also coper plates, iron plates and coal I think. And you do it with trains. So you expect that a bunch of bots is always near to the water barrell buffer chests to do an instant supply of the requester, but they are not. Because whenever a train rushes in with copper, iron or coal, they fly away and then they are no longer near where you want them. The copper, iron and coal trains binds a lot Bots (don't remember the train size, but do the math). Now imagine copper, iron and coal are coming in at the same time.... then you have less bots then needed to fullfill all request, let's say you have only half the bots needed. Then the game tries to give 50% of all requests to the requesters. In case of a copper plate requester that goes from 4800 to 2400 it might not be a problem, but the water requester falls down from 480 to 240... which leads to his dry out because you need more.

As for the active/idle count on bot network: I think Bots that are recharging (after delivery) but have no new job attached yet, they're shown as idle (no job) while they're not ready to take a job. So idle count doesn't show bots that are ready to work.
You wrote that in some roboports they're stocking, which roboports are they on your map?

[Kahnugo]

The roboports I was looking at were just East/SouthEast of the main factory building, I opened my current save just now and the area has around 2-3k bots in roboports. There is probably some difference between my current save and the one you've been looking at, I suspect my current save has a better surplus that doesn't choke on the occasional bursts of tasks. It might also have helped slightly that I changed around the circuit logic that dictates the empty barrel requests (it was updating on every tick I believe, unless there is some build in limiter on requester chests) to update requests twice a second instead (at some point I'll make it dedicated to update slightly slower).

I do think you're putting a bit too much emphasis on the ore deliveries, as it shouldn't really change the dynamics that much considering that the demand doesn't change when the trains come in. It is only that the ore gets closer to the requesters for a short while after the trains unload.

The buffer chests are necessary because they alleviate the latency to a significant degree because each bot that does those very short deliveries will be able to complete many deliveries from buffer to requester before they need recharging and from testing tasks will always pick the idle robot closest to the source, so because a lot of bots will either end their task at the buffer chests or being tasked with buffer to requester chest that means there will be a significant flow of bots going idle in that specific area, simply because it's a function of how many bots end their tasks in a certain area.
The rough tests I mentioned earlier seemed to show that robots get tasks based on being idle, I think that charging behavior works separate from this mechanic and the manager will indiscriminately pick idle robots no matter if they are charging or not and that once they are picked, they show up on incoming deliveries/incoming pickup ui (both simultaneously). This would mean that robots charging while assigned do not disappear from the ui, rather they might be delayed while still showing up as on their way, not as being idle.

[Guenni7]

I'm sorry, but as I don't understand the circuit logic you have implemented I am not able to be of further help.
Still think it is a design problem rather than a game engine problem, but I think a dev should answer to your problem when he/she finds the time.