Logistics storage fixes

[Zeeth_Kyrah]

One thing I've noticed with my logistics network is that I don't find automatic storage useful. This is because the items offered at provider chests are offloaded into nearby storage chests with only distance as the deciding factor between them, and these chests are filled randomly with whatever providers happen to be offering. This is no way to adequately buffer a requester chest, nor organize one's materials in a storage array!

I'd like to suggest that a logistics storage chest have an interface where you can define which items to store, up to what maximum amount. That way players will always know where to look to find their stuff, and a reasonable collection of materials can be made available at key points in the physical operations zone. Plus, an automated storage field becomes meaningful, instead of just this thing full of random junk that your drones are always filling up and pulling from instead of the specific chest you want them to pay attention to. You could easily use the same logistics interface the other chests use for this.

I'd also like some way to adjust the priority of a given chest in the logistics system, so that you can say "fill requests from this chest before you check others" or "this chest is low priority, use other chests first". This way, you could tell your drones to grab from a particular provider chest instead of a nearer one, or use a specific storage chest before/after checking your providers, or fill the requester chest after filling the storage chest, and so on. Logical priority would take precedence over physical distance, but only to a limit, so that your drones don't fly all over creation and get themselves destroyed trying to grab iron from a base on the other side of the map. This could be a slider at the bottom of the logistics request/inventory grid, labeled "Logistics priority" with a number from 0 to 9, default 1 (low priority).

[ssilk]

https://forums.factorio.com/forum/vie ... f=5&t=1237
https://forums.factorio.com/forum/vie ... f=5&t=1765
https://forums.factorio.com/forum/vie ... =18&t=1561
https://forums.factorio.com/forum/sea ... 2&start=20

[TGS]

Hmm I'm not really sure what exactly you are getting at. But I've seen this sort of question raised before in other posts. You have the right idea though, it is essentially a storage 'array'. The thing with a storage array is that it really shouldn't be organized because you don't organize an 'array' it is automatically organized and distributed amongst the entire array. It's the same in most computing. If you have say... a large RAID array it isn't likely that you get to choose individual locations for your files. Because that isn't how it works.

It sounds like what you really should focus on is smart chests connected to a red or https://forums.factorio.com/wiki/inde ... it_network to keep stock of everything you have as well as manage the storage space. It isn't particularly hard to do and quite handy. Storage chests can also be hooked up to this network but that is a bit more complex. The main issue is that you got the term right. Storage Chests really do make up a logistics storage array, so you are kind of meant to look at it as a big blob of expandable unorganized storage space. Basically imagine it as a Steel Chest*n That being said, there is nothing forcing you to use storage chests. You can literally use just providers and requesters and it function just fine.

[Avarant]

I don't even know why people use Provider chests. I use storage chests and requester chests.

Resources and intermediates go into storage chests, and requester chests well, request, what they need.

Provider chests always seemed like an unnecessary burden for logistic bots. It doubles the amount of work to get the same job done.



If your storage chests (in place of providers) are filling up 1) that's a great thing, 2) you need to be using those resources.

[TGS]

I honestly think it is fine as it is. I mean it could use some additional 'options' perhaps. But as far as I know this can be achieved through filter inserters and circuit networks. So I would say it isn't broken don't 'fix' it. I know it doesn't work the way a lot of people would like, but that doesn't mean it is broken. That just means it doesn't do what you want it to do.

As was mentioned in another post. Storage chests really should be viewed as a storage 'array'. Similar to a data RAID or cloud array. You don't choose where things go, you simply send it to the array to be stored. And that is the point. Storage. You can access the storage through Requester chests and you can send to the storage through Provider chests. Anything beyond that and you are talking about something else entirely. If you setup a large chunk of storage chests which is what I usually do, you can basically just consider it one really really big scalable/expandable chest. Yes I know people get a bit fussy that it requires uncontrolled bot travel distance but really... if that is your concern then use smart inserters to filter, or build your storage on a separate robotic/logistics network and on your productive network only use requesters/providers.

In short if you want to do that... use only requesters/providers in your main production area then build an express belt a fair distance away with a storage network disconnected from your main logistics network and provider chests at the end of the belts to send stuff to the storage array. The downside is at that point to request stuff you have to move into that area to request. But those are ultimately the choices. The feature is fine, it really is. People are just looking at it the wrong way and trying to make it be something it's not imo.

[ssilk]

There are uses for the storage chests, hm, I don't find it anymore, but I saw some posts about using them at train stations: an own logistic network only for the train station. Provider chests for inserting from the wagons, requesters for output to belts, and storage chests for storage...

Very useful!

[BurnHard]

There are uses for the storage chests, hm, I don't find it anymore, but I saw some posts about using them at train stations: an own logistic network only for the train station. Provider chests for inserting from the wagons, requesters for output to belts, and storage chests for storage...

Very useful!

Post from me, last post on page 1 here https://forums.factorio.com/forum/vie ... f=8&t=1253

Had been just an experient, but it did function very well Answering some previous posts, I actually DO need all 3 types of chest. The logistic robots always try to empty a provider chest, so if you need them as empty as possible, because the next train arrives with waggons full of goods you can't place just storage chests there.

[Zeeth_Kyrah]

Hmm I'm not really sure what exactly you are getting at. But I've seen this sort of question raised before in other posts. You have the right idea though, it is essentially a storage 'array'. The thing with a storage array is that it really shouldn't be organized because you don't organize an 'array' it is automatically organized and distributed amongst the entire array. It's the same in most computing. If you have say... a large RAID array it isn't likely that you get to choose individual locations for your files. Because that isn't how it works.

You get to partition your disks in a hard drive array. Why can't you partition your chests in a resource array?

[TGS]

Hmm I'm not really sure what exactly you are getting at. But I've seen this sort of question raised before in other posts. You have the right idea though, it is essentially a storage 'array'. The thing with a storage array is that it really shouldn't be organized because you don't organize an 'array' it is automatically organized and distributed amongst the entire array. It's the same in most computing. If you have say... a large RAID array it isn't likely that you get to choose individual locations for your files. Because that isn't how it works.

You get to partition your disks in a hard drive array. Why can't you partition your chests in a resource array?

I don't know anyone that partitions their hard drives for 'organization' in an array. If you partition your drives in a hard drive array you don't get to choose what goes where. Not in the standard array concepts anyway. But I think you're missing the point. You aren't supposed to look at logistics storage as 'organized' storage. That's not the point. The point is large expandable storage space that you don't think about. You deposit into and withdraw out of but you don't sit there and organize it. If you want your storage organized, don't use the logistics system to do it.

The way I've used the logistics system I tend to create a fairly large amount of 'storage space' using storage chests, so even if I did want to organize the stuff in them there isn't really any point. Because I can't even 'access' all of the chests cause I don't create 'lanes' with which to access specific chests. I don't take stuff out or put stuff in manually I do it all via requesters/providers. I think if anything this system shouldn't be 'changed' and separate additional more specific chest types should be added. Perhaps a specific storage chest that the player can define what can go into it.

[Zeeth_Kyrah]

You get to partition your disks in a hard drive array. Why can't you partition your chests in a resource array?

I don't know anyone that partitions their hard drives for 'organization' in an array. If you partition your drives in a hard drive array you don't get to choose what goes where. Not in the standard array concepts anyway. But I think you're missing the point. You aren't supposed to look at logistics storage as 'organized' storage. That's not the point. The point is large expandable storage space that you don't think about. You deposit into and withdraw out of but you don't sit there and organize it. If you want your storage organized, don't use the logistics system to do it.

The way I've used the logistics system I tend to create a fairly large amount of 'storage space' using storage chests, so even if I did want to organize the stuff in them there isn't really any point. Because I can't even 'access' all of the chests cause I don't create 'lanes' with which to access specific chests. I don't take stuff out or put stuff in manually I do it all via requesters/providers. I think if anything this system shouldn't be 'changed' and separate additional more specific chest types should be added. Perhaps a specific storage chest that the player can define what can go into it.

So logistics isn't for organizing your systems to provide a local materials buffer, huh? Now I'm going to build something to disprove that.
Also: OS partition, apps partition, data partition. You might not choose exactly what files get stored, but you can designate what sort of materials get stored there.

[Garm]

It is possible to create specialized logistic system. In fact i am making one now that will separate and store different ores at different locations. The only inconvenience comes from roboports - at 4 charging slots and 50x50 service area they are too inefficient for high throughput systems.

[ssilk]

Then I use two roboports. Or three.

Or I remove some bots.

What I found sometimes not so useful, is the size. I like the size of 50x50 but in some cases I don't want to have it connect to another logistic network. I think to press shift while placing, like with the power poles, to avoid connection to other ports/networks. The question is then what the bots will do, if they found, that another port is more near to load, but that one is in the other logistic network.

[Garm]

thats what I meant by inefficient - they cannot support enough robots for area so large.

I think it would be better to add supporting buildings to roboports as i've mentioned before here, or split roboport into two separate structures: one for area other is for charging.

[ssilk]

thats what I meant by inefficient - they cannot support enough robots for area so large.

No, the area has nearly no influence to that, it's the number of bots.

I think it would be better to add supporting buildings to roboports as i've mentioned before here, or split roboport into two separate structures: one for area other is for charging.

See, the logistic robots have a very special usage: random transportation of items within a very limited area. And the transportation power is for them is nearly a constant. When you go beyond that number, they fail.

And what can be done is NOT more chargers or other thing, because that would put the same problem into other region. What we need as players are statistics about the average degree of capacity utilization and transported items, queue waiting time etc. What also might help are a layer, where the background is blended out and I can see better, how they fly. Or some lines I canbelnd into, which show me the material-flows (the thicker the line,the more material flows in one direction, and for that are belts much, much better useable.

You might have a look at this page https://forums.factorio.com/wiki/inde ... ic_network

[Garm]

When I speak about inefficient i am talking about number of bots/area ratio in my case area has direct relation to efficiency of the roboport.

I know where my material flows and how fast the flow is. I also know that 1 roboport is unable to handle 1 blue belt worth of material. And I am not talking about complex sorting - I am talking about 1 belt being inserted into provider chests, so robots can then move items into storage nothing more.

Given the area roboports cover I am forced to use 4 roboports lumped together in order to diminish their coverage area, otherwise different zones would overlap and I would loose all specificity I tried so hard to maintain. And even with said lumping I am stuck with at least 54x54 areas, which make my storage and sorting depot astoundingly huge.

[ssilk]

Hm. Well. We think the same. See my post from 11:37 today.

I also thought about a reduced size of the Roboport. But I think what we are dealing here is space. And there is normally plenty of space in factorio.

Currently I made some "isles of roboports", with some different tasks (station, production, storage, repair). The isles have a distance of about 100 tiles, so there is space left for expansions. And the isles are connected, mostly made with multiple lines of belts. Circuit networks send the needed materials to the other isle, and the inserters send it with the belts. It's working, here and there optimizations needed, but it's working!

What I've learned:
- such robotic network structures need much more space as we are used to.
- I need also space for extensions I forgot.
- the transport between the isles is ... Working, but complicated setup.
- the needed space isn't in the end not that much bigger as without, but the layout of the factory looks very different.

I'm really not sure, if the direction is good. I need some more time to make me a clean picture about. And, yes, eventually you may be right. But eventually something different is needed. Help is needed, but I won't post my factory to not influence others.

So please understand this post not as pro or con: I just don't know. And wanted to explain why.

[Garm]

Thats is why i was proposing either additional structures or separation of function.

Atm roboport can do 3 things well:

- damage repair
- building reconstruction
- blanket coverage for small scale production with high specificity. (provider chests for assembly stations)

Due to the limited charging ability it has limitations:

- inability to field more than ~20 active robots at once

Due to large area of coverage:

- very cumbersome capability to cover specific areas without overlapping.



While I dont particularly mind having slow charge speed anymore - since roboports arent really designed for high throughput, the problem comes to the area overlap. At the moment I build isolated rooms around 54x54 in size (mostly 50x56 and 54x56 actually) which are separated by 1-2 empty spaces. All is good until I need to deploy roboports around the perimeter for repair/re-construction of walls and turrets and i am forced to have perimeter walls at least 25-30 bocks away from actual base due to the overlapping areas.


With this any overly engineered base ends up being humongous: atm few parts of my base are already more than 300 blocks wide and tall. It is becoming more and more impossible to find decent open areas to expand the base.

[ssilk]

Garm, I understood, what you wanted to say yesterday. But this thread is read by more people, so I wanted to give them an idea, of how to deal with it currently.

My ideas to improve the situation:
1. A roboport with 80x80 and only one charger only 2 slots for robots and 1 for repair (but it might be able to request repair packs)
one with 40x40 and 4 chargers (like before v0.8.2 ) like now, and eventually
one with 20x20 and 5 or 6 chargers and no slots at all. But I have not the best feeling with it - I will explain it below!
2. The chargers could be able to handle every queue (they charge faster with rising queue), but the needed power rises exponentially, because the faster charging wastes more and more energy. See also below!
3. As explained above, we can add a feature, that roboports won't connect (like the power poles). But it's very unclear how this could work in detail. I think this make sense together with #1.
4. Statistics over the degree of capacity utilization, transported items, empty runs, total transporting power (items * way), etc.
5. Specialized logistic robots and/or other algorithms, like one, which will let a robot wait (or let him first return to the base), the longer the item source plus destination is away from the robot. Eventually also per Logistic network differently. See also down.
6. We need something, which sends the requests of one robotic network to another. This is my favourite one, see down.

@1: almost your suggestion. I don't like it too much! Because it won't help out of overusing it. It's always possible to go over the limits, even if you make factor 10 more chargers. I tried to explain it already: We don't know enough yet and I think, introducing it now will stop other solutions, because it rewards players too much, which don't deal with belts and inserters and do everything with the bots. We are all lazy.

What I want is first learning, what we can do with the whole stuff (see for example @4 or @6) and then make good changes.

In other words: You must admit, it makes no sense - and for you and most others too - to place copper cable assembly at one side and circuit assembly at the other of a robot network and await, that the bots could compete with the rising need. But players will do and would await, that it works, but it won't. And those players complain here about it. I want, that the game explains, what is wrong with it's behavior, because it's a players fault and not the games.
So I would place this solution at the last place, when everything else is working and now we just need a bit more possibilities.

@2: this will let the player see more directly, that he does the wrong way. But it's really hard to balance that correctly. Also an idea would be that the bots needs more power (also have more capacity and faster charging speed), so that they just use more energy. I think currently that a robotic network should not be much bigger than 500 bots, because after that, in my eyes the map looks very overfilled, crowed, ugly. I don't like it and I think to limit it with the needed power is one idea of many.

@5: Eventually another algorithm makes the whole thread invalid!

@6: See also this thread: https://forums.factorio.com/forum/vie ... f=8&t=2149
I tried that "Drone exchange" at weekend with the circuit network and it works well. Example: Circuit network from the chests of network#1 cables into network#2. Some requester chests in network#2, the smart inserters (on circuit network from #1) place the stuff from that chests on the belts and work only if there are too less items in the network#1. The belts transport it into the network#1 and put it into provider chests. Works quite well, but is currently too much afford for a regular game.

This is really great and I would like to have this much easier, because I'm very sure, that this is a thing, which is really, really good! It's a must! And must work also with trains. In the end I don't want to have such long cables. I want to say "If logistic network 'ssilks home' tells to have too less circuits then request" or so.

----

What I want, is to make a suggestion, that really works, but I think we need to test some more things and wait.

[Garm]

I dont think you've understood. As stated before I dont mind charge speed as much - main gripe is with humongous area coverage of roboport. I would be happy if we would get an antenna that does nothing but gives us 10x10 robot coverage, while charge speed problem can be avoided using current game mechanics.


About drone exchange - I've been using it for abut a week now polishing my rail terminal to perfection, guess where my calculations about 2 roboports per blue belt came from?

[ssilk]

That's what I currently just testing, I want to make it proofable for me.

Where did you mention a 10x10 port? Because after last evening I found, that even 20x20 could be too large.

Currently I would like to have a slider, which I can slide between - eventually too small but ok - 10x10 and - hmmm, eventually too big - 80x80. And depending on that it has more or less open charge ports, more or less docks, more or less charging speed, energy usage...
This is just, to test out, which are the optimal sizes so that we have in the end only 2 or 3 different ports with fixed sizes. Or three slider positions, if we find that the costs are not the point.

Also useful: a button which calls all bots in reach to the dock and keep them there and another button, which kicks all bots out of the dock and disallows docking.

I found it also worth thinking, to set a waiting time per robotic network, which is the time, waiting before a new bot is send into the network (and let him return). Just to play around with it.