Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
Discussions Rules and Guidelines
Report this post
To deal with that problem you would have to multiply signals by weights, which would take at least one combinator per resource (coal * 10, output as A; steam engine * 100, output as A; green circuit * 5, output as A; etc for every single resource and use the resulting value of A to decide when to close the station).
In fact, you would probably need one combinator per resource per train wagon (if the 3rd wagon can't be unloaded then the train will be just as stuck as if none of the wagons can be unloaded).
[If you want to set the weights in one place to avoid having to change hundreds of hard coded constants if stack sizes are ever changed then you'd need twice that number]
Thanks, just to make it easier. This depot will only handle ores so it will be the same amount in every stack so that's quite easy to calculate so your suggestion on the arithmetic cominator might work for this. And just for info, I will only use 2 wagons.
you unload items into storage chests, that put roboport at waiting station(s) and hook it up(you would need at least one stop for each ore if you want it to run). add condition for each train that allows it to leave waiting station only when you have less than X of resource.
ie: you have 200k iron, but you need only 100k. any train that has already loaded at outposts will come back and unload what it got, but then it will go to waiting station. and wait. after ore in storage is less 100k than signal changes and trains transporting iron will get going again.
not exactly what you wanted but I think it is quite simple way to achieve your goal
I went for the first sollution with arithmetic combinators. I play more or less vanilla so I only have four types of ore (coal, stone, copper and iron)
So I hooked up every chest in the station with Greenwire and the combinators. 1 st combinator adds the amount of coal and stone and gives a "A" output, 2nd adds copper and iron and gives a "B" output, and then 3rd adds A+B and gives me the total amount of ores in all my unloading chest for that station.
Then I hooked this up with redwire to a railsignal and condition is if C is bigger than 50K turn light red. I have more space than 50K but when the light turns green I would like to have the possibility unload a whole train right away.
And what I can see, haven't tested it for a long time but it seems to work and I will probably do more tweeking like IF first wagon unloading is full then red and so on.
Honestly, not a good idea to do that on a big scale.
If you don't discriminate trains by their cargo manually, it'll clog up eventually.
Just like a mixed belt.
wire all chests of a station with a decider and a signal of the station
say if chests < XXXX signal goes red, train uses the next station...
However much storage you have, it will evenually become full of the least-used resource, leaving no space for the others.
There is no advantage to having more storage than is needed to cover the interval between deliveries. In fact, having more storage than necessary is a disadvantage, because it makes it harder to analyse the system. Furthermore, any attempts at "smart" supply wil be hampered by the increased latency (analogous to the concept of "buffer bloat" in computer networking).
You cannot indefinitely produce more of a resource than you consume; the extra has to go somewhere. When that space runs out, production will stall. Trains won't be able to offload cargo, so they won't be able to pick up more cargo from the outposts, output chests fill, transport belts fill, mining drills stop harvesting when their output is blocked.
That isn't a problem; that's just the system regulating itself. What is a problem is any kind of mixed storage (chests, trains, belts), because the resources which stop being harvested won't necessarily be the ones which are over-produced.
storage cannot become full if you are not brigning back resources. only things that will become full are chests at the outpost loading station, because trains will not be comming to get resources. and after they are full miners will just stop....
If you use twice as much iron as copper, you have to deliver twice as much iron as copper. If you deliver the same of each, eventually your storage will be 95% copper. Every time that you consume 4 units of iron and 2 units of copper, your system will replace those 6 units with 3 of iron and 3 of copper. Eventually, your storage will contain nothing but copper which can't be used because nothing can consume it without also having iron.
Moving the stall point using circuit networks doesn't change that. But you can't e.g. set a rail signal so that it lets through a train carrying iron while blocking one carrying copper. It may help prevent trains clogging up the offload, but it also introduces latency, and risks creating the situation where a single free slot might start many trains running, only one of which actually gets to deliver.
I normally just build one offload for each resource type. If a resource saturates, the trains allocated to that resource will just circle, attempting (and failing) to offload resources, attempting (and failing) to pick up more. But that's not a problem if your rail network is well designed.
If you're pressed for space and want a small-scale solution, you can use filter inserters to offload specific resources to specific chests, or use slot filters to restrict individual slots in shared chests. But then you need to ensure that a train carrying a saturated resource isn't hogging the offload while a train carrying a needed resource is stuck behind it. Inactivity doesn't necessarily help, as it won't trigger for resources which are being used very slowly. A circuit condition works but you have to actually count up the total storage and set the limit to just under the total (again, so that it triggers on slowly-used resources as well as completely-unused resources).
Ultimately, there's unlikely to be any benefit to controlling signals with circuit networks. It's too blunt a tool for this job. Better to just ensure that un-needed trains depart quickly. You probably need to do that regardless.