Connecting two chest for ignoring a request

[ssilk]

This problem would work in the real world like so:

- a gas station requests fuel.
- fuel is delivered (by a big truck) and stored in big tanks in the earth.
- but instead that the fuel is filled into customers cars, the fuel is moved into another gas station, directly besided (underground belt ).
- the truck, which delivers the fuel now sees, that the first gas station has too low fuel in it's tanks and instead to the refinery, it drives to the nearby gas station to get the fuel from there, cause it is much shorter way.

In other words: What you want to be fixed is a ridiculous situation.
And the problem with this suggestion is the suggested solution. It makes no sense. I really don't want to micromanage that; that produces per sure more ridiculous situations, we don't know yet, than it solves.

In reality this problem doesn't happen, cause the fuel transport costs some. And this is also the way, how I would suggest to solve this problem:

Every item has a "price" which rises, when transported.

Well, I won't explain it much more yet, but some points:
- an item has a price (not yet, that is the change!) and every time it is transported, the prices rises.
- in a chest the price is the average of all prices of the stacks, which is the average of all items. If I take out an item, it has the average price, if I put an item in, the average price of the chest changes.
- of course the requests are fullfilled in a way, that the own average price should not rise.

[JoshLittle]

I don't really understand why it is so hard to understand the value of it.

Collecting a product into one place can also have a value. Proof:
Electric waste constains some few quantities of noble metals. To move the waste and to work on it raises the price of the components. But there is a value after working out some tons of waste which was not usable while it was only waste. So the work raised the costs but also the value. You only have to deside what weights more.

In Factorio the only real cost for transporting is the power the bots use - the infrastructure exists and it doesn't get used up like in real world. Perhaps power is not my problem. I'm a power billionaire. The costs are not even measurable in this case.

Or if you know you need five balls and you know you buyed a lot over time but also lost a lot and you find one here and one there, you will have to buy 3 more. But you already had 10 other balls lying around in hidden corners. You wasted your money on the three new balls. Which you would have been aware of, if they were all together in one place.

In Factorio you don't buy, you produce. And you don't need balls for an event, you need full stacks of material to procude. Sometimes they get lost in non-logical chests. Let's free them back to the network

[ssilk]

Edit: Due to Khyrons very good explanations I thought a bit and I think that it is possible, that I've overseen some aspect. Nevertheless, I won't delete the rest of this post, cause to explain you, why I think this doesn't work. That doesn't mean, that I won't change my mind, if you find better arguments.

...

Its not so, that I do not understand the usefulness of the constructions shown on the previous page. I tried them myselfs. They are useful only for rare situations, like distributing repair pack.

It's just, that I think
A) what is, if I make that with 3 requester/provider chests? I don't want to define 9 connections.
B) I can built evil circles of not-delivering and don't ever find out why.
C) this is not useful for assembling, cause the same can be built with requester chests directly at assembly. As said, distributing repair packs is a useful task. Distributing iron is not.
D) there are major changes to the search algorithms which are optimized to find needed items. Adding some ignore-list to them
E) even, if all of the above problems can be solved: do you really mean, that the average factorio player finds out, how this is working? and why?

So, what I tried to say with flowers, now glas-clear: your solution of disallowing transfer is not working. And if, there are a lot of better suggestions about this problem. They have been mentioned.

[Khyron]

Are the goalposts fixed enough?

Not at all. You keep explaining just one part of a complex scenario with the same very vague parameters. Consequently there are many valid solutions. In order for you to rule out those solutions, you need to be more specific about what the scenario is and how your proposal addresses that scenario.

For example, the screenshot below satisfies all of your requirements. You might need to right click, view image to see the whole thing.


Instructions: Deconstruct the smelter. Drones move it to the requester chest. Inserters move it to the provider chest where it waits for the player to collect them by moving into the roboport range.

However, I'm certain you'll write back and say "No, because I don't want to use two roboports". Well you didn't explain that in the requirements. See?

You should simplify your problem down to the most basic scenario so that it's crystal clear what the cause is and what solutions will be acceptable. To do that, I'd suggest using the minimum factory equipment and items possible. Then describe the desired path of each item with no optional pathing (just explain one source, each waypoint and one destination). Also list the character's logisitics setting with regard to any items involved. If your problem necessitates multiple paths or items, explain each of them in their entirety. Eg: I want wood to be harvested from trees here (show screenshot), moved to a chest here, then moved to another chest here (for "reasons"*). The second flow is I want repair packs to be taken from the factory here, moved to a chest, then to another chest and later moved by logistics drones to my inventory.

*This is the dubious part, why you want more chests involved. TBH, items should not be moved until you know where you want them because it's probably wasted effort. Eg: moving them to a central location is unproductive if you end up wanting them delivered to near where they were first collected.

[JSCarter]

*This is the dubious part, why you want more chests involved. TBH, items should not be moved until you know where you want them because it's probably wasted effort. Eg: moving them to a central location is unproductive if you end up wanting them delivered to near where they were first collected.

Despite being dubious in most cases there may well be occasion where it makes sense to move items to a specific location beforehand.

This game is very much about production management and fine-tuning. Currently the logistic network removes all ability to control item routing leaving it entirely up to the game to decide when/where to move items.

I would suggest that giving the player more option for control is a good thing.

[Alywiz]

I think there is a disconnect when people are trying to think about this problem.

Ill use the gas station example

ssilk over simplified his gas station model for his explanation.

For this situation,

1. The tanker truck (log robot) arrives at the gas station.
2. The tanker attaches to the underground tank (requester chest) and fills it.
3. The underground tank provides fuel to the gas pump (provider chest) by pipe (inserter)
4 The tanker sees that the underground tank is low, so it goes and gets fuel from the gas pump to refill the underground tank to refill the gas pump.

That is how the logistics system currently operates.

Here is a solution I envision,

First, imagine if the logistics gui's had a color designation button. Non-color can provide to any network or receive from any network, but a red requester could only get item from a red provider or non-colored, but never from a yellow provider for instance. That solves the primary gas station problem.

The second part of my solution involves improving the logistics network to more controllable without having to make different chests for each function.

Imagine, that instead of making designated chests, you made a single "logistics chest" that could be upgraded with cards.

Your non upgraded chest will by default tell all robots in range that it needs to be emptied immediately, (It now the highest priority supplier) [Which solves the OP's clearing inventory problem].

Now, the upgrade cards,

The game would have several types, and a higher tier logistics chest could hold more cards to increase its functionality

Requester cards.
1. A "default" card or even check box on the GUI. Every colored network would require a single one and only one. Any items that are being cleaned out of a log chest will go here if they have no where else to go.
2. "Sink" card. When used with a log chest, the card provides a GUI that allows you to pick a certain number and type of items (GUI option should be on most cards). The chest will accept only those items but robots will prioritize sinks over a default chest.
3. "Requester" card. This card will prioritize over a Sink card, and allow you to specify delivery locations for crafting, or provide repair packs to roboports from a central storage, etc.
4. "Polymorphic Sink" card. Has the same priority as a sink card but will allow anything to enter that is already in inventory.

Supply cards
1. the new logistics chest, would be the active provider. It is actively sending any items in inventory into the network. Possibly have a card that does the same thing in case a player wants to keep that function on a chest.
2. "Passive provider" card. A chest with this card will provide items to requester cards, or to players, but not sink cards, making it very useful to pair with a sink card, allowing the player the have warehousing capabilities if he wishes.
3. "Player provider" card. Will only provide items to player requests and nothing else. Usefull for a chest that holds the odds and ends you need occasionally but dont have room to carry all the time. Could be paired with a polymorgh card do neat things.

Have an option on provider cards to leave one item in inventory so for instance a polymorphic sink doesnt lose track of what it is supposed to store.



Additional possible enhancements,
1. "Crafting" cards. A player could build a production chain that only starts producing when he requests a certain item that isn't stored anywhere but doesn't want to or cant produce it in hand, time or material restrictions, but doesn't want the production chain to always be on. Useful for say roboports or locomotives or expensive mod items. useful but not as important as the rest of the cards.
2. Allow priorities to be set in the GUI between cards of the same type. Numerically is preferred to allow players to customize the number of layers of storage to their hearts content. For instance, set your overflow storage with a sink at priority 2 and its will only get items when the primary storage is full. if you have a sudden glut in iron production, you may set it up so that the excess goes into bonus steel production, but if you instead provide a provider card with a higher priority than the primary storage the chests with be used to meet slack in production instead before emptying primary storage.

[The Phoenixian]

Okay my brain isn't working quite right at the moment but I think I'm starting to concieve of what might help the OP here.

For the situation in the images on page one, how well would a "Passive Requester chest" work? That being a chest which requests from active provider chests and passive provider chests but does not pull items from storage chests. If I'm reading you right that would allow you to direct the flow of goods into storage chests in one location or even multiple locations to cut down on flight times and give you a predictable point where you could pick up the parts you wanted.

Alternatively, though this was suggested before, how would placing a filter on a storage chest to give it a slightly higher priority for a certain good work?

[Khyron]

we still don't have a clear description of what the problem is. And by that I mean an example with the fewest parts/steps.

[The Phoenixian]

we still don't have a clear description of what the problem is. And by that I mean an example with the fewest parts/steps.

Rereading the OP again I'm pretty sure Josh LIttle is saying he wants to be able to organize his logistics network such that robots can carry an item to a specific chest and or location and have it still available to be brought out again by the same network.

If I'm reading him right Josh Little wants to be able to dertermine where all objects he frequently requests go so that when robots deleiver them to his player inventory they don't have far to travel.

For another example, I use landmines a lot and a great thing about landmines is that they leave ghosts when the detonate so your construction robots can replace them. A thing that would make it even better though is if I could ask my logistics network to place the mines in a specific location, say near the minefields, so that the construction robots don't have to travel far when replacing them. And thus can do so faster.

The core of all this seems to be making it so that a logistics network can store things in specific locations.

[Khyron]

I guess the only way to do that currently is to move the items by belt to a provider chest at the target storage location. Using the logistics network to get the items to the storage location AND to replace destroyed mines with the one logistics network isn't possible. Whether it should be possible (by design) is another question.

In any case, I suspect there's another problem lurking in the shadows here. Let's say we get these passive requester chests included in the game. Now let's consider a scenario for their use... Let's say we have a massive base with one logistics network. In each corner of the base we set up a provider chest to store mines for rapid deployment. Now consider the pathing logic from the drones point of view. Based on where the drone happens to be at the time it accepts a "rebuild mine" job, where's he going to go? Probably to the closest passive requester chest (if we're lucky). What if that takes him further away from the mine deployment spot? Things could actually get worse than they currently are.

Basically, in order for any solution to this whole thread's problem; drones are going to require very advanced pathing logic: They will have to find the shortest path from the destination to [any source plus the distance to the source from where they are now]. This is a really common problem in games (dwarf fortress, rimworld, stardrive etc etc.). I don't know of any game that's done this yet. Programmatically it's possible, no doubt. Is it resource intensive? Even basic pathing usually is. How long will it take to develop (bug free)? I dunno, those are questions for the devs. I'd certainly consider it a non-trivial problem.

Now, come back to whether this should be possible by design. Well, if we have a base with up to 4 roboports forming one logistics node: Your drone speed research is going to have a much bigger impact on the total delivery time than if you were to have a working passive requester chest system (with working advanced pathfinding). So we have to scale the base up to a much bigger size before the passive requester chest (and functional advanced pathfinding) becomes a significant factor. And here we are again, with a problem that affects only(?) very large logistics networks (discussed in another thread).

Another point is I've heard some complaints/comments that the logistics network is a bit of a 'silver bullet' (answer to all your woes). This would further expand the capabilities of the drone network and cause even less burden on the player to create working factory/belt layouts. These sort of features undermine the fundamental puzzle aspect of the game (as do many requests for features, like that one about making assembly plants multiple levels high etc. etc.)

So... yer. :/

[JoshLittle]

Shurely I mean the same network. What do you mean why I was so shocked as you ment it is possible.

I think your points against requester+provider chest are valid.

But the ideas with an ignoring area around a requester or the cable-connection wouldn't have an influence on the routing (because the route will not be initialised).

This weekend I played way too much ( ), but I tried to find better ways in the logistic network. I really have to say that it sometimes sucks a lot. Specially if you destruct a full chest (or even active providers - thats why I use them very rarely) there is no chance to influence the bots for a better an less energyconsuming behaviour. Even if a few tiles away is a storage chest with (or without, doesn't matter) the same product initialised they fly wherever they want. Sometimes I chased them to see where they put it in and often is was an empty storage chest, not even another not fully filled chest with this product. Sometimes they use a short path (active providers more likely than in destruction-cases), but then there are cases they fly over the whole world. I can't see a rule for that.

So there would be a benefit for a solution of my problem. I could place a requester and a provider wich ignore each other in an area where I rearange f.e. solar fields. On deconstruction they would put it there instead of far far away and take it from there instead of far far away. If there fly hundrets of (de)construction-bots in the current version only 10-20% of them react to an initialised storage-chest, even if they fly directly over it.

[ssilk]

What you tried is in my eyes a missuse of the logistic network. Or let's say the logistic area.

This is the basic idea: You have an area, where everything is distributed equally. That's it.
The problem is, when you try to trick this basic idea out (and this is in my opinion, why we are discussing this here).

"Uh?", you say, "I trick nothing."

Well, you do. The logistic system is thought to move items from provider/storage to requester chest. Nothing more. You trick that out, by moving stuff back to the provider. Ain't gonna work and it doesn't make any sense.

I try to show another point of view: In my eyes a logistic area has a center area, where all the storage chests are. The logistic area is small enough, that it doesn't make sense to distribute the items to the borders. With full researched robot-speed this size is in my opinion around a radius of 250 - 300 tiles. It takes a robot (with full speed researched) about 30-40 seconds for that distance. That is not too long and short enough to work with it.

Much bigger networks don't make sense (in my eyes). And so the need for this.

[JoshLittle]

Apart from the inner area I build my logistic network with the maximum range for orange covering (in the inner part are some places with multiple roboports where the traffic is much higher) and this network is about getting up to 400 roboports. Only about 20 of them are disconnected in differend outer parts to protect the walls (I have 2 big lakes for protection and only have to cover 2 1/2 sides), the rest is one big network (not fully filled yet). The roboports are my biggest consumer for energy, but I have not the tiniest bit of power problem (solar panels only have to deliver slightly unter 10 W if the accumulators are recharched).

So what is the big problem with that? Would it be more effective to cut the inner core out without any connection from it and to manage the logistic overload to deliver the stuff I need to the outer parts? Or is it better to setup a train to get only one oil barrel every 10 seconds (from a field with 8 pump jacks and full speedmodules after they drained to 0.1) instead of using a simple robot?

I think more smaller networks with the same sum of coverage would reduce some problems but would also raise others.

[ssilk]

smaller networks with the same sum of coverage would reduce some problems but would also raise others.

Which are?
I ask, cause of course you need to cut the areas into smaller parts. Of course you need to deliver by train.

[JoshLittle]

The biggest problems that come to mind:

• the false sum of items for the logistic info in smart inserters. If they are delivered to a requester at the border, they are not visible anymore. The internal logistic has to be finetuned every time a new small logistic network is set up f.e. multiple solar areas or multiple defense-lines. If I cut my big network in pieces the pieces between the border-area have to deliver it through. Those steps have to be set up at multiple places. Shouldn't the network make life easier instead of more complicated?
• The supply of the player with armery (capsules, shells) has to be managed
• It affects the bots Right of abode

You really would set up a train to a oil field with 8 pump jacks knowing that the output will drop soon to a ridiculous small amount when not even bots fill their full four slots for it?

[Khyron]

The biggest problems that come to mind:

• the false sum of items for the logistic info in smart inserters. If they are delivered to a requester at the border, they are not visible anymore. The internal logistic has to be finetuned every time a new small logistic network is set up f.e. multiple solar areas or multiple defense-lines. If I cut my big network in pieces the pieces between the border-area have to deliver it through. Those steps have to be set up at multiple places. Shouldn't the network make life easier instead of more complicated?
• The supply of the player with armery (capsules, shells) has to be managed
• It affects the bots Right of abode

The amount of items shown in the logistics network is correct. Items stored in requester chests are no longer available to the logistics network. To say it another way, the requester chest is the final destination of items in the logistics network. To say it another way, once an item arrives in to a requester chest it has exited the logistics network.

If you want to have capsules, shells delivered by drones to the player, put a passive provider chest beside the assembly machine that creates them wherever that assembly machine happens to be. If that's not where you want the items to be delivered from you have several options:

• Move the assembly machine
• Move the items by inserter, belt and/or rail using any combination
• Collect the items by hand and move them manually
• Have drones move them to a requester chest for manual collection
• Place an active provider chest beside the assembly machine and one storage chest within the entire logistics network where you want the items to be stored.
• Combine any number of the above options to accommodate any level of complexity you desire
• Reconsider why you want to move these items. Keep reconsidering until you stop wanting to move those items.

Basically, you continue to complain about the logistics network because you are using it in a way counter to how it has been designed. The design is functional and useful. If you start using it the way it has been explained to you multiple times you too will find the logistics system functional and useful.

You really would set up a train to a oil field with 8 pump jacks knowing that the output will drop soon to a ridiculous small amount when not even bots fill their full four slots for it?

I have never moved oil by drone. I use either underground pipes or train. Underground pipes cost 1.5 iron per tile and then they move oil for free, forever, without fail, requiring no technology investment. I would use underground pipes for any distance too short for rail.

[JoshLittle]

This discussion is really annoying if two people misunderstand what I say (doesn't matter if it is because I'm not a native speaker or because of the content) and the arguments for one line of discussion are misrepresented in the other line. I'm aware of the machanics you explain. Why do you treat me like an idiot? I have one big network right now because one production with one provider for an item is just easy and simple to get refilled at any place in the network without any complicated movement of items. Then I am told to have really small networks. And I have problems with that. Now you tell me why there are problems with small networks and pretend that I want to have it that complicated. wtf?!

Just one thing: With "false sum" I don't mean the functions of the network are incorrect. It's ok that items fall out of the counting by leaving the network. My goal in managing a facility is to have an overview over the whole sum of items. If in one sub-network 2000 roboports are stored it would be no good idea to produce more. But if the main/production-network only sees the amount of it's passive roboport-provider, which is constantly drained by a falsely micromanaged border-logistic to another sub-network, then the main/production-network has a "false" number and produces endlessly. Once again: the game is programmed correctly for that, but it's just my argument for one big network contrary to many small networks.

So instead of telling me how bad I use the network, why don't you let me see how well both of you use it? What are your useful tricks for solving the problems? Perhaps this direction of information is more productive and less anoying for both sides...

[Khyron]

Sorry Josh, I thought you were deliberately being cheeky. It wasn't my intention to upset you. I'll try and clear up a few things.

In my mind there are only four things the logistics network does for you:

• Bring items to the player
• Bring items to assembly machines
• Build/rebuild/deconstruct sections of the factory
• Repair/replace defenses

The way I would recommend using the logistics network to supply things to the player character is to take items from assembly plants and store them in to passive provider chests right beside the assembly plants. Then have as many roboports as required to cover your main base*. I assume you have one main base where you do most research and manufacturing. If that's not the case, then I would have to see your base before I could recommend a solution. You will probably want to research a few levels of drone speed so that the drones can move faster than you can run, otherwise you need to stand still to have them resupply you.

Similarly, if you require some items to be moved from assembly machine to assembly machine, use one passive provider chest at the source and one requester chest at the destination. IMHO a well designed factory makes minimal use of drones in this way. For example, I use drones to carry motors to the oil processing area to be made in to electrical motors.

*If your base is bigger than the 250-300 tiles ssilk refers to, then you might be unsatisfied by the time it takes drones to deliver items, regardless of having thousands of drones sitting idle. At that point the base is just too big for the speed the drones fly at. So, you can attempt to make drone delivery times shorter by creating separate drone networks. But, you can still have individual networks as big as 250x250 tiles (or whatever size you find the drone deliery times is acceptable). My main base is completely supplied by one roboport (50x50 supply area with the walls at 100x100 on three sides and I expand out one side for some rail depot and solar farms), so for me it's almost unimaginable to need more than 250x250.

[JoshLittle]

Then we just have completely different playstyles. For me it is unimaginable to have the main part just to fit into one roboport (not the roboport itself, you know what I mean ).

To cover the base in screenshots in a usable resolution it would take "very long" so I don't even try. But a few explanasions to give an impression:

• My research is complete. Temporarly I deconstructed my whole research-area (labs + SP-production) because there was not really anything left, but shortly I rebuilded it in a slightly other configuration because I began to like the combat robotics and decided to push it to 20 (atm 13). But logistic was fully researched long ago.
• I don't need thousands of bots. I have around 400-500 logistic and around 500 construction bots (hard to count if the info of the network seems to ignore resting construction bots). When I build solar farms, the displayed sum of bots jumps up to around 960 bots.
• For the basic tasks I use belts (ores, plates, ..). The logistic bots mostly used in the main part between circuit production, the oil processing and the single-task-dedicated assemblers. But also some small tasks like "mining" on an island, oil transport (hey, what is better to transport 1-4 barrels than a bot?) and the player-supply.
• It doesn't matter for me how much time a bot or a belt needs for the transport. I like two full slow belts more than a fast belt or a train for which I don't know where to get the ressources from. So I didn't need trains yet. I never ever though of building a train within the base. Instead I use long belts. I see the benefit from building posts on orefields, but my map never had large fields for which it would be beneficial to build a train to. Most of my fields can hardly fit 10 mining drills (with a double gap).
• So in my early game I decided to expand my walls to the next reachable field and kept going with it when I needed another one. Since armor MK2 and a good reactor+shield+sceleton ratio I just expanded for fun (or to reach the rare oil-dots). The area was growing and left the place for the oversized solar-production. In the 50h chart the first steam enginges meanwhile are out of the picture.
• I also tend to make the input-storage a bit bigger. For crude oil I have (1+5x4+2=) 23 tanks (they had everything from completely dry to completely full).
• I don't think the drones are to slow. The highest reachable speed is ok and has a good game-balance. For me they can nearly take the time they want (because if I need to move masses I use belts or small chains of chests with stackbonus) - and if I had really big masses then I also would use a train.

[ssilk]

The biggest problems that come to mind:
[*] the false sum of items for the logistic info in smart inserters. If they are delivered to a requester at the border, they are not visible anymore. The internal logistic has to be finetuned every time a new small logistic network is set up f.e. multiple solar areas or multiple defense-lines. If I cut my big network in pieces the pieces between the border-area have to deliver it through. Those steps have to be set up at multiple places. Shouldn't the network make life easier instead of more complicated?

Good point.
What I've in mind is not just to "split" an existing area. I add another layer (=color) over (or above) the first. There are then areas with both colors.

[*] The supply of the player with armery (capsules, shells) has to be managed

What's more important: Delivery within time or delivery without having to work for it?

[*] It affects the bots Right of abode

Not a point

You really would set up a train to a oil field with 8 pump jacks knowing that the output will drop soon to a ridiculous small amount when not even bots fill their full four slots for it?

What you want is a game without "working" for it. That's not gonna work.