Concept: Rework of the Logistic Chests (Unified Logistic Chests)

[MeduSalem]

So after reading through various other threads on Logistic Chest suggestions I propose the following concept on how to vastly improve on the abilities of the Logistics network, while only having 3 chests (yeah I would get rid of one).

Basically my concept achieves following:

Logistic Chest Possibilities.png (15.64 KiB) Viewed 9222 times

So how to do that with only 3 chests?

1. Requester Chest
   
   I begin with the additions to the Requester Chests because they are the easiest to explain. Basically Requester Chests gain 2 checkboxes:
   

   

   Requester Chest.png (291.04 KiB) Viewed 9222 times

   How the checkboxes work:
   
   • "Input from Provider Chests": Determines if the Requester Chest can request from Provider Chests.
   • "Input from Storage Chests": Determines if the Requester Chest can request from Storage Chests.
   By default both are active, but at least one has to be active at each point or the chest wouldn't do anything.
   
   Naming of the Chests and example Color Coding (to match with the initial sketch):
   
   • Both ticked: Standard Requester Chest, Light Blue (The way currently Requester Chests work)
   • Only Provider Chest ticked: Passive Requester Chest, Dark Blue
   • Only Storage Chest ticked: Active Requester Chest, Cyan
2. Storage Chest
   
   Next are Storage Chests. I added a "Logistics" tab with Request Filters to the Storage chest:
   

   

   Storage Chest.png (285.19 KiB) Viewed 9222 times

   How the Request Filters work:
   
   • Set filter(s) by clicking, selecting item type(s) and setting amount(s) (just like in Requester Chests)
   • Robots will only insert the specified amounts of the selected item types.
   • If no Filters are applied to the Storage Chest they accept any item until the chest is full (like they work currently).
   • Items will be requested only from Provider Chests and only provided to Requester Chests, but not from/to other Storage Chests!
   What this changes:
   
   • Being able to specify exactly the item type you want to have in a Storage Chest. No more mess due to Robots dumping stuff all over the place at random.
3. Provider Chest
   
   Provider Chests gain a "Logistic" Tab for Provider Filters and also two checkboxes:
   

   

   Provider Chest.png (289.16 KiB) Viewed 9222 times

   How the checkboxes work:
   
   • "Output to Requester Chests": Determines if the Provider Chest can provide for Requester Chests.
   • "Output to Storage Chests": Determines if the Provider Chest can provide for Storage Chests.
   By default both are active, but at least one has to be active at each point or the chest wouldn't do anything.
   
   Naming of the Chests and example Color Coding (to match with the initial sketch):
   
   • Both ticked: Standard Provider Chest, Magenta (The way currently Active Provider Chests work)
   • Only Requester Chest ticked: Passive Provider Chest, Red (The way currently Passive Provider Chests work)
   • Only Storage Chest ticked: Active Provider Chest, Violet
   How the Provider Filters work:
   
   • Set filter(s) by clicking, selecting item type(s) and setting amount(s) (just like in Requester Chests)
   • Robots will only take item types that are specified by the filters, any other item types in the chest that are not covered by a set filter are left alone.
   • If no filters are applied bots will take everything (just like now).
   • The amount determines how much of the item type is left inside the chest.
   What this changes:
   
   • We don't need 2 different Provider Chest items anymore. One rules them all. And it can do even more than both of them.
   • The filters allow the chest to be used as buffer storage for assemblers: Some items can be taken by bots, but the set amount gurantees that some items are left inside.
     To give you an idea... it could be useful in Circuit production: You might want to split off a certain amount of Electronic Circuits to be taken by Robots but you also want to remain enough Electronic Circuits inside the chest that an inserter can grab them to produce for example Advanced Circuits right next to the chest.
   • The filters also allow for other items inside the chest that you want to remain in the chest instead of being taken out. That way you can crossroad 2 production lines over the chest and still use it as Provider chest.
4. Chest Priorities (If you want to know more in-depth):
   
   Chest Priorities

   As you might know the Requester Chests need to know in which order to take Items from Provider/Storage chests or it would result in a complete mess. I basically adapted the current priorities and expanded it with the additional Chest types of my Concept:
   
   Standard Requester Chest:

   1. First Storage, reason: You want less stuff just rotting in the Storage (like currently)
   2. Then Standard Provider, reason: Since Standard Providers can overflow into the storage and you want to avoid unnecessary robot movement they come before Passive Providers
   3. Then Passive Provider, reason: Basically a low priority backup to the above

   Passive Requester Chest:

   1. First Standard Provider, reason: Same as above, since Standard Providers can overflow into the storage and you want to avoid unnecessary robot movement they come before Passive Providers
   2. Then Passive Providers, reason: Basically a low priority backup to the above

   Active Requester Chest: Only Storage, no priority necessary here.
   
   Storage Chest priorities:

   1. First Active Provider Chests, reason: You want stuff to flow into the storage on purpose, so it has to take priority
   2. Then Standard Provider Chests, reason: You want stuff to be put in Requesters, but if they are full they can optionally overflow into Storage (like Active Providers currently)
5. General Stuff:
   
   The chest colors would change according to the settings inside the chests to give a visual impression of the current settings of the individual chests. The color codings given above are just examples... they could be whatever the devs/people like of course to make them stand apart from each other.
   
   Existing Logistic chests placed throughout the maps could be easily converted to the new format as they wouldn't require you to replace anything. The way the Logistic Chests work currently is only a subset of my concept.
6. Further simplification to only using 1 Logistic Chest:
   
   Due to the way I managed to make the chest windows almost completely consistent with one another with my concept, one could go even a step further and simplify Logistic Chests into only ONE Chest using radio buttons to chose from 3 possible ways the chest can work, something like that:
   

   

   Provider Chest 2.png (291.62 KiB) Viewed 9213 times

   The sub options get greyed out depending on the selection.
   
   Then we would only have 1 Logistic Chest altogether instead of 4 currently (3 with my above concept) and the settings inside the chest determine how the chest is supposed to work. However that would mean people would have to fiddle more with windows additionally to plopping stuff down (that is until they blueprint chest setups), but it would remove 3 items from the crafting menu/inventories.
7. Renaming issue:
   
   Because ratchetfreak and ssilk brought this to my attention...
   

   The current chests are converted, so that the logistic system you already created in an existing game doesn't break:
   
   Active Provider -> Standard Provider (*)
   Passive Provider -> Passive Provider
   Storage -> Storage
   Requester -> Standard Requester
   
   (*) I think this is eventually an issue, or something which must be communicated very well. But it could be handled. For example: The upgrade-script can pop-up a big box, that explicitely explains that change ("converted X active provider to standard provider, cause ...") and the player needs to confirm that.

Other sources and threads on the topic: viewtopic.php?p=118776

[Melfish]

This looks quite good.
Can we already mod this system in the game?

[ssilk]

Nice, good thoughts. I really like the symmetry of the chests, I think that can make things really much easier.

But you forgot about the priorities.
Example: Now it is so, that requester chests first request from active providers, then from storage chests and then from passive providers.

And to be sure I understood you right: How do you implement a box for repair packs, that holds some number for fast repair at the borders, so it requests some repair packs from the center and provides it to the construction bots stationed at the borders?
I ask, cause I tried to think into this direction but didn't found a good way, cause now it's not longer clear, where are construction bot tries to take items first.

I also want to point to
viewtopic.php?f=67&t=8905 Overlapping Logistic Network II
When fixed the problems of this I and combined with that suggestion I think it can solve nearly all possible logistic problems.

[MeduSalem]

Nice, good thoughts. I really like the symmetry of the chests, I think that can make things really much easier.

Thanks, I am a real sucker for symmetry. I simply can't live with stuff being asymmetric when they could be symmetric.

But you forgot about the priorities.
Example: Now it is so, that requester chests first request from active providers, then from storage chests and then from passive providers.

Yeah well I thought about priorities as well, but I didn't include them in the post because it might have gotten a bit overwhelming then and as a matter of fact it is something that could be discussed or balanced once it shows some weird, unintended behavior.

But why not, let's discuss it. I assume we will leave the priority of Storage chest as it is, meaning the bots should always try to empty the storage chests first so you don't have as many items doing nothing, though as a fact we could argue about that as well of course. So with how storage chests work currently in mind I would say it could work like this:


Standard Requester Chest:

1. First Storage, reason: You want less stuff just rotting in the Storage (like currently)
2. Then Standard Provider, reason: Since Standard Providers can overflow into the storage and you want to avoid unnecessary robot movement they come before Passive Providers
3. Then Passive Provider, reason: Basically a low priority backup to the above

Passive Requester Chest:

1. First Standard Provider, reason: Same as above, since Standard Providers can overflow into the storage and you want to avoid unnecessary robot movement they come before Passive Providers
2. Then Passive Providers, reason: Basically a low priority backup to the above

Active Requester Chest: Only Storage, no priority necessary here.

Storage Chest priorities:

1. First Active Provider Chests, reason: You want stuff to flow into the storage on purpose, so it has to take priority
2. Then Standard Provider Chests, reason: You want stuff to be put in Requesters, but if they are full they can optionally overflow into Storage (like Active Providers currently)

And to be sure I understood you right: How do you implement a box for repair packs, that holds some number for fast repair at the borders, so it requests some repair packs from the center and provides it to the construction bots stationed at the borders?
I ask, cause I tried to think into this direction but didn't found a good way, cause now it's not longer clear, where are construction bot tries to take items first.

For your given example I would then put Storage chests at the border, set them to request Repair Packs (whatever amount is suiting you). The robots will then either take from an Active Provider or Standard Provider (both being able to feed Storage chests) located in the center of your base. The type of Provider is depending on what you prefer.

The Logistic Robots would deliver the Repair packs to the Storage chest until it is filled with the amount of repair packs you specified. If then something like a Wall/Turret gets damaged the Construction robots fly to that Storage chest (as long as it is the nearest one) and grab the stuff they need. So you can place Storage chests with the same setting all along the perimeter and have local buffers. In that usage scenario the Storage chests would act much like "Relay Chests", like has been suggested here by patmo98: viewtopic.php?p=134455

A problem arises once you have a Requester Chest nearby the Perimeter requesting for Repair packs. Then obviously Logistic Bots would come along and grab from your Storage Chest located at the perimeter and try to feed the Requester Chest. But since the Storage chest will then start to request more Repair packs again Logistic Bots from the center of your base will try to stock up the Storage chest. But it could also be circumvented by forbidding these requester chests to take from Storage chests (making them passive).

The above behavior would be fine though for Gun Turrets! You would want the Active Requester Chests (only requesting from storage chests) at the gun turrets to take Ammunition from the local Storage chest buffer!

The nasty part would start when the Local Storage chest runs out. Then the bots would dodge to the nearest Storage chests still having items, so you will have to look that the storage chests get restocked in a timely manner.

I also want to point to
viewtopic.php?f=67&t=8905 Overlapping Logistic Network II
When fixed the problems of this I and combined with that suggestion I think it can solve nearly all possible logistic problems.

Yeah, I had some ideas for the overlapping Networks as well, but they are worth their own thread. But basically I would make the Logistic Networks color-coded or something like that and to which network(s) a chest belongs could be seen on hover in the sidebar. Robots and Roboports would be shared amongst all networks.

But then again we might not even need overlapping networks anymore when Storage chests can be told to request only specific items. Then you wouldn't have to fear the problems of thrashing everything anymore. Like for example if you are using robots for train unloading of ore the robots would only dump the ore into storage chests with ore filters located next to the train station... and not all over the entire base.

It's a thing that would remain to be seen if my concept would be applied. Maybe we would still face situations where color coded networks wouldn't be too bad.

[patmo98]

So after reading through various other threads on Logistic Chest suggestions I propose the following concept on how to vastly improve on the abilities of the Logistics network, while only having 3 chests (yeah I would get rid of one).

Basically my concept achieves following:



So how to do that with only 3 chests?

So I'm working my way through this, but I'm trying to figure something out from the diagram... Are all requests transitive? For example, can a Standard Requester in your diagram take directly from an Active Provider, since they're indirectly connected? (This is the way Factorio currently works.)

[MeduSalem]

So I'm working my way through this, but I'm trying to figure something out from the diagram... Are all requests transitive? For example, can a Standard Requester in your diagram take directly from an Active Provider, since they're indirectly connected? (This is the way Factorio currently works.)

No, "current" Active Provider Chest would be basically the "Standard Provider chest" on the sketch in functionality. So the active Provider Chest in the sketch can't deliver to Requester Chests, only to Storage chests - a functionally that isn't in the game currently.

[ratchetfreak]

There is a path missing from the active providers to the requesters

As it stands you need a storage chest as a stop-over to get something from a active provider to any of the requesters.

[ssilk]

What you mean is the standard provider. The active provider should only deliver to storage and has first priority to empty it. That is a bit of game-change / name-conflict. I think there should be a different name for that, but I cannot think to a better one.

Well, question to MeduSalem: How must the current chests be converted, so that the logistic system you already created in an existing game doesn't break?

I mean like so:
Active Provider -> Standard Provider (*)
Passive Provider -> Passive Provider
Storage -> Storage
Requester -> Standard Requester


(*) I think this is eventually an issue, or something which must be communicated very well. But it could be handled. For example: The upgrade-script can pop-up a big box, that explicitely explains that change ("converted X active provider to standard provider, cause ...") and the player needs to confirm that.

[MeduSalem]

There is a path missing from the active providers to the requesters.

This is intended.

Currently (as of 0.12) Active Provider can provide to Requester+Storage but with my concept that Provider type would be renamed to "Standard Provider" having the same functionality.
The Active Provider of my concept would then only be able to feed to Storage.

It derives from setting the Checkboxes:

• Checking "Provide to Storage", while leaving "Provide to Requesters" unchecked = Active Provider
• Checking "Provide to Requesters", while leaving "Provide to Storage" unchecked = Passive Provider
• Checking both "Provide to Requesters" and "Provide to Storage" = Standard Provider (Exact behavior of 0.12 Active Provider Chests)

I understand the renaming of this one chest is a bit confusing, but it makes sense once you figure out why. I did the renaming because I applied following name scheme:

• Active Chests = Fiddle only with Storage chests
• Standard Chests = Fiddle with eveything
• Passive Chests = Fiddle with everything except Active Chests

I know it would take a bit of getting used to that name change.

But of course people could come up with a totally new naming scheme for the chests as well while we are at it.

As it stands you need a storage chest as a stop-over to get something from a active provider to any of the requesters.

If you want the Provider to be able to Overflow into the Storage chests -> You would use a Standard Provider Chest (which provides exactly the functionality like Active Provider Chests do as of 0.12).



[Edit]

Ah damn ssilk beat me to it. He explained the renaming issue in a TL;DR manner!

Well, question to MeduSalem: How must the current chests be converted, so that the logistic system you already created in an existing game doesn't break?

I mean like so:
Active Provider -> Standard Provider (*)
Passive Provider -> Passive Provider
Storage -> Storage
Requester -> Standard Requester


(*) I think this is eventually an issue, or something which must be communicated very well. But it could be handled. For example: The upgrade-script can pop-up a big box, that explicitely explains that change ("converted X active provider to standard provider, cause ...") and the player needs to confirm that.

Exactly. A script would convert the chests according to how you describe it... and the next time you load the map there could be a Popup stating the reason for the renaming so you aren't left in the dark. That is if we would agree on using the naming scheme provided in my concept, maybe someone finds better names, but it might cause even more confusion if you'd change the names even more radical. I already tried to minimize the renaming...

Wasn't there a similar popup notifying you back when the Turret sizes changed? Can't remember anymore.

[ssilk]

• Active Chests = Fiddle only with Storage chests
• Standard Chests = Fiddle with eveything
• Passive Chests = Fiddle with everything except Active Chests

Ahhhh! When I see that list it was clear for me. It should be named like so:

Active -> Storage
Standard -> Multi
Passive -> Temporal

So an Active Provider would become a Storage Provider (cause he can put things only into storage chests). A Standard Requester would be a Multi Requester (cause he can put it everywhere). And a Passive Provider would be a Temporal Provider (cause he is thought for temporarily storage - it's some kind of a "non-storage"). For the last one I had also the idea to name it "JIT" (Just In Time - the "opposite" of storage), but that might be too clumsy.

Not sure, if that works for every constellation. But open for better ideas.

[MeduSalem]

Ahhhh! When I see that list it was clear for me. It should be named like so:

Active -> Storage
Standard -> Multi
Passive -> Temporal

So an Active Provider would become a Storage Provider (cause he can put things only into storage chests). A Standard Requester would be a Multi Requester (cause he can put it everywhere). And a Passive Provider would be a Temporal Provider (cause he is thought for temporarily storage - it's some kind of a "non-storage"). For the last one I had also the idea to name it "JIT" (Just In Time - the "opposite" of storage), but that might be too clumsy.

I could live with the Storage/Multi naming scheme... they would make sense.

I also think that Just in Time is explaining better how passive chests work, but it is too long of a name. There would have to be something shorter... Temporal sounds somewhat strange... it's close to but not yet quite to describing the just-in-time effect, if you know what I mean.

[Anson]

congratulations for this great idea !!!

i already had thought of adding the item selection to storage chests, but that was a very limited idea and is automatically part of your new system.

also the option to have providers and requesters which only do business through storage chests might take care of some more of my problems with buffer chests that also should provide items for the player and accept items from the player's trash without causing loops.

as a second stage, this concept might even be extended by specifying optional priorities, so that you can have eg primary and secondary storage for items and lowest/default priority for junk/overflow, or give priority to get a small amount of ammo to primary storage (for use by the char) first, then provide turrets with secondary jit requesters, and finally keep an additional supply in tertiary standard providers for refilling everything later (fast, on demand) ?

if/when the developers don't want to do such a big change before 0.14, 0.15 or even at all, would it be possible to do a mod which implements this unified logistic chest ?


about the name system: "storage" and "multi" sound fine to me, although it might become confusing when i first speak of "multi chests" (meaning multi providers and multi requesters) and then speak of "storage chests" (would i be speaking about storage provider and storage requester, or about storage chests themselves). maybe no chest should be named like a part of other chests' names, but i have no better idea myself. or do i really want storage chests to become "retention chests" to avoid that possible confusion and create another confusion by renaming the existing storage chests ? :-)
for the third type of chests, i would like "Jit" better than "temporal" (they have no flux compensator :-)

maybe a native english speaker has some better idea than i can come up with.

edit - new idea while reviewing what i just wrote:
either rename storage chests to "buffer chests" (would still create confusion for renaming storage chests), or rename the provider and requester chests to "buffered provider" and "buffered requester" since the items have to go through storage chests as a buffer. and that also starts a new idea for the third type of chests: what about a simple "direct" since "direct providers" deliver items only directly (without buffer) to requesters and "direct requester" since they only get items directly (without buffer) from providers. their collective name of "direct chests" probably would be a matching opposite of "buffered chests" ...
summary: providers and requesters would be buffered/standard/direct chests, while the buffer chest would keep the name "storage".

[ssilk]

Liked the "unified logistic chest" so much, that I changed the title.

I like also the ideas for naming.

[MeduSalem]

The other day while playing around with 0.13 circuit network stuff I also had the idea what if the circuit network signal could actually influence WHICH type (Requester/Storage/Provider) the logistic chest acts as... and additionally set the filter(s) for items. In requester chests it would then request the item set in the filter, while as provider chest only the item set in the filter is allowed to be taken from the chest.

That would mean that one could change the chest type dynamically and influence item flow in ways unknown yet.

Then it might actually make sense in the far off future to make Inserters bidirectional. While inserterting resources a chest could work as requester and once the assembler is finished move the item back to the same chest and then change it to a provider or ridiculous stuff like that.

[Patashu]

Just wanted to say that this suggestion is really cool. As one additional suggestion, maybe make it possible for storage chests to have only construction robots take from them (not logistic robots) so you can have construction bot only chests, by adding just one checkbox. Or is this not really needed anymore?

[Optera]

Good job necroing this topic. It deserves more attention.

[mrvn]

How about having just one chest and then set filters for the minimum and maximum number of desired items.

Without filters anything can be stored just like a storage chest now.
A filter of anything or everything would keep the chest as general storage but limit the amount.
If an item is below the minimum then more of it is requested. This would be like a requester chest now.
If an item is above the maximum then it is moved to some other storage chest that is below maximum. This would be an active provider chest now.

[JeyJeyKing]

Hello and thanks for your suggestion. I hate to be the first nay sayer but:

I feel like the system is very good the way it is right now: 4 simple functionalities in 4 items making up a coherent system.
It is clear what everything does by the name of the item. I can just plop chests down left and right and stuff happens. Additionally I can look at other peoples' work in MP and understand what it does just by looking at it.

In contrast:

Your suggested change is 7 functionalities on 3 items resulting in a rather complicated system.
This means I cannot just build the 4 different chests, place them where I want them and sometimes do a little extra configuration, no, you'd probably have to configure every chest you place down. I'm not saying that this would be too much of a hassle, but it would be a hassle nonetheless and I'm not yet convinced that it would be worth adding.
It would be moving the structure of functionality away from items into the GUIs of the chests. This means that I cannot just look at a system and take an educated guess what it does, I'd also have to click on the chests and see how they're configured.

What I understood that you would like to achieve is:

Remove one chest. Make stuff simpler. But the way I see it, to compensate this you have to add a lot of complexity to the remaining chests, effectively not really making it simpler.
Make the chests more powerful as a whole. I feel like the examples you have mentioned are things you can already do.

Overall I feel like this would be making the system less intuitive and more complex to solve non-issues and therefore I don't see it happening.

[mrvn]

Hello and thanks for your suggestion. I hate to be the first nay sayer but:

I feel like the system is very good the way it is right now: 4 simple functionalities in 4 items making up a coherent system.
It is clear what everything does by the name of the item. I can just plop chests down left and right and stuff happens. Additionally I can look at other peoples' work in MP and understand what it does just by looking at it.

In contrast:

Your suggested change is 7 functionalities on 3 items resulting in a rather complicated system.
This means I cannot just build the 4 different chests, place them where I want them and sometimes do a little extra configuration, no, you'd probably have to configure every chest you place down. I'm not saying that this would be too much of a hassle, but it would be a hassle nonetheless and I'm not yet convinced that it would be worth adding.
It would be moving the structure of functionality away from items into the GUIs of the chests. This means that I cannot just look at a system and take an educated guess what it does, I'd also have to click on the chests and see how they're configured.

What I understood that you would like to achieve is:

Remove one chest. Make stuff simpler. But the way I see it, to compensate this you have to add a lot of complexity to the remaining chests, effectively not really making it simpler.
Make the chests more powerful as a whole. I feel like the examples you have mentioned are things you can already do.

Overall I feel like this would be making the system less intuitive and more complex to solve non-issues and therefore I don't see it happening.

You already have to configure every requester chest because it needs to know what it shall request. So no change there. Storage chests would be replaced by unconfigured chests so no change there. Passive provider chests are also unchanged as they aren't covered by my idea. So all that changes are active provider chests. You would have to configure my chest to make it behave active.

The advantage would be that you have a combined functionality. A chest can both request ammo clips and actively provide wood. Or maintain a steady amount of repair packs. request if low and providing if high.

[Patashu]

How about having just one chest and then set filters for the minimum and maximum number of desired items.

Without filters anything can be stored just like a storage chest now.
A filter of anything or everything would keep the chest as general storage but limit the amount.
If an item is below the minimum then more of it is requested. This would be like a requester chest now.
If an item is above the maximum then it is moved to some other storage chest that is below maximum. This would be an active provider chest now.

The problem with a 'single unified chest' system is that there are some behaviours associated with the different chests besides just 'what does it request and what does it provide':
-How do you designate a provider as active?
-What chests does logistic trash go to? (impossible/aborted jobs, trash slots from player, items from active provider)
-What chests does construction trash go to? (deconstructed items, impossible/aborted jobs)
-What chests can construction bots take from? (construction, repairs)
When you add it all up and slap them on a single item it becomes too many flags.
With the Unified Logistics Chest concept, a new, unspoiled player can put down, without any configuration except setting what a requester requests, providers, storage and requester chests and get the behaviours of the old logistics chest system, and only need to touch the checkboxes once they have need for more advanced behaviours.
WIth a 'single unified chest' system, said new unspoiled player will not have presets for the different behaviours of provider, requester and storage. They'll have to somehow figure out what the point of the logistics system IS with less hints to go off of. Obviously a tutorial could help with this, but tutorials shouldn't be necessary to learn how something works on a basic level.