Hey guys,
Longtime lurker here, but I couldn't find a solid answer through google or reddit so figured I'd ask the forum.
I was wondering if there was a way to count all the trains in my rail network and output the number as a circuit condition. I'm trying to make a setup for automation that would go something like [if Coal<(Trains x 150 coal) = True]
Any help is greatly appreciated!
Counting trains for circuit automation
-
Mittens The Bear
- Manual Inserter
- Posts: 2
- Joined: Tue Apr 05, 2022 1:14 pm
- Contact:
Re: Counting trains for circuit automation
I think this is a difficult task because you can't know "at all time" what's inside of a train, there is no easy straightforward way to do it. You could read their content before their departure and store it in combinator but that will quickly yield a very heavy combinator build, not sure that's what you are looking for. It should be possible to count trains using the trains stop and "read incoming trains" then trying to make sure trains are always "counted" in one or another train stop but that doesn't allow to know for sure how many "coal trains" it would require some conditions such as that no station can have trains of different ressources incoming at the same time, or it would make the counting much more difficult.
I think i would try to use the "read incoming trains" for a practical use, and that reading and storing train content/type/number in combinator is more a mini-game in itself but it would be difficult to use in a real game. Though even "reading incoming trains" to count all trains is not super user friendly, you could make many trains invisible by mistake and trigger a response from your system, or you could by mistake make too many trains appear by wrongly connecting a wire, less terrible than reseting the memory if you try to store everything in combinator memory but still not very easy to use and deploy overtime.
Maybe more details on the use case could allow some propositions that have similarities but would be easier to go for ?
I think i would try to use the "read incoming trains" for a practical use, and that reading and storing train content/type/number in combinator is more a mini-game in itself but it would be difficult to use in a real game. Though even "reading incoming trains" to count all trains is not super user friendly, you could make many trains invisible by mistake and trigger a response from your system, or you could by mistake make too many trains appear by wrongly connecting a wire, less terrible than reseting the memory if you try to store everything in combinator memory but still not very easy to use and deploy overtime.
Maybe more details on the use case could allow some propositions that have similarities but would be easier to go for ?
-
Mittens The Bear
- Manual Inserter
- Posts: 2
- Joined: Tue Apr 05, 2022 1:14 pm
- Contact:
Re: Counting trains for circuit automation
Hi! Thanks for taking the time to reply.
So I'm working through a Nullius run and I'm starting to get my train network setup. The trains run on fuel canisters that need to be built and filled, then leave empty canisters again as a byproduct. The automation I'm trying to set up is to have the requested amount of empty canisters into the fuel system automatically increase as I stamp down new trains, so that there is a consistent buffer without overproducing.
So I'm working through a Nullius run and I'm starting to get my train network setup. The trains run on fuel canisters that need to be built and filled, then leave empty canisters again as a byproduct. The automation I'm trying to set up is to have the requested amount of empty canisters into the fuel system automatically increase as I stamp down new trains, so that there is a consistent buffer without overproducing.
So I'm not interested in the contents of the trains at all. Just a simple count of how many are in the network. Kinda like how roboports have signals for how many robots are in the network.
Re: Counting trains for circuit automation
I think i have faced this situation, but i'm not so sure, there was water cannister maybe was the burnt result in my memory at some point in game.
You can deal with managing the increase in canister number that is necessary to adapt to the increasing number of trains by making sure of 3 things => 1)there is enough empty cannister at the place where they are filled for 1 full train, AND 2)that there is also enough space for 1 full train worth of empty container at the place where they are unload AND 3) that the recently unloaded empty cannister are refilled in priority over the newly made empty cannister.
1) say you have some assembly making "new empty cannister", you wire their output inserter/belt so that it is not producing/ adding more in the system when there is enough empty cannister for 1 full train of buffer. say 500, so that any train that need some cannister for delivery because you just add it for example, will be able to pick up cannister, after those 500 you keep are filled with fuel, the assembly will remake 500 to restore the buffer, increasing the total count of cannister by 500.
2)Then you also need to make sure at the place where you unload the empty cannister, where there is 500 empty in buffer. That there is also enough room to empty 500 more so that in total there would be 1000 waiting to be filled. Otherwise an train filled with empty cannister could get stuck trying to unload and jam the whole system.
3)The last piece of logic is to use some priority to make sure the "recently unloaded empty cannister" are used in priority over the "newly made empty cannister", which can be done with a splitter and priority input lane. This way when you temporarily have 1000 cannister, the factory will use the correct source to refill 500 and leave the other 500 empty as reserve for any new potential train.
Not sure how such logic would be applied with multiple station to refill/empty cannister. But it doesn't need to know how many trains are there to make sure there is enough empty cannister ready and enough room to handle problems.That's not how robotport knows how many robots are in the network, more like connecting inserters to the logistic network so that they keep X cannister in the system at all time and prevent their assembly from working if the limit is reached already.
If for whatever reason the assembly refilling the cannister stop working, then you will have an acumulation of empty cannister due to the unloads and trains will start to queue at the unloading of empty cannister but no new one will be created since there would already be 500 +.
If for whatever reason the assembly that make new empty cannister stop working, then every additionnal trains will wait for cannister, it will only be when another train unload its empty cannister than the additionnal train that was waiting would be allowed to do something, once the cannisters are refilled and it is loaded, and the other train that unloaded them previously will then wait instead because of cannister shortage for yet another train to unload some empty ones.
There shouldn't be a time where too many cannistesr are created that would require more manual intervention than resuming supply of cannister material or fuel to fill them. no need to purge the system of empty cannister. which i understood was the goal but that's also kinda side stepping the challenge you presented at first so not sure if this is a satisfying answer
You can deal with managing the increase in canister number that is necessary to adapt to the increasing number of trains by making sure of 3 things => 1)there is enough empty cannister at the place where they are filled for 1 full train, AND 2)that there is also enough space for 1 full train worth of empty container at the place where they are unload AND 3) that the recently unloaded empty cannister are refilled in priority over the newly made empty cannister.
1) say you have some assembly making "new empty cannister", you wire their output inserter/belt so that it is not producing/ adding more in the system when there is enough empty cannister for 1 full train of buffer. say 500, so that any train that need some cannister for delivery because you just add it for example, will be able to pick up cannister, after those 500 you keep are filled with fuel, the assembly will remake 500 to restore the buffer, increasing the total count of cannister by 500.
2)Then you also need to make sure at the place where you unload the empty cannister, where there is 500 empty in buffer. That there is also enough room to empty 500 more so that in total there would be 1000 waiting to be filled. Otherwise an train filled with empty cannister could get stuck trying to unload and jam the whole system.
3)The last piece of logic is to use some priority to make sure the "recently unloaded empty cannister" are used in priority over the "newly made empty cannister", which can be done with a splitter and priority input lane. This way when you temporarily have 1000 cannister, the factory will use the correct source to refill 500 and leave the other 500 empty as reserve for any new potential train.
Not sure how such logic would be applied with multiple station to refill/empty cannister. But it doesn't need to know how many trains are there to make sure there is enough empty cannister ready and enough room to handle problems.That's not how robotport knows how many robots are in the network, more like connecting inserters to the logistic network so that they keep X cannister in the system at all time and prevent their assembly from working if the limit is reached already.
If for whatever reason the assembly refilling the cannister stop working, then you will have an acumulation of empty cannister due to the unloads and trains will start to queue at the unloading of empty cannister but no new one will be created since there would already be 500 +.
If for whatever reason the assembly that make new empty cannister stop working, then every additionnal trains will wait for cannister, it will only be when another train unload its empty cannister than the additionnal train that was waiting would be allowed to do something, once the cannisters are refilled and it is loaded, and the other train that unloaded them previously will then wait instead because of cannister shortage for yet another train to unload some empty ones.
There shouldn't be a time where too many cannistesr are created that would require more manual intervention than resuming supply of cannister material or fuel to fill them. no need to purge the system of empty cannister. which i understood was the goal but that's also kinda side stepping the challenge you presented at first so not sure if this is a satisfying answer