Friday Facts #203 - Logistic buffer chest

[golfmiketango]

So, basically you've split requester chests into "requester chest lvl 1" and "requester chest lvl 2" so that "lvl 2" can pull items from "lvl 1" chests.
Can we also get chest levels 3,4,5... ?

Yeah, I was thinking the same. Actually, even without buffer chests, some means of grouping provider and requester chests into categories and setting robotic rules forbidding fulfillment of requests flowing across certain edges in the graph of category nodes would allow for similar constructs and maybe other clever stuff.

Buffer chests could still be useful in that model, however, simply for their ability to simultaneously request and provide an item (although ... if there were such a thing as filter-able storage chests, I wonder if that would that be the same, better, or worse than buffer chests? If robots knew about the filters and made routing decisions accordingly, I suspect it might be almost, but not quite as useful).

[Alice3173]

after having slept over the initial excitement I do have a small request could we get presets for the Buffer chests?
There would be 3 choices: default 1, 2 and 3 + individual requests.
We set the desired amounts then save as default 1, in the future any buffer chest placed down would start with the default 1 setting (for example yellow and red Belt stuff, electrical poles and some raw Resources) then you could add individual items (the oil area would have refineries + Chemical plants , buffers near the main bus would have additional belts etc).

Somewhat related but a toggleable option to make requester chests examine the squares around them for inserters and check the recipes of any buildings those inserters are inserting into from the requester chest, even if it just defaults to an amount of 0, would be quite helpful. It's really annoying when half your time spent setting up an assembly line is spent hunting down the individual ingredients required for the current recipe. It's even more annoying when you're playing mods with recipes that have 6+ ingredients and have to keep exiting out of the chest to recheck the recipe. At the very least being able to set an option to default those items into the requester chest then have to choose the amount would speed things up greatly.

[IronCartographer]

It's really annoying when half your time spent setting up an assembly line is spent hunting down the individual ingredients required for the current recipe.

Shift-right click (copy) an assembler, then shift-left click (paste) to a requester chest. Your request is already in the game, though you demonstrate its need for improved discoverability.

Maybe requester chests should have a Recipe Selection UI which could serve the same purpose, but that would be a bit redundant... I wonder what would be a better solution.

[Alice3173]

Shift-right click (copy) an assembler, then shift-left click (paste) to a requester chest. Your request is already in the game, though you demonstrate its need for improved discoverability.

Maybe requester chests should have a Recipe Selection UI which could serve the same purpose, but that would be a bit redundant... I wonder what would be a better solution.

Oh, you can do that? Took me a long time to even learn you could do that between assemblers/chests to copy recipes and requester setups between them but it never crossed my mind to even attempt them between types of buildings. (Only learned by watching an lp of the game.)

[ske]

Can we "buffer" those flying robots, too? (I mean balancing and distributing of idle robots.)

Sometimes all robots fly off to one end of the map for construction or item movement. This is ok. But after they are finished they sit at the other end of the map and don't come back before needed. Not even some of them. Not even after an hour of doing nothing. Repairs have to wait a very long time because the worker robot has to fly all the way back. This would be solved if some of the idle robots were distributed between the roboports, so that each there is at least some of them.

[Maslofski]

will we get these chests in 0.15 or do we have to wait for 0.16? they seem like an fairly simple thing to implement, from the player side atleast

[Tricorius]

Imagine you are manufacturing ammo somewhere in the middle of your base and putting it in a passive provider and it's distributing from there to requestors all round the perimiter. You notice there is a big latency to this process on one side of your base so you put a buffer over there to cut the latency. If buffers always take priority over providers then the opposite side of your base will now start pulling from the buffer instead of the closer provider which is probably not what you want.

I think the idea here is that you would have an ammo buffer anywhere close to where you need it. And the passive providers probably evenly supply the buffers. So the solution here is to add another ammo buffer on the side nearer the passive provider. Then the bots will prefer (hopefully the nearest) buffer.

Taken a step further, you can set up north, west, south, and east buffers that supply ammo, repair packs, walls, gates and turrets and hopefully the bots can quickly service their wall segments with all needed supplies even if all the individual passive providers are scattered across the base.

[tolomea]

If buffers always take priority over providers then the opposite side of your base will now start pulling from the buffer instead of the closer provider which is probably not what you want.

I think the idea here is that you would have an ammo buffer anywhere close to where you need it.

Yes. My point is that you can't install them as an incremental upgrade, when you put in the first such buffer you will break things if you don't put in the others at the same time. So it's not anywhere you need them but rather everywhere.

You can most easily work around that by putting a buffer right next to the provider. Indeed it's easy to imagine that being best practice to avoid any such issues. But then if you are always putting buffers next to your providers to work around priority issues, why not just change the priority on the providers.

[Patashu]

A buffer will have a maximum capacity that it requests, so once all buffer chest requirements are fully satisfied then everything else will go back to normal. If you're using ammo faster than you're making it, then you have bigger problems to worry about

[MageKing17]

Loving the buffer chest idea; this is exactly what I subconsciously felt was missing from the logistic network, but wasn't able to articulate.

[Tallinu]

Buffer chests will be an awesome addition... But I'd still love it if any of the things I mentioned in a previous post here could be considered. Of the few who replied, opinions seemed to be divided on whether or not performance would be noticeably affected, but I think that's up to the devs to decide whether each item could be implemented efficiently along with whatever other optimizations you intend to make to robots, and a few of the simpler behavior changes like the recharge priority or pre-positioning don't seem like they would necessarily require much more processing, just different processing. (The only objection to those seemed to consist solely of "You just want X", and while that's absolutely true -- if I didn't want X, I wouldn't have asked for X! -- it's also not any sort of actual reason to not implement the feature. )

Also, for the bot "out of energy" prediction one, checking every tick whether the bot has enough energy to continue moving toward a stationary target has to use more CPU time than testing once, at the outset, whether the bot has enough energy to reach that target, and then simply moving it without any further need to perform energy checks. You can even delay subtraction of the energy spent until it reaches the end of its current path or until something else unexpectedly interrupts it, causing it to stop and redirect. So that change could actually be seen as an optimization as well as an improvement in gameplay behavior. And even for a moving target, just determining and storing the fact that you have enough energy for X ticks of movement (before energy drops below the recharge threshold) at the current bot speed research level could still simplify matters.

[Boardy]

Can we "buffer" those flying robots, too? (I mean balancing and distributing of idle robots.)

Sometimes all robots fly off to one end of the map for construction or item movement. This is ok. But after they are finished they sit at the other end of the map and don't come back before needed. Not even some of them. Not even after an hour of doing nothing. Repairs have to wait a very long time because the worker robot has to fly all the way back. This would be solved if some of the idle robots were distributed between the roboports, so that each there is at least some of them.

How far do you want to go to make everything automatic? It will remove the game from the game and all you have to do is watch your computer play the game by itself.

If it really bothers you, you could create some circuit logic to take all/most construction robots out of the roboport after some idle time and put them in an active provider chest. Then have some requester chests in your central area where they will be reinserted into roboports. (Or if you want to keep it simple, just take out anything over 50 construction or logistic bots.)

[IronCartographer]

Can we "buffer" those flying robots, too? (I mean balancing and distributing of idle robots.)

Sometimes all robots fly off to one end of the map for construction or item movement. This is ok. But after they are finished they sit at the other end of the map and don't come back before needed. Not even some of them. Not even after an hour of doing nothing. Repairs have to wait a very long time because the worker robot has to fly all the way back. This would be solved if some of the idle robots were distributed between the roboports, so that each there is at least some of them.

There have been ideas to address this in the past.

Related but simpler: What if roboports had requester-style settings allowing them to attract idle robots? They wouldn't be tethered, but would return if not needed elsewhere. It would solve the other half of the equation for low-latency repairs and construction, or even train unloading if the logistics bots were distracted somehow (You just had to request 2k landfill and pull the logistic bots away from the train station, didn't you? ).

It would even allow upgrading of bot tiers (as Bobingabout wanted in the form of request-filter hybrids).

That said, a challenge would be keeping the robots available despite being in the process of relocating...

[ske]

How far do you want to go to make everything automatic? It will remove the game from the game and all you have to do is watch your computer play the game by itself.

If it really bothers you, you could create some circuit logic to take all/most construction robots out of the roboport after some idle time and put them in an active provider chest. Then have some requester chests in your central area where they will be reinserted into roboports. (Or if you want to keep it simple, just take out anything over 50 construction or logistic bots.)

It doesn't remove the game from the game. It just removes an unnecessary bottleneck.

I tried to make something similar but it didn't work well and didn't solve the problem. As far as I see there is no reliable solution to having a number of idle robots per roboport.

[ske]

Related but simpler: What if roboports had requester-style settings allowing them to attract idle robots? They wouldn't be tethered, but would return if not needed elsewhere. It would solve the other half of the equation for low-latency repairs and construction, or even train unloading if the logistics bots were distracted somehow (You just had to request 2k landfill and pull the logistic bots away from the train station, didn't you? ).

Yes, I'd be happy with just this in regards to robot redistribution.


One more thing that could be done is replanning robot routes. E.g. you have a chest of iron standing right next to you and request 1 gazillion iron. What happens is that close-by robots get called and far away robots also get called. The close-by robots transport iron from the chest to you and idle after that. The far-away robots take a aeon to arrive while the idle robots wait around doing nothing. In this case the system could transfer the task of the far-away robots to the close-by robots and save a lot of time and energy. I think this could be done with moderate additional CPU load while improving experience a lot.

[BenSeidel]

Hmm,
I see everyone asking "what is the difference between the buffer chest and the storage chest" whereas I want to know what is the difference between the buffer chest and the requester chest? What examples can anyone think of that you would use a requester chest over a buffer chest?

Every other chest has it's purpose:
Passive provider: output from assembly machines
Active provider: non-blocking output from assembly machines (empty barrels, etc).
Storage: A place to put those deconstructed items, empty barrels, etc.
Buffer: can be used as an input chest into assemblers as well as supply access for construction bots & player (as stated in the FFF)
Requester: Ummm... used as an input chest into assemblers, but with the drawback of not allowing access to the items in the chest by the player OR construction bots.

I can see that adding an additional priority level makes things simpler, but only for those that are experienced and know what each chest does. But by that stage you don't have to think about your setups anyway. Maybe it might just be worth changing the requester chest into the buffer chest and stay with the 4 chests we have now? 4 is easier to learn that 5 for new players.

Don't get me wrong, being able to have a dedicated storage area for the various items is cool, but will it cause more confusion for new players than it's worth?

[IronCartographer]

What examples can anyone think of that you would use a requester chest over a buffer chest?

I'm tempted to use buffer chests for all non-essential production so there's a natural prioritization of critical outputs that are still fed by requesters. However, now that I think about it, that would probably result in personal logistic requests being satisfied by random buffer chests rather than central storage... So there's your answer: Requesters allow you to avoid forced scattering of the sources for requested items, with buffers being the new destination for players seeking a fast resupply.

[ske]

Buffer chests could have a priority level assigned where they receive only from lower priority and only feed to higher priority. This would make most chest types quite obsolete.

For example
[*] Active Provider = Prio -1
[*] Passive Provider = Prio 0
[*] Player trash = Prio 0
[*] Storage = Prio 1
[*] Buffer = Prio 2
[*] Buffer = Prio 3
[*] Buffer = Prio 4...
[*] Receiver = Prio 999

In order to distinguish between storage and buffers you need a checkbox to enable arbitrary storage.

That being said, while it is a very clear concept, it might lead to a good user interface.

[RebelNode]

I think one chest-type logistics still misses is path-chest. As in when I want a simple replacement for a belt when it's impossible or difficult to build one between two locations. Kind of like a fully separate logistics "pipe" that still draws from the same pool of idle drones to do the transportation between my two chests.

[factoriouzr]

I'm glad this combo requester/passive provider is finally being implemented.

I have asked for this a long time ago and discussed it several times. Here is the most recent issue I created asking for this and suggesting this exact implementation the devs choose (viewtopic.php?f=6&t=44238).

It always seemed like the dev's were against this idea as they didn't reply to the issue (I know they are busy but this was desired by the community for so long and they reply to other issues) and there might have also been some push back on the idea (might not have been from the devs).

As such it's interesting to read the following in their Friday facts:

As flexible and powerful as it is, we have always felt there was one key missing to the puzzle. The main issue is that requester chests cannot provide their items to any other member of the logistics system. Trying to workaround this by putting an inserter to a passive provider, just leads to the robots moving the items in a loop. This is also a nuisance trying to supply construction robots with materials, as they can only collect them from storage or provider chests, and they are only typically located in the main base areas.

Regardless I'm very glad this feature is finally making it into the game (0.15 please).

Can you also please fix the following two issues as they are huge headaches and fixing them would greatly improve the game IMO:
viewtopic.php?f=6&t=45013&p=276644#p276651
viewtopic.php?f=6&t=35510&p=219987#p219987