[Rseding91] [0.16.12] Still having requester problems

[Planks]

In this save, Low density parts are not being flown from buffer chests to requester chests

I've re-made both sets of requesters and buffers

Clipboard01.png (1.23 MiB) Viewed 7850 times

[fortycakes]

I'm having the same issue on 0.16.11 and 0.16.12, green circuits and copper wire are working fine, but not plastic...

[Zavian]

@Fortycakes: It might be easier for the devs to debug if you upload the save.

[fortycakes]

It just randomly started working after I unticked and ticked 'request from buffer chests', then all the chests started working. Must have fixed something stuck in the logistics network.

Unfortunately my save is over 100MB and I'm on a 4G, limited network at the moment.

[mewtwoEX]

I've noticed this problem on some old requester chests in 16.10. Haven't yet played enough to see if it crops up still. For me it seemed to be migrated chests only, but I'm not at a point in my new playthrough to have bots to test with.

[Planks]

I did some science

In my save file, deconstructing the roboports applicable to the requester chests, and then rebuilding them, sometimes allows requests to resume.

BUT deconstructing the chests (like in the OP) and rebuilding them in the same place does nothing

After a while, they just stopped working again.

[Rseding91]

Thanks for the report. It's now fixed for the next version of 0.16.

[azegg]

Looks like its still broken, I can confirm its working (for me) in .12, but .13 breaks it. I have about 59k of Solid Fuel in passive provider chests, and my 48 Rocket fuel assemblers that each request 67 Solid Fuel are not getting anything. I have over 10k available bots just sitting idle. I have tried the checkbox for buffer chests, removing/adding the requested items, and even delete and replace the requester chest, none of which fixed the issue. the only mod I'm using is Auto Deconstruct.

[Tlmitf]

I am now having this issue.
It seems that the requester chest waits until it is empty before it requests - and even then it doesn't request enough. I am only getting dribbles of copper coils and iron gear wheels moving around.
**EDIT**
This is not quite true. I have provided factories alternate component sources while leaving the requester chests intact, and the chests did eventually reach the requested number, just very slowly.

Version 0.16.13

[Rseding91]

Looks like its still broken, I can confirm its working (for me) in .12, but .13 breaks it. I have about 59k of Solid Fuel in passive provider chests, and my 48 Rocket fuel assemblers that each request 67 Solid Fuel are not getting anything. I have over 10k available bots just sitting idle. I have tried the checkbox for buffer chests, removing/adding the requested items, and even delete and replace the requester chest, none of which fixed the issue. the only mod I'm using is Auto Deconstruct.

Please make a new report with the save and mods showing the issue.

[Koub]

Duplicate of viewtopic.php?f=30&t=56135 I guess ?

[golfmiketango]

I suspect I have encountered an unfixed bug brought about by the introduction of buffer chests... it has to do with the "request from buffer chests" check-box. Check out the attached save (mod hacks should be down to just the one hacked up blueprint flipper mod which I've attached; remaining mods are standard from-the-portal mods which the automagic "sync mods with save" feature should cover fine).

In the save you'll see I'm standing next to a terrible hack which builds green science from robot logistics. Note, in particular, the requestor feeding the iron-gear-wheel assembler just to my right. If you open up the UI for that requester chest, and hover the mouse over the request slot for iron plates, you'll see that

• There is a general shortage of iron plates in my network
• The checkbox for "request from buffer chests" is checked

Note that no items are scheduled for delivery and that, even if you wait for a very long time, no iron plates are ever delivered to this chest. Yet, there are requestors nearby getting delivery just fine. Now, returning to the requester chest UI, go in and turn off "request from buffer chests", and hover the mouse over the iron-plates request slot again. You will see that immediately items are scheduled for delivery. I would bet just about anything that if you cheat in a provider chest with a million iron plates in it, all of a sudden, iron plates would start being delivered as well -- in my experience if I change either bullet point above, deliveries resume.

What I believe is happening is that somehow requester chests with "request from buffer chests" checked are effectively given a lower fulfillment priority when scheduling logistics deliveries of scarce items in busy networks, either because they are in a different queue which starves for deliveries in a shortage, or, if there is just one queue/list, then due to some glitch in the code which normally slides the fulfillment window in a loop over the list of requesters (which would normally ensure that in, a shortage, everybody gets a little bit), causing starvation of some (but maybe not all) requesters configured to request from buffer chests. It might be a build-order thing; these chests are among the last to have been built in this network.

[Edit: oops, just realized this is a "resolved" bug. Would some mod be so kind as to move my post to a new thread as if it were a fresh bug report? tia]

[Rseding91]

Buffer chests do have a lower priority than requester chests - by design.

[golfmiketango]

It's not a buffer chest. It's a blue requester chest.

Unless ... my assumption is wrong? I am assuming that checking the box on a requester chest to accept delivery from buffer chests does not mean it will only accept delivery from buffer chests, but in addition to any other providers.

If that were incorrect, it would explain everything I'm seeing, but it would be (in my somewhat wierd mind, at least ) such a tragedy that I'm not even thinking about that as a serious possiblity...?

[Edit: hm, well maybe not so completely tragic, since, I suppose, I would just have to daisy chain a buffer-chest requestor to a non-buffer-chest requestor to make a 3-tile black-box apparatus that works approximately how I think the requestor "obviously should" work with the box ticked; but I lose control of precisely how many items are buffered there unless I fill several more tiles with combinators and add yet another inserter and an active provider to the mix].

[Jürgen Erhard]

Buffer chests do have a lower priority than requester chests - by design.

Let me get this straight (and, if you guys ever write a manual for this game, put it in): if both a buffer chest and a requester chest request an item, and there are fewer of that available than both request in total, the buffer chest always loses? That makes buffer chests one bit less useful.

[golfmiketango]

Buffer chests do have a lower priority than requester chests - by design.

Let me get this straight (and, if you guys ever write a manual for this game, put it in): if both a buffer chest and a requester chest request an item, and there are fewer of that available than both request in total, the buffer chest always loses? That makes buffer chests one bit less useful.

You "have it straight." (I realize I'm not Rseding91 but I'm very, very sure). Although it might make them less useful for certain things, it makes them more useful, if you are using them as buffers, rather than as general-purpose logistics containers. Because, why would you want your bots to deliver stuff to your buffers, and then immediately turn around and deliver the same stuff from your buffers to your requesters, or your character, if your requesters/character are already empty and bots could just deliver things directly where they're going?

If you want a magical gizmo with the same priority as a requester chest when requesting, but that otherwise works almost (not 100% but damn close) like a buffer chest, and you could part with 10 tiles of space, you could always do something clever like this, (putting your request into the constant combinator):

HighPriorityBufferChest.png (534.87 KiB) Viewed 7136 times

[/url]

Blueprint String

0eNrNVk2vmzAQ/CuRjxVUgbx8oaqH9tJj71WEDCywemBTY6KmEf+9a9MkvAQSUulJvSQxtmdnZ3aXHFlUNFApFJoFR4axFDULfhxZjZnghXmmDxWwgKGGkjlM8NKsCplhrTF24xxq7UZNmoJircNQJPCLBV7rPIuh4GdD329g/AkwXKHOS7BAsoxQcC37GIt25zAQGjVCl5tdHELRlBFFC7wHUA6rZE23pTAcCNH1Pi4ddjA/KEyCCuJu13cYCaiVLMIIcr5Huk1XLrAhbScWqjYbKapahzf57VHphp6ceXUnXOBxbhKrwcAYrFpzY5xLgWUFinc02Ae6KhtdNU+Dt61NQXQZWZKe+cgUgOiLhwkLlu2OjvtmX0EytNsa/67k9p+Ve/6/qe29t9oDar7c1XptanzQo8WIC4szo1Nidz3wLw4MaZ5iQY07aXLEsiLt3KrgGpiFa4yo221vduym6zKeuSkPVHGDulv2RDDr1YgwLw9m3O006LSZT+d8xcwbYbK8FI3m8auLogalByl4ZwqP++MU+twc/9AbXBx0jiLrDDw1xtwsyoorW0MB+2y3/4ZTwJMw510naUqVJNKqgcsJu2mPlTIB+w6Zqqh33+vxIvGurbi5OGjN6vFL7HaM9ctk1BWTeijTsDdgvGdm8li/r8+MU048x2tpsJRW71dKsAc1pZg+sSem5fLKxwezYDFaH/YlRuOdSCokZ2wnUnK/4W2xnGTejBUGJ9J7cCsl94QzOmHnraFiJ2bQ+2vmsIJHQHKyb5jls++KDKCwsy92Js2+mhB0iFjWnV+btT/fepulv23bP8vba98=

[Edit: Throughput of the above is constrained by the inserter but that could be fixed by manually setting the request in the BufferChest (unfortunately we can't set requests and output contents from buffer chests simultaneously). Also, I am not sure why I used the stack size of one and blue inserter. I think a stack inserter with full stack size should be fine there. Finally, I should have documented one more detail: it's important that the requester chest above is not configured to request from buffer chests, otherwise bots will just keep moving items between the requester and buffer chests and the stack inserter will keep moving them back forever!