The feeling I have is that the new train system is more complex than it was. Mind you, this is how I feel, because... well... I don't understand the system.
I have a refinery making fuel blocks. I have a train filled with those blocks and the intention is that this train supplies various outposts.
I watched a video of KatherinOfSky and I got the trains to move to those outposts needing resupply, using her example.
However, I only want to unload, say for example, 200 blocks and I have also set a maximum waiting time of 15s. But when that is done, the train just waits there and the interrupt "loops" back to the destination where it's currently parked.
So, it's not moving, where I expect the train to either move to the next station or return to the refinery to top up and wait until needed.
I also noted that the outpost station after the first cycle moves to the top of the station list. Why?
I never worked with LTN and the whole automation business I feel is complex. DoshDonnington seems like a magician to me, to give you an idea.
Any guidance on where my thinking "logic" runs of the cliff is appreciated. Because I'm not seeing where I set it up incorrectly.
Not understanding interrupts for Train servicing stations
-
- Manual Inserter
- Posts: 4
- Joined: Sun Jan 07, 2018 3:58 pm
- Contact:
Not understanding interrupts for Train servicing stations
- Attachments
-
- 2024-10-27 00_51_23-Factorio_ Space Age 2.0.11.png (101.21 KiB) Viewed 815 times
-
- Burner Inserter
- Posts: 7
- Joined: Sun Oct 27, 2024 4:18 pm
- Contact:
Re: Not understanding interrupts for Train servicing stations
I have not played with interrupts yet (but I have been reading up a little). Based on my understanding from https://factorio.com/blog/post/fff-389 and https://factorio.com/blog/post/fff-395 , whenever the train leaves the station it uses the interrupt scheduler first and foremost to decide where to go next..so that would be why when 15s has passed, it decides that it will go right back to where it is..because that's where the interrupt conditions tells it that it "should go next".
What I would assume you'd need to do, is configure the station itself to disable the station when it's "full", ie when it has the 200 blocks it needs. You could use some green cables and and possibly an accumulator or something to do it. That alone could be enough to fix it.
If you want to get more fancy you could create a "Depot" interrupt as they show off in fff-389 to have it go somewhere out-of-the-way when not needed, or possibly just let it go back to the "Refining - Fuel" platform and sit there until it's needed again.
I hope I understood it correctly.
What I would assume you'd need to do, is configure the station itself to disable the station when it's "full", ie when it has the 200 blocks it needs. You could use some green cables and and possibly an accumulator or something to do it. That alone could be enough to fix it.
If you want to get more fancy you could create a "Depot" interrupt as they show off in fff-389 to have it go somewhere out-of-the-way when not needed, or possibly just let it go back to the "Refining - Fuel" platform and sit there until it's needed again.
I hope I understood it correctly.
Re: Not understanding interrupts for Train servicing stations
How I use interrupts is my trains normal schedule is go to loading station go to unloading station.
Then they have interrupts where if they are low (not empty) on fuel they go to a refueling station to have fuel added to the engines. I don’t transport fuel to each station as the trains now know to go get more when needed.
If you are shipping fuel around you could have the refuel train go to A drop 200 go to b drop 200 goto c drop 200, and then interrupt back to base when its cargo is empty.
Then they have interrupts where if they are low (not empty) on fuel they go to a refueling station to have fuel added to the engines. I don’t transport fuel to each station as the trains now know to go get more when needed.
If you are shipping fuel around you could have the refuel train go to A drop 200 go to b drop 200 goto c drop 200, and then interrupt back to base when its cargo is empty.
-
- Manual Inserter
- Posts: 4
- Joined: Mon Oct 28, 2024 9:52 pm
- Contact:
Re: Not understanding interrupts for Train servicing stations
Following up, I have a question of my own. I want to mimic the LTN behavior of "when station drops below a minimum threshold, dispatch a train to bring more", though I am having a bit of difficulty grasping how to do this successfully. I had a little difficulty with the refueling interrupt but got that sorted (mostly, except if trains are using mixed fuels).
I would prefer to avoid using many combinators for what should be a relatively simple solution to a relatively simple request. I would also like to set up "If supply station doesn't have a full train load, wait until it does" (or find another that does, for something like iron or copper ore that will have multiple loading stations, I figure I can simply enable/disable these based on the supply on hand, enable once the station has a full train load)
I would prefer to avoid using many combinators for what should be a relatively simple solution to a relatively simple request. I would also like to set up "If supply station doesn't have a full train load, wait until it does" (or find another that does, for something like iron or copper ore that will have multiple loading stations, I figure I can simply enable/disable these based on the supply on hand, enable once the station has a full train load)
Re: Not understanding interrupts for Train servicing stations
Everytime the train finishes a schedule (in your case <empty cargo> or <15s passed>), it checks all interrupts conditions to be true or false. In your case, the interrupt condition is "Cargo > 0". So if your trains cargo is not empty after finishing a schedule, the interrupt condition will be true again as there is still cargo in the train. So it will again travel to a station called "Supply" or in your case stays there, as the train is already at a station called "Supply".
If you want to avoid that... just use a combinator at your "Supply" stations to check if the station got its items and then turn off the train station / set train limit to 0 and your train will travel to the next active "Supply" station.
If you want to avoid that... just use a combinator at your "Supply" stations to check if the station got its items and then turn off the train station / set train limit to 0 and your train will travel to the next active "Supply" station.
-
- Burner Inserter
- Posts: 7
- Joined: Sun Oct 27, 2024 4:18 pm
- Contact:
Re: Not understanding interrupts for Train servicing stations
For this I would just set a station condition to have the station enabled/disabled based on whether it has a full load/needs more. As long as each station only deals with a single type of item (crude oil, for example) you don't need any combinators, just some green or red wire connecting your storage with the station, then you set the condition on the station directly.BradSwiftFur wrote: ↑Mon Oct 28, 2024 10:00 pm I would prefer to avoid using many combinators for what should be a relatively simple solution to a relatively simple request. I would also like to set up "If supply station doesn't have a full train load, wait until it does" (or find another that does, for something like iron or copper ore that will have multiple loading stations, I figure I can simply enable/disable these based on the supply on hand, enable once the station has a full train load)
If it's the dead-simple case of one train always only dealing with crude oil you don't even need interrupts, just disabled stations. Interrupts for refueling would still be nice, though the trains could conceivably get stuck at the refueling station waiting for one of their normal stations to get enabled, so you might have to handle that case too.
For more complicated cases accumulators and/or combinators may be unavoidable.
-
- Manual Inserter
- Posts: 4
- Joined: Mon Oct 28, 2024 9:52 pm
- Contact:
Re: Not understanding interrupts for Train servicing stations
So I'm trying a relatively simple setup where:
Supply stations are disabled if less than one trainload is available
Requester stations are disabled if they hold more than one trainload
Each requester station gets one Decider Combinator. Input is from the chests, also connects to station (so it can know whether to disable or not.) Requester station outputs "Read Train Count (C)", which the Decider Combinator receives along with the chest contents. Output "Send To Train" is disabled (otherwise the train gets a signal for many items and it triggers the interrupt!). The combinator checks "Quantity of item less than one trainload" AND "Train Count (C)" less than one. When both conditions are true, it outputs an "Item 1" signal to the network (which denotes "Send 1 train load of this item"). When a train is incoming, the Train Count should = 1, which tells the combinator that the call has been answered and to turn off the outgoing signal.
Each provider station gets one decider combinator and one arithmetic combinator (it's sole purpose is to invert an output of one to -1). This decider checks the network for the incoming item request signal (Item More Than 0) and (on a separate wire so as to avoid "contaminating" the input signal with the station "Quantity Available") Train Count More Than 0. It basically checks "I see a request, AND train incoming to answer the request", output Item -1 (to cancel out the "I need 1 train load of this item" which is still on the network from the requester station.) But since the decider combinator can't output a negative 1, it goes through an arithmetic combinator for that, which outputs back onto the network.
The train(s) wait at depots where they idle with a wait condition of 3 seconds, the idea being that it will be exceedingly rare that any 2 trains will check the interrupts at the exact same game tick, and only one will answer a request, thus triggering the provider station (with the Train Count) to cancel out the requester's call for goods.
My current issue now involves not so much the system working (if a bit primitively), but the interrupt system correctly capturing the requester station name. While using a generic "Iron Ore Loading" for multiple places works well enough, I want requesters identified a little more uniquely. Like "Who's requesting copper?" Is it red cards? Green cards? Low Density Structures?
Supply stations are disabled if less than one trainload is available
Requester stations are disabled if they hold more than one trainload
Each requester station gets one Decider Combinator. Input is from the chests, also connects to station (so it can know whether to disable or not.) Requester station outputs "Read Train Count (C)", which the Decider Combinator receives along with the chest contents. Output "Send To Train" is disabled (otherwise the train gets a signal for many items and it triggers the interrupt!). The combinator checks "Quantity of item less than one trainload" AND "Train Count (C)" less than one. When both conditions are true, it outputs an "Item 1" signal to the network (which denotes "Send 1 train load of this item"). When a train is incoming, the Train Count should = 1, which tells the combinator that the call has been answered and to turn off the outgoing signal.
Each provider station gets one decider combinator and one arithmetic combinator (it's sole purpose is to invert an output of one to -1). This decider checks the network for the incoming item request signal (Item More Than 0) and (on a separate wire so as to avoid "contaminating" the input signal with the station "Quantity Available") Train Count More Than 0. It basically checks "I see a request, AND train incoming to answer the request", output Item -1 (to cancel out the "I need 1 train load of this item" which is still on the network from the requester station.) But since the decider combinator can't output a negative 1, it goes through an arithmetic combinator for that, which outputs back onto the network.
The train(s) wait at depots where they idle with a wait condition of 3 seconds, the idea being that it will be exceedingly rare that any 2 trains will check the interrupts at the exact same game tick, and only one will answer a request, thus triggering the provider station (with the Train Count) to cancel out the requester's call for goods.
My current issue now involves not so much the system working (if a bit primitively), but the interrupt system correctly capturing the requester station name. While using a generic "Iron Ore Loading" for multiple places works well enough, I want requesters identified a little more uniquely. Like "Who's requesting copper?" Is it red cards? Green cards? Low Density Structures?
-
- Manual Inserter
- Posts: 4
- Joined: Mon Oct 28, 2024 9:52 pm
- Contact:
Re: Not understanding interrupts for Train servicing stations
Quick follow up. Having watched the system for a load of plastic, I observed the network signal quickly flickering from "Plastic 1" to [Nothing} at what appeared to be every game tick. I am guessing that one (or both) of the associated stations are doing updates and checks as their inventory counts change. Naturally, with multiple trains this will lead to multiple fulfillment attempts so I need to correct this somehow.
-
- Manual Inserter
- Posts: 4
- Joined: Mon Oct 28, 2024 9:52 pm
- Contact:
Re: Not understanding interrupts for Train servicing stations
A bit more watching and I have realized the loading station Decider and Arithmetic combinators are evaluating the input (call of +1 on the network) and its output (Reply of -1 on the network) together. It's currently set up to evaluate "call for product" and "Train Count > 0", and it's output keeps it flip-flopping between TRUE and FALSE. I either need to set up a latch of some sort or re-figure my logic.
My attempted solution was to set up an OR condition using the Stopped Train ID (if >0), which essentially says "There's a train here to fulfill your request", keeping the condition TRUE and keeping the output at -1, cancelling out the request signal.
My attempted solution was to set up an OR condition using the Stopped Train ID (if >0), which essentially says "There's a train here to fulfill your request", keeping the condition TRUE and keeping the output at -1, cancelling out the request signal.