Factorio Forums

Following setup: I have a train-to-train smelter (and basically everything else). I disable a station if I dont have enought products to fill up a train at max speed*.

In the same way, I want to make ingredient deliveries: Enable the station, if I can unload at least a whole train at max speed*.

* max speed is defined as: not waiting for smelters/AMs to process inputs to outputs.

This works great... except when asymmetric drain happens. For example this smelter. It works at max speed*, except if for example only the first wagon gets emptied for a while. In that case 5 of the 6 (or 10 of the 12) chests are fully full of ingredients, and 1 (or 2) are fully empty and this is not enought to call in a train to fill up all the chests.
If we stick to the copper ore example, we have 6*2*2400=28800 copper ore storage. A 6 wagon train has a capacity of 6*2000=12000 copper ore. Therefore I need to call in a train only if i have less than 16800 copper ore stored.

Suppose we have assymetric drain, 2 of the chests are fully emptied while the others are full: used capacity: 5*2*2400=24000 which is more than 16800. The result: The station stays disabled and no train is called in to restock.
There is no easy way to fix this. I have tried one solution of overcommitting which leads to trains hogging the unloading stations basically all the time, which becomes an issue, if you have more than one resource per train track (second screenshot; low density structures production).
This whole issue could easily be mitigated, if empty chests would return a selectable signal to indicate when they are empty: That way one could know what chests are fully empty and just override the relevant, but disabled station with combinators.

Surprised this still isn't a thing. I have an array of storage warehouses I wanted to show free slots available on, and there's no way to do that apparently?

Just trying to get an idea of how full or not my storage space is.

Oh lol, I like just now posted a really similar feature request.

-> viewtopic.php?f=6&t=110550

First, I think you should redesign to avoid asymmetric drain.

Second, you can get what you want from a decider with "everything = 0, output 1 placeholder" attached to each chest or set of chests you're interested in.

computeraddict wrote: Sun Jan 07, 2024 6:35 pm First, I think you should redesign to avoid asymmetric drain.

Second, you can get what you want from a decider with "everything = 0, output 1 placeholder" attached to each chest or set of chests you're interested in.

Show me where you would put that one decider per chest in my first screenshot. I dont see a way to do that. Unless I accept to lose the efficiency of beacons, by getting rid of one, implying i would need to use more active entities.

Disregarding the creation of inefficient designs and adding more active entities, I would already need like 50k of such chests/deciders right now and im reasonably sure it would put a load on the cpu that is going to be felt.

So yeah, im not a fan of that ^^

Fixing asymmetric drain is obviously a priority, but not easy, since over the course of the game it adds up and at some point you will end up with broken stations

someone1337 wrote: Sun Jan 07, 2024 8:00 pm

computeraddict wrote: Sun Jan 07, 2024 6:35 pm First, I think you should redesign to avoid asymmetric drain.

Second, you can get what you want from a decider with "everything = 0, output 1 placeholder" attached to each chest or set of chests you're interested in.

Show me where you would put that one decider per chest in my first screenshot. I dont see a way to do that. Unless I accept to lose the efficiency of beacons, by getting rid of one, implying i would need to use more active entities.

I can fit 5 arithmetic/decider combinators in there per assembler, 3 per furnace with your setups (2 per furnace if you're determined to keep the light).

Which is enough if you're willing to wire the three copper plate chests together (or do them as a 2&1, or 2 overlapping pairs).

And the way you avoid asymmetric drain at the points where you eventually take things off the train (labs, the workshop and walls) is you unload into active providers or only call a train where there's enough space to unload it fully.

In my opinion, by trying to find a means to send your trains away early and requesting a feature for this, you're requesting a workaround for a problem you don't want to solve genuinely.
You solve this problem by implementing even load and unload. By doing this, you also increase efficiency, because you use the full content of a train and not only part of it.
How you solve this, is the challenge the game presents to you, the player.
If with a given station layout balancing cannot be established, that station layout isn't feasible.

There are other missing features better suited for implementation, because they help solving the problem and other problems, not help establishing just some workaround. Such a feature would be the ability to read wagon content in addition to reading train content. If you were able to do this, you would be able to balance train loading and unloading with direct control of wagon content.

Your setup seems to be very dependent of the unloading of the plastic+steel and at the same time loading low density structures into the slots that became free. If incoming wagons don't have perfect content (ratio 2:5) and not too full (you need 10 slots for lds but only 2+5=7 slots for plastic+steel). Seems difficult to achieve for shared slots because you're unable to read each wagon's content. If you instead use filtered slots, you need an additional train to transport the low density structures away.

To balance the drain, balance the output: the chests used for buffering the low density structures. Make sure they all contain the same amount of items by first adding all their content, then divide this by the negative amount of chests. Wire this negative average to each chest-to-train inserter, and wire each chest to its inserter with a different color, so you get the difference of chest content and average. Activate each inserter with condition ANYTHING < 12. This way the same chest cannot be faster filled than any other chest. If you make sure at the same time an incoming train is fully empty you're inserting the low density structures into, you have an even pull of source items.

Additionally, there is always a very small imbalance for sources, so add a waiting condition with inactivity > 10 seconds to make trains leave whose unloading has stalled due to such an imbalance.

I cannot tell if your setup also requires actively controlled unload, but in case the above solution doesn't fully work, you also need to control the train-to-chest inserters for copper/steel/plastic in a similar way as the low density inserters, i. e. make sure every buffer chest has the same amount of source items as its neighbors.

someone1337 wrote: Sun Jan 07, 2024 8:00 pm Show me where you would put that one decider per chest in my first screenshot.

For the ore just stick them in next to the train. There's an entire free column there.

If you wanted to do it for plates too you can lose the lamps.

TL;DR

Making chest/containers connected to networks output Fullness percentage

What ?

It would be great if you could add a "Read fullness" on the Circuit Connections of chests and give it a signal to output on (from 0 to 100 as signals doesn't works with floats), being able to choose what signal to output would also allow to still "read" the exact content of the chest

Why ?

On some trains stations i added some logic that disable the station if the chests are too empty or too full to disable the station so a train doesn't come to deliver or take away 5 plates

An issue i found is that i need to calculate myself the "fullness" of the station everytimes

Ores stack to 50 while plates stack to 100, while some other things stacks to 10, And then you have different sizes of chests.

It would be great if you could add a "Read fullness" on the Circuit Connections of chests and give it a signal to output on (from 0 to 100 as signals doesn't works with floats), being able to choose what signal to output would also allow to still "read" the exact content of the chest

then on the station i can just do "if F (for Fullness) < 300 (i have 4 chests so 4 full would be 4x100 400, so this is 75%) then enable the station"

I checked on both "suggested, implemented and in 2.0" and i couldn't find something mentioning percentages, so i hope this idea isn't a dup

Only way this could work is a "number of occupied/empty slots".

Anything else becomes useless as soon as you have two items with different stack sizes in the same chest.

Illiander42 wrote: Sat Jan 27, 2024 6:16 pm Anything else becomes useless as soon as you have two items with different stack sizes in the same chest.

I didn't though of that, maybe output the number of occupied slots on something like "S" would make more sense and be easier to calculate

Although i don't know if it should be "full slots" or just "slot where at least 1 item is"

TL;DR

Add a readout of the full and empty slots of Chests

What ?

It is often interesting to know how much chest space is already used to determine alarms or influence train stations. If we can read the number of full and empty slots in chests we can save a bunch of combinator logic.

Why ?

This change makes the setup of train stations and other logic simpler, less prone to errors, and easier to use for newer users

someone1337 wrote: Sun Jan 07, 2024 8:00 pm

computeraddict wrote: Sun Jan 07, 2024 6:35 pm First, I think you should redesign to avoid asymmetric drain.

Second, you can get what you want from a decider with "everything = 0, output 1 placeholder" attached to each chest or set of chests you're interested in.

Show me where you would put that one decider per chest in my first screenshot. I dont see a way to do that. Unless I accept to lose the efficiency of beacons, by getting rid of one, implying i would need to use more active entities.

Disregarding the creation of inefficient designs and adding more active entities, I would already need like 50k of such chests/deciders right now and im reasonably sure it would put a load on the cpu that is going to be felt.

So yeah, im not a fan of that ^^

Fixing asymmetric drain is obviously a priority, but not easy, since over the course of the game it adds up and at some point you will end up with broken stations

Fixing asymetric drain has nothing to do with this feature request. Neither knowing when a chest is empty or how many free slots a chest has will fix asymetric consumption. You need to balance chests and you can already do that simply by comparing the number of items in each chest. You just need the space for it.

My suggestion: don't have asymetric drain. Only ever use full or at least balanced trains and this will never be an issue.

What I expected was a "Remaining capacity for item X" signal / condition.

I couldn't care less about:

• empty slots, because it's not telling me the truth about incomplete stacks
• fill levels, because it's telling me nothing about whether an individual item can be stored

So what I actually expect, is either a signal or (in case of trains) a wait condition that tells me "how many items of type and quality X can still be stored".

This has become even more pressing now that with space age, quality results in an unprecedented flood of mixed contents with randomized ratios due to diverging quality levels.

TL;DR

A new Circuit Network option for reading storage chest information. Specifically, the ability to read the total number of inventory slots, and the number of empty inventory slots.

What?

I would like to have a check box added to all storage chests where I can select inventory metrics (different from current contents information). Similar to how train stops and roboports have a check box for what is provided to Circuit Networks, I'd like a check box where the chest would provide the total number of inventory slots on signal T and the number of empty inventory slots on signal E.

Why?

I have a real simple concept that I use for train stations, but trying to implement generic blueprints is overly complex. Parameterized blueprints are an improvment, but still way more complex than necessary. I like to make "drop off" stations that are enabled when there is enough free inventory space to empty an incoming train, otherwise it is disabled. In addition, I sometimes have "pick up" stations that are enbled when enough material is avilable to fill an incoming train, otherwise it is disabled.

As previusly stated, this is currently doable but requires a lot of combinators, even with parameterized blueprints. With this new feature, things get MUCH simpler.
- "Drop off" train stops could be enabled/disabled with: F > (some constant). The "some constant" would be the number of wagons on trains * number of slots in a cargo wagon (e.g. 3 wagons * 40 slots).
- "Pick up" trains stops coule be enabled/disabled by using a single combinator. (Total storage slots - free storage slots) > number of slots in a cargo wagon (e.g. 3 wagons * 40 slots).
- The "some constant" value could be provided globally using the new wireless signals with radar, so only 1 single constant combinator for the entire map.

BONUS VALUE
Consider a map where you have a dozen train stops and you are ready to upgrade their storage from Iron Chests to Steel Chests (or some modded chests). With this new feature, everything just works. Using existing systems, the combinators from the blueprints need to be redone/update since all the calculations for "free slots" changes. Global constants sent via the wireless radar circuit network don't work because stations with iron chests need different constants than those with steel chests.



I really hope all this makes sense. I went through far too many revisions of this posts for it to not be clear.


*** EDIT ***
@#$@!# I screwed up the image. It was supposed to be for signals "E" and "T".

I strongly second this suggestion! It would be one less set of numbers to have to hard-code everywhere (and also be convenient for mods which might change chest sizes, as you said). I will note that with the selector combinator that can output stack sizes (I'm actually not sure if it is DLC exclusive or just 2.0) it would be possible to calculate the number of empty or non-empty slots given the total number of slots plus the signal of the contents, but there still seems to be no way to get the total number in the first place. Even so, I think getting the empty slots for free is useful streamlining, since calculating that value would only be an interesting problem the first time.

EDIT: A signal for the total capacity of a fluid tank would be much appreciated, for basically the same reasons that the OP stated for chests. In this case I don't think we need a specific "Empty space" signal, just the total capacity along with the contents, since fluids don't have slots or stack sizes to complicate things.

TL;DR

Add the ability to read the number of slots in the chest from the circuit network.

What?

Normally a chest connected to a circuit network looks like this:
Assemblers have the ability to expose that they are working, using a custom signal, like this.
Instead, have an option to expose the number of slots currently in the chest, normal steel chests would return 48 and legendary steel chests would return 120.

Why?

Currently, I have circuit conditions for train unloading stations which work by taking the total number of items which can be stored and subtracting the number of currently stored items, divide that by the number per train and this is used as the train limit. With the recent addition of the selector combinator, I no longer have to compute this manually for each item given it's stack size, but can dynamically compute it using the selector combinator and use a constant combinator to specify the number of slots in the station. With the recent changes to chest quality, setting a single value in a constant combinator becomes more onerous because that number will change based upon the quality of chests used by any given station.

Firstly, I think an option to read the free and/or total capacity of containers is much more urgently needed if/when the devs allow Quality to change the capacity of chests. Even though stacks-per-chest is constant in the sense that it can't change over time on its own, it won't be constant over the lifetime of a factory, leading to tedious and uneccessary reworking of combinator networks.

Secondly, I'm not sure if this recent thread viewtopic.php?f=6&t=118236&p=627417&hil ... ts#p627417 should be merged into the discussion, but I wanted to point it out just in case.

As an aside, selector combinators reading stack sizes plus other combinator math would allow someone to calculate the number total slots from the number of empty slots or vice versa, so we only technically need one extra signal output on the chests (but obviously having both would be convenient). We could also calculate "remaining capacity for item X" that others have mentioned from either one of those.

And if the devs do decide to make a change, please don't forget the humble fluid storage tanks, which are also deserving of love