Connecting two chest for ignoring a request

[JoshLittle]

It should be possible to throw stuff (f.e. furnices, machines, pumps, ...) somewhere in a logistic network chest, then it is carried away to a central place with a requesterchest but is still available in the logistic network for a temporary request of the player.

When the inventory is nearly full and another task (f.e. attacking) has to be done, it is easy to put a chest (storage, provider) down, throw the not needed stuff in it and go for the task. But after a while it is a big mess. I like the idea of having a central place where all my tools are stored (to have all in place at a visit), but to have them also be able to be delivered.

The strategy to have requesters with those tools requested solves the collecting part, but they are to available to be delivered. By take them out into a storagechest with an inserter they are available again, but then the bots will bring them again and again to the requester only 2 tiles away.

The solution could be a new type of chest which is a requester but also a passive provider (so the stuff has not to be moved out of it) OR it would be possible to connect a requester and a storage/provider chest with cables which prevent the redelivering to the requester.

[Khyron]

This is a pretty awkward problem, but it is solvable with the current logistics system.

You need to stand outside the area covered by your Roboport and drop items in to a provider chest. Optionally you can use a storage chest as your "central place". Drones will move items from the provider chest to the storage chest. Don't use a requester chest for this purpose because once drones move items to the requester chest they won't deliver them back to you at a later stage.

Now, the next time you move inside the area covered by the Roboport, drones will carry stuff from the provider chest (and/or storage chest) to you for any items you've set on your personal logistics settings.

[JoshLittle]

I know the effect of reentering the covered area. After crafting a lot outside I have to be fast to reach a location with multiple roboports to prevent the hundrets of bots from waiting dead at a single outside roboport - or to pick the arriving bots up as well.

The situations I mean are not really solvable in the current system. When I rip down an old orefield with drills and modules which I don't need at this point, I don't have them in my logistic requestings. And I don't want them right know. But I want them to be in a certain location all together waiting for me (= at the moment: requesterchest + inserter + steelchest).

The reservation is not very good (at least after the last peace is delivered the reservation fails) and also seems to be buggy. I have often the effect while moving full chests with bots: I place a storagechest where I want to have it, put an item (f.e. coal) in it and deconstruct the old steelchest full of coal. But they don't bring it to this nearest storagechest also if I marked it with a coal. At the end everything is far far away in another storagechest, where I perhaps sometimes emtied my inventory and a piece of coal landed in it.

[Khyron]

Sorry, I'm not understanding the problem. I understand you don't want drones to deliver stuff to you and you're happy to collect collect stuff from a chest somewhere. How does a single requester chest with those items not satisfy the problem? If you want to build a new mining base, set a requester chest with electric miners, belts, powerlines and whatever else you want. When you're ready to build the mining base, take everything from the chest. How does that not solve the problem?

[ssilk]

@joshLittle: as you describe it, it is too vague, too blunt, not logical, I think.

Could this be shortened to

As player I want a "mobile logistic chest".
Acceptance criteria:
- the chest tries to "suck in" all deconstructions in the neighborhoods
- it provides the items, if there are near constructions immediately, highest priority
- after a while (some minutes) it provides the items, if it is in reach of a normal logistic network, like an active provider chest.

???

[JoshLittle]

OK, forget all the "why"

I want to have a new behaviour to requester-chests:

• It should be possible to tell a requester-chest NOT to ask for the providings of one or some specified (provider/storage) chests.
• When this NOT-connection is done, the requester requests from everywhere but not from the connected providers. The providers deliver to everywhere but not to the connected requester.

This NOT-connection could be done by:

• Red/green(/new color) cables over a pole (= nearly everything of this is already in the game = less programming to do)
• A little menu for requesterchests for an ignoring-area (standard=2? => 5x5 grid; up to maybe 16 => 33x33) which could be indicated by a light-red colored background around it on mouseover
• New chesttype that only deliveres to the player (Edit: Added)

[ssilk]

Erm. To be honest: I don't understand this.
Have you ever played this through in mind? I have and it makes no sense.

Edit: you have explained why, but I still have no good use-case for this. What you want is something NOT! This against human nature.

[Khyron]

I'm still confused too. Maybe a picture/diagram would help.

[JoshLittle]

• The requester should request every wood in the system
• It is passed forward into a chain of boxes (they could be non-intelligent)
• The last box is the output of this "buffer"
• The requester should NOT get the wood from the output (because bots become crazy for nothing; energy consumption)

[JoshLittle]

Same for my two boxes which request some kind of tools I throw in boxes somewhere
After they are collected to this storage they should not fly in circles back to the requesters by bots
Steelchest should be a passive provider chest (if the ignoring for the requesters would be implemented)

[Khyron]

• The requester should request every wood in the system
• It is passed forward into a chain of boxes (they could be non-intelligent)
• The last box is the output of this "buffer"
• The requester should NOT get the wood from the output (because bots become crazy for nothing; energy consumption)

In that diagram you have 1 requester chest and 5 storage chests. Replace every storage chest with a steel chest. You will find that the drones will stop endlessly moving wood back to the requester chest.

I assume you're using those 5 chests only because you've got massive amounts of wood and each chest can only store 2400.

Another way to do this would be to remove all the inserters and just have 6 requester chests.

[JoshLittle]

I know that it doesn't happen with steel chests. That is why the second example has a steel chest at the moment and not a passive provider what I want if it is would be possible. My wood example was just a test to show how close input and output can be located.

I want a storage(-line) to request and to provide.
But: Requesting for input + providing on output = robots get crazy

That is why I'm asking for a way to disconnect the input from the output.

Then I could have a requester + n-times steel-chests + passive provider

[Khyron]

I want a storage(-line) to request and to provide.

Request from where?
Provide to where?

This conversation is a bit like the problem which is a bit like an ouroboros.

I think you want a new type of provider chest that only provides to the player.

[JoshLittle]

I want a storage(-line) to request and to provide.

Request from where?
Provide to where?

From every storage or provider chest in the network (= every chest I potentially throw something in to empty my inventory or which is filled by bots on destruction)
To the player and every other requester (f.e. wood for a requester in front of a small-pole-making-machine)

This conversation is a bit like the problem which is a bit like an ouroboros.

No, at the moment my storage is one

I think you want a new type of provider chest that only provides to the player.

Yeah this would be a way to solve the problem (I already added this idea yesterday to a previous post)

[Khyron]

From every storage or provider chest in the network (= every chest I potentially throw something in to empty my inventory or which is filled by bots on destruction)
To the player and every other requester (f.e. wood for a requester in front of a small-pole-making-machine)

The logistics network currently accommodates [1 to many] source locations and transfers items to [1 to many] destinations. It (now) seems you want to add a waypoint. I would argue that if you want a flow of that complexity, you should make a hybrid logistics/belt or logistics/rail network. Adding one new type of chest only grants you one extra hop in the network. How long until somebody asks for another new type of chest because they want two waypoints? If you use a hybrid of networks, you can have n hops.

[JoshLittle]

What difference does it make to use a belt between requester and provider instead of an inserter?
Or how to put this buffer remotely in the state of providing when I f.e. stand on ores (within the logistic network) and want my stored mining drills back and not want to make another 15?

Can you tell me how to do it with the current tools the game has?

[Khyron]

Can you tell me how to do it with the current tools the game has?

Sure, np. Can we work off one of your screenshots? I'll need the entire path, from where the resources first enter the chain to where they exit; and the conditions which they do so. Also quantity of items and/or time and any other parameters you'd like to specify.

I want to be sure we get all the details of your scenario clearly described before I attempt to solve it because I don't want to have any shifting goalposts, if you know what I mean.

[micomico]

Josh's problem could be solved by the different colored roboport networks, suggested in other threads. This two requester-provider chests could be in different - overlapping - networks with differerent colors, served by different bots, who would not try to take the stuff back from the provider chest to the requester chest.

This is the "bring the repair packs close to the roboport", problem all over again. Just with different items.

It could also be solved, in this case less efficiently, with the ability to set filters in the storage chests and have the logistics networks give those chests higher priority when searching for places to store stuff. Although it doesn't fit perfectly in this scenario, this ability would make for other awesome factory builds.

[JoshLittle]

Then we take the second screenshot with the two requesters and the steel chest.

• The requesters are set to request some kinds of tools, like smelters, furnices, mining drills, oil tanks, ... etc. Nothing is producing them, so there is no initial provider, they all were made in the inventory.
• When I put them somewhere in a provider/storage chest to clear my inventory before a hunt, they are delivered to one of the requester (and then collected into the outputchest)
• This outputchest is currently a steel chest but should be able to provide the tools for bots to bring them to me - or in case of f.e. wood also to a requester for a machine which makes small poles. So the output should be free to go into the logistic network.
• The difference what it makes: Instead of all the things shuffled around the whole area in douzands of boxes slightly filled with it, the things should be collected on a certain location with no other overproducing stuff messing in (f.e. if an active provider flushes cables, the tool-storage should be free from it). And after they are collected they should still be available for the logistic network.
• I'm also thinking for stuff which is made automaticly, like solar panels. With a requester of destructed panels it would be possible to fill them back up into the initial provider via inserter to use the "free" solar panels in the network to fill it's limit up again to prevent an overconsumption of materials.

Are the goalposts fixed enough?

[JoshLittle]

Josh's problem could be solved by the different colored roboport networks, suggested in other threads. This two requester-provider chests could be in different - overlapping - networks with differerent colors, served by different bots, who would not try to take the stuff back from the provider chest to the requester chest.

Disconnected logistic networks have the problem that I have to be in the network of the output/provider. And different kinds of networks are propably harder to implement than f.e. a simple new type of chest. And not to speak of the problem of disconnected wall-protection-networks that are fusing together with a growing base. What is disconnected at the moment will get fused naturally