throughput/historical statistics in logistic info screen

[vanatteveldt]

I often use separate bases for different goods (i.e. a green circuit factory) and I like how the new logistics info screen (L) makes it much easier to see stock levels.

What I would really like to see is historical information similar to the production (P) screen: deliveries in the past minute / 10 minutes / hour (which is a measure of factory throughput) and stock levels (which is a measure of supply management).

The reason why this would be nice is that the P screen shows global statistics, so to analyse how a single part does this would be really nice. Of course it won't really do much for bases where the whole factory is covered in a single logistics network, but even then the historical stock graphs might be a nice addition.

[Qon]

What I would really like to see is historical information similar to the production (P) screen: deliveries in the past minute / 10 minutes / hour (which is a measure of factory throughput) and stock levels (which is a measure of supply management).

What you actually want: Production graphs local to a specific logistics network

If you want throughput and production info locally within a certain logistics network, ask for that explicitly and directly. That sounds like a good suggestion.
Trying to estimate your local production with a storage graph and a delivery graph together seems really counter-intuitive. A production stats screen for each logistics network gives you that info.

Stock level graph

A stock level graph can be useful for seeing if stock levels are enough. But since storage containers are huge it is likely your storage is oversized by about 100 times and the usefulness of the graph is then very limited. You should try to avoid buffers in most cases. The logistics chests directly connected to the train with inserters have enough storage for 16.8 trains (48*14 / 40). And then there's the stock in the passive providers and requesters in your production area. Your storage can be overkill if you limit your all your chests to 3 slots and and have 0 logistical storage chests.

So in the end this seems like a good feature until you realise it's useless because you have to be religiously anti-buffers to even come close to being limited by your buffer size. If you need to know the trends then looking at the past 10 min or 1 hour local production graph and comparing consumption with production tells you if buffers are going up or down. Or just look if the buffers are empty or full.

Very special circumstances can make this a valid feature though. Maybe? Can't come up with any situation like that atm though....

Delivery graph

This will just be a huge spike for anything delivered by train and won't tell you anything except how often trains come. For intermediate materials (not delivered or picked up by train at that outpost) it will be just the production graph (distorted a bit by buffers being buffers). And the delivery graph resembling a production graph is most important for the input-output materials since that's what the outpost is for, everything else is easily scaled to fit your outpost production goals. So in the end it's just a shitty version of a local production graph. Also a proper network-local production graph will work with a belt base as well as long as it is covered by roboports (without logistics robots).

[vanatteveldt]

I agree that the production graph would be very useful. However, assemblers don't "belong" to a single logistic network, so I thought it would be practical to limit to "members" of the network.

Delivery of finished products is equal to production, so that's fine.
Delivery of raw products is indeed a "spike per train" in many cases, but on the longer term (e.g. 1 hour) it can also show whether supply is enough to match calculated demand. Also, in e.g. a logistic mining outpost it will give a measure of output (I guess you can see the ore as delivery of the finished product for that outpost).

Goods becoming available (i.e. Insertion into provider chest) might actually be at least as useful as delivery to requester chests (as a proxy for production), so maybe that's a better idea.

Stock levels are useful not for keeping track of long term storage (which indeed is mostly useless) but can be very useful for buffers: if e.g. gears ever or routinely drop to zero while iron is never zero, there might be a problem in gear production (too few assemblers, too few robots, or too small buffers).

[mrvn]

How about showing the change in stock levels over time. The middle of the graph would be no change in stock level and then up for when stock was increasing and down when it was reducing. That way even if you have 100k in stock you can still easily see it going up or down by something as little as 10 items / second.

[Qon]

I agree that the production graph would be very useful. However, assemblers don't "belong" to a single logistic network, so I thought it would be practical to limit to "members" of the network.

True, thematically it's a bit odd. But we don't have any other "production networks" that delimit what a "production unit" is. It can be anything, like a selection tool (like blueprint selection) for making production measurement units. This part can be substituted for anything that makes the most sense. The point of the feature suggestion is separating production graphs based on something else than faction.
Electric network is connecting all those assemblers too, but you likely have a global electric grid so it's useless for separating the graphs.

Delivery of finished products is equal to production, so that's fine.

Delivery of raw products is indeed a "spike per train" in many cases, but on the longer term (e.g. 1 hour) it can also show whether supply is enough to match calculated demand. Also, in e.g. a logistic mining outpost it will give a measure of output (I guess you can see the ore as delivery of the finished product for that outpost).

So in the end it's just a shitty version of a local production graph.

Goods becoming available (i.e. Insertion into provider chest) might actually be at least as useful as delivery to requester chests (as a proxy for production), so maybe that's a better idea.

Also a proper network-local production graph will work with a belt base as well as long as it is covered by roboports (without logistics robots).

Stock levels are useful not for keeping track of long term storage (which indeed is mostly useless) but can be very useful for buffers: if e.g. gears ever or routinely drop to zero while iron is never zero, there might be a problem in gear production (too few assemblers, too few robots, or too small buffers).

But since storage containers are huge it is likely your storage is oversized by about 100 times and the usefulness of the graph is then very limited. You should try to avoid buffers in most cases. The logistics chests directly connected to the train with inserters have enough storage for 16.8 trains (48*14 / 40). And then there's the stock in the passive providers and requesters in your production area. Your storage can be overkill if you limit your all your chests to 3 slots and and have 0 logistical storage chests.

So in the end this seems like a good feature until you realise it's useless because you have to be religiously anti-buffers to even come close to being limited by your buffer size.

How about showing the change in stock levels over time. The middle of the graph would be no change in stock level and then up for when stock was increasing and down when it was reducing. That way even if you have 100k in stock you can still easily see it going up or down by something as little as 10 items / second.

This will just be a huge spike for anything delivered by train and won't tell you anything except how often trains come.

[cpy]

So more RAM and CPU usage? Unless we can get it run in different thread or ability to turn it off, it might not be the best idea to add it right now.