1. What did you do? [Case A]
I linked a roboport with the green circuit to a substation, set it to "Read logistic network requests"
I setup a requester chest with request of 50 big electric poles
I place a single big electric pole in a passive provider chest
I place a single logistic bot in the roboport
Once the bot is on the fly for the passive provider chest, I read the value on the substation:
2. What happened? [Case A]
The count on the substation is "46"
1. What did you do? [Case B]
I do the exact same set but replacing the passive provider chest by a storage chest
Once the bot is on the fly for the storage chest, I read the value on the substation:
2. What happened? [Case B]
The count on the substation is "49"
3. What did you expect to happen instead?
I expect that the displayed value is the same in both [Case A] and [Case B]
I also expect that the value displayed is 49 since only one item is picked up by the bot
4. Does it happen always, once, or sometimes?
It happens consistently.
Also, "Active provider chest", "Buffer chest" and "requester chest" (with "Trash unrequested" option enabled) behave as "passive provider chest" in [Example A]
Note:
Thank you for your support and this amazing game
[2.0.11]Read logistic network request inconsistent count while bots pickup
Re: [2.0.11]Read logistic network request inconsistent count while bots pickup
Thanks for the report however this is how the logistics system handles requests to pick up and deliver items. Robots will over-reserve what they want to grab and when they arrive if they can't actually grab that many they will only grab what's available.
If you want to get ahold of me I'm almost always on Discord.
Re: [2.0.11]Read logistic network request inconsistent count while bots pickup
Thank for the explanation, it make sense.
However, why the storage chest does not behave like the others ? (like shown in Case B)
However, why the storage chest does not behave like the others ? (like shown in Case B)
-
- Burner Inserter
- Posts: 5
- Joined: Wed Oct 30, 2024 4:24 pm
- Contact:
Re: [2.0.11]Read logistic network request inconsistent count while bots pickup
I have also encountered this inconsistency while playing.
Storage chests will cause an exact number to be set in the read logistic network request signal while other chests will cause an overestimate until the bot arrives.
In my use case using a storage chest gets the behaviour I need where I can find out the exact amount of items missing from the logistic system that does not fluctuate depending on the bots having picked up an item or not.
If the storage chest behaviour could be extended to the other chests that would be preferable.
Storage chests will cause an exact number to be set in the read logistic network request signal while other chests will cause an overestimate until the bot arrives.
In my use case using a storage chest gets the behaviour I need where I can find out the exact amount of items missing from the logistic system that does not fluctuate depending on the bots having picked up an item or not.
If the storage chest behaviour could be extended to the other chests that would be preferable.
-
- Burner Inserter
- Posts: 5
- Joined: Wed Oct 30, 2024 4:24 pm
- Contact:
Re: [2.0.11]Read logistic network request inconsistent count while bots pickup
After further observation the behaviour is even more inconsistent than storage chests behaving differently than providers and buffers.
Sometimes the storage chest will cause the logistic network request signal to update by the exact contents and other times it will report the over-reserved value.
I have not been able to work out under what conditions the two behaviours appear, but it seems like it may be related to whether the job is allocated to a bot that is already on another job.
Sometimes the storage chest will cause the logistic network request signal to update by the exact contents and other times it will report the over-reserved value.
I have not been able to work out under what conditions the two behaviours appear, but it seems like it may be related to whether the job is allocated to a bot that is already on another job.