ColonelSandersLite wrote: ↑Sat Oct 01, 2022 9:32 pm
Moosfet wrote: ↑Sat Oct 01, 2022 1:33 pm
Satisfaction: 0/100
On-the-way: 0
Logistic Storage: 1000
I'm inclined to think that this is a mod issue as I haven't experienced behaviors like that before.
It's actually not a bug and happens with the vanilla game. The 1000 items in logistic storage are in buffer chests, and so the bots aren't willing to deliver them because they're reserved for construction or player requests.
I really don't understand how buffer chests are supposed to be useful. Now and then I try to use them to keep materials closer to where they'll be needed, and then an hour later I run into this problem and 15 minutes after that, when I figure out that this isn't a bug, I remember why I never use buffer chests. (I have kind of bad memory so after I don't play for a year, I forget that this happens and have to figure it out all over again.)
I can only guess that the devs play differently, perhaps by using space-limited provider chests such that there will always be items in provider chests, but I like to connect inserters that put items into provider chests to the logistic network so that they don't pick up items that the network doesn't need. So, for example, I might decide I need 1000 laser turrets at most, so configure the inserter that picks them up to not pick them up if the network already has 1000 for some reason, like, say I blueprint something with a bunch of turrents, so they all come out of the provider chest, and then decide I don't want it, so I control-Z it. Those turrets go into storage, but even though the provider chest is now empty, no more get made, since there's 1000 in storage. ...but then I have some far-away defense walls and decide to put buffer chests near them so that turrets can get replaced faster, and then an hour later I find that some recipes aren't getting made because machines need laser turrets as an input item, but the requester chest isn't getting any, because there's already 1000 of them in buffer chests and so that inserter isn't picking up any more of them. I suppose this problem would go away if I just used a space-limited provider chest and let it make too many laser turrents in these rare situations (since usually it'll use the storage first, so the provider won't empty until the storage is empty), but, IDK, it's just how I've always done it. It does work better if I copy & paste to make more machines that produce something. Say I only want 50 so I make one slot open in that provider chest, but then I copy and paste it 9 times. Now I'm making 500, whereas if I had used the network condition on the inserter instead of relying on space-limiting the provider chests, I'd still only make up to 50 of them.
I suppose buffer chests might also work for me if I just checked the "request from buffer chests" checkbox on every requester chest I place, but I'm not about to start doing that. It would create a lot of senseless back-and-forth movement of items, as the bots primarily deliver them to the far-away buffer chests and then bring them back to the requester chests, and I'd forget to check the box sometimes, and so it's easier to just never use buffer chests. Indeed, I'm not sure why that option is even there. It seems like someone encountered my problem here, tried to solve it with that checkbox, and then kind of just abandoned the whole idea of buffer chests and left them in this not-really-useful state when that didn't work.
I really wish the logistic network didn't count the inventory of buffer chests. Indeed, I think that instead of reporting this number:
Code: Select all
N = (quantity in storage, provider, and buffer chests) - (quantity to be picked up by a bot)
It should just report this:
Code: Select all
N = (quantity in storage or provider chests) - (outstanding requests in requester or buffer chests)
I'm usually more interested in how many items the network wants than how many it has. When I'm looking at how many it has, usually I'm just using that as a proxy for how many it wants. Like, I'll try to keep an inventory of 1000 iron plates, so if there's only 900, then something wanted 100, so I need to make 100. However, it would be cool if I could just look at the network value and see that it's -100 and thus conclude that I need to make 100 more iron plates.
Anyway, do that, then drop the requester chest, rename the existing buffer chest to "requester chest," and we'll just have requester chests which, much like how the passive provider chest also serves as a storage chest, and the storage chest also serves as a provider chest, the requester chest can also serve as a storage chest, and a provider chest, depending on if the items are being requested by a player or construction bots. Then the problem of needing items on-hand in remote places will be solved without adding a 5th chest type that creates more problems than it solves. You just go wherever you want the items, place a requester chest, and then they'll be there if you need them or construction bots need them, and they'll also be available from any other requester chest that has some in it because they're sitting their unused in case an inserter decides to load them into a machine someday.