Hi guys,
have you found good generic train schedule setup? I have tested one, while it works i am pretty sure there are better setups. Mine setup is like this:
* all input stations (which provide stuff) are named Input
* all drop stations (which requests stuff) are named <Icon> Output
* I have depot section which has a stop for every train have. All depot stations are named Depot
* I have refueling stations all named Refuel
now schedule on trains. All trains will have same generic schedule:
* One and only item in schedule is Go to depot
now Schedule interrupts:
* If no cargo and is stationed in Depot - go to input. It will go to any available input train station and load cargo.
* If has cargo go to <Icon> Output. This uses this parameter variable to set icon based on cargo train has
* If you have no fuel - goto fueling station
* Now interrupt which can happen during interrupt: If no path available and destination is full - got to depot and wait 5 sec
this works but not ideal. trains are going to inputs and unload at output. seems fine. But sometimes they go to inputs and fullly load even if no drop stations require this input. So loaded trains wait in stations or depots. Which is an issue.
so what are your good generic setups?
2.0 train schedule setup
-
CarbonPhosphate
- Manual Inserter
- Posts: 2
- Joined: Tue Oct 22, 2024 12:23 am
- Contact:
Re: 2.0 train schedule setup
So far I have the same, but I've been trying a couple of things to try and stop full trains waiting in the depot:
- Trains with items can't go back to the depot, and will sit in the pickup stations
- Depots are set to low priority, so the full trains at pickups will move first
This works, but to be perfect I don't want full trains waiting at all, so I've tried some circuit stuff:
So far, the dropoff stations send a signal with an item to the circuit network when they want items, and the provider stations have limit=0 if there aren't any dropoffs requesting items
It's not perfect though - if there are multiple pickups, all trains waiting at depots run as soon as any dropoff requests something, and I haven't been able to find an elegant solution to send only one train as they all pathfind in exactly the same tick. I'm thinking I might run a counter to the depot stations so only only one depot station gets the "check" signal to send the train at a time, but it feels really awkward to set up giving each depot its own number. Any ideas?
- Trains with items can't go back to the depot, and will sit in the pickup stations
- Depots are set to low priority, so the full trains at pickups will move first
This works, but to be perfect I don't want full trains waiting at all, so I've tried some circuit stuff:
So far, the dropoff stations send a signal with an item to the circuit network when they want items, and the provider stations have limit=0 if there aren't any dropoffs requesting items
It's not perfect though - if there are multiple pickups, all trains waiting at depots run as soon as any dropoff requests something, and I haven't been able to find an elegant solution to send only one train as they all pathfind in exactly the same tick. I'm thinking I might run a counter to the depot stations so only only one depot station gets the "check" signal to send the train at a time, but it feels really awkward to set up giving each depot its own number. Any ideas?
Re: 2.0 train schedule setup
I was thinking about having global logistic network too for trains and try to calculate needed trains. But my bases usually are huge and when i start to think about size of logistical network I would have in this case - well i do not think this would end well.
I was wondering maybe it would be possible somehow to do purely with train scheduling without global train logistical network.
I was wondering maybe it would be possible somehow to do purely with train scheduling without global train logistical network.
Re: 2.0 train schedule setup
I feel like I'm close to having this one figured out, but can't nail the last bit.
Setup:
* Providers:
* Train limit: 1
* Label with "<icon> Provider - Fluid
* Use circuits to determine when provider has at least 1 full train of fluid (using 2 cars, 100k fluid)
* Here, we just connect all tanks to a arithmetic combinator, and divide by 100k
* Use this signal to set the train stop to active IF any > 0
Using this setup, a provider only comes online once it has at least one train of fluid
* Requesters
* Train limit: 1
* Label with "<icon> Requester - Fluid
* Create a constant combinator with request amount (e.g. -150k water, etc)
* Connect to all tanks
* Route through arithmetic combinator, divide by 100k -> output will be -N, where N is number of trains needed to fill station
* Use signal to set train stop to active if ANY < 0
Again, the requester will only come online if it requires at least one train of fluid
* Depot
* Name: "Depot - Fluid"
* Send signal to train
* Constant combinator with -1 for all items we want to service, attached to each depot
Train schedule (see screenshot for full details)
* We use the circuit signal to select an item (it'll just iterate through all the items on the line)
* Check if <icon> - Provider Fluid AND <icon> - Requester Fluid" is NOT full
* Dispatch train to go to provider, get full load, then go to requester.
This works _perfectly_ in the simple case of one requester and one provider _per item_. I have tested it with two different fluids on the same network
However, it breaks down as soon as we have more than one provider.
Specifically, when:
* Two providers are online (have >1 train of fluid)
* One requester comes online
In this case, the conditions for the interrupt are satisfied for _two trains in the depot_. Even though the first train gets scheduled, routing to one provider and the requester, the provider doesn't get marked as "full" until the train is actually on the way to that station!
Two trains will get dispatched, one to each provider. The first one will fill and head to the requester, while the 2nd will sit and wait at the provider until the requester needs another train.
I'm not sure there is _any_ fix for this issue with the current circuits/inturrupts. There's no way that I can see to mark the destination requester as "full" until a train has that stop as the _next_ stop, not just in the schedule.
Note: There is a similar race condition that exists with one provider/requester, where the provider has _more than one_ train load in storage (doesn't occur in this blueprint, but would if the fluid capacity was >200k for a provider).
In this case, a train will be dispatched to the provider -> requester.
As soon as the first train leaves the provider, and is on the way to the requester, a 2nd train will be dispatched.
(I'm currently debugging using fluids).
Here's a blueprint string I'm using to test with. Fill the providers with fluid, and turn on the combinator at the depots, and it'll start running. The "requester" combinator on the lower requester is off (to demonstrate the above issue).
Setup:
* Providers:
* Train limit: 1
* Label with "<icon> Provider - Fluid
* Use circuits to determine when provider has at least 1 full train of fluid (using 2 cars, 100k fluid)
* Here, we just connect all tanks to a arithmetic combinator, and divide by 100k
* Use this signal to set the train stop to active IF any > 0
Using this setup, a provider only comes online once it has at least one train of fluid
* Requesters
* Train limit: 1
* Label with "<icon> Requester - Fluid
* Create a constant combinator with request amount (e.g. -150k water, etc)
* Connect to all tanks
* Route through arithmetic combinator, divide by 100k -> output will be -N, where N is number of trains needed to fill station
* Use signal to set train stop to active if ANY < 0
Again, the requester will only come online if it requires at least one train of fluid
* Depot
* Name: "Depot - Fluid"
* Send signal to train
* Constant combinator with -1 for all items we want to service, attached to each depot
Train schedule (see screenshot for full details)
* We use the circuit signal to select an item (it'll just iterate through all the items on the line)
* Check if <icon> - Provider Fluid AND <icon> - Requester Fluid" is NOT full
* Dispatch train to go to provider, get full load, then go to requester.
This works _perfectly_ in the simple case of one requester and one provider _per item_. I have tested it with two different fluids on the same network
However, it breaks down as soon as we have more than one provider.
Specifically, when:
* Two providers are online (have >1 train of fluid)
* One requester comes online
In this case, the conditions for the interrupt are satisfied for _two trains in the depot_. Even though the first train gets scheduled, routing to one provider and the requester, the provider doesn't get marked as "full" until the train is actually on the way to that station!
Two trains will get dispatched, one to each provider. The first one will fill and head to the requester, while the 2nd will sit and wait at the provider until the requester needs another train.
I'm not sure there is _any_ fix for this issue with the current circuits/inturrupts. There's no way that I can see to mark the destination requester as "full" until a train has that stop as the _next_ stop, not just in the schedule.
Note: There is a similar race condition that exists with one provider/requester, where the provider has _more than one_ train load in storage (doesn't occur in this blueprint, but would if the fluid capacity was >200k for a provider).
In this case, a train will be dispatched to the provider -> requester.
As soon as the first train leaves the provider, and is on the way to the requester, a 2nd train will be dispatched.
(I'm currently debugging using fluids).
Here's a blueprint string I'm using to test with. Fill the providers with fluid, and turn on the combinator at the depots, and it'll start running. The "requester" combinator on the lower requester is off (to demonstrate the above issue).
- Attachments
-
- 10-23-2024, 12-51-52.png (198.8 KiB) Viewed 3961 times
Last edited by cylarc on Wed Oct 23, 2024 5:51 pm, edited 1 time in total.
Re: 2.0 train schedule setup
heres my attempt but its buggy.
EDIT: And yes, you can do it easier by calling all the requesters the same name but I find it confusing since I often play with outposts style instead of a bus.
- It does not check if there is a supplier. so if there is a request for iron ore and the train will just sit there, searching for iron ore forever completely ignoring the requests for copper ore which can be easily fulfilled since the copper mine storage is full.
- It does not check how many train are needed to supply it. if there is a demand for 1 load of copper it can and will send all trains to get that 1 load.
you can connect wires direct to radar dishes. they all share one global logistic network and it will save you some effort having to run wires throughout the baseSopenas wrote: ↑Tue Oct 22, 2024 4:23 amI was thinking about having global logistic network too for trains and try to calculate needed trains. But my bases usually are huge and when i start to think about size of logistical network I would have in this case - well i do not think this would end well.
I was wondering maybe it would be possible somehow to do purely with train scheduling without global train logistical network.
EDIT: And yes, you can do it easier by calling all the requesters the same name but I find it confusing since I often play with outposts style instead of a bus.
Last edited by Gamma_Rad on Thu Oct 24, 2024 8:56 pm, edited 1 time in total.
-
CarbonPhosphate
- Manual Inserter
- Posts: 2
- Joined: Tue Oct 22, 2024 12:23 am
- Contact:
Re: 2.0 train schedule setup
it's not pretty, but I've figured out a solution to thisSpecifically, when:
* Two providers are online (have >1 train of fluid)
* One requester comes online
In this case, the conditions for the interrupt are satisfied for _two trains in the depot_. Even though the first train gets scheduled, routing to one provider and the requester, the provider doesn't get marked as "full" until the train is actually on the way to that station!
Two trains will get dispatched, one to each provider. The first one will fill and head to the requester, while the 2nd will sit and wait at the provider until the requester needs another train.
I've got a timer counting from 1-60, one number every two ticks (has to be two because one is too short) and each depot station only releases its train while the time is the correct number. It's not the most scalable, but it's at most a 1-second extra delay for every thirty trains you have so it's not too bad.
Basically each depot is given the check signal when its unique number is on the timer, and trains only leave depots when they get that signal. Stops two trains responding to the same request.
It's actually not that bad to give each depot a unique number with the new blueprint parameter formulae
-
BiergitKraft
- Manual Inserter
- Posts: 1
- Joined: Sun Oct 27, 2024 5:10 pm
- Contact:
Re: 2.0 train schedule setup
I wanted to deliver multiple items to one train stop on demand.
I solved this by assigning each train stop an individual bit for each item that should be delivered to that stop. All stops are connected to the same logical network. For example a stop needs crude oil and water, I assign it i.e. bit 0 for water and bit 3 for oil. So if the amount of water drops below the threshold, the combinator sends (1<<0) aka 1 Water to the network. If oil is missing, (1 << 3) aka 4 crude Oil is send to the network. The bit chosen is also defining the priority as we will see later.
Other train stops that need oil or water might add a 1 to their assigned bit and all adds up on the logical network.
The Train only has one stop (I didn't add depots so far) to load water or oil or whatever, the rest is made by interrupts. Since we cant use AND in the interrupt conditions to properly mask a single bit, I use a >= comparison to solve this. Additionally we need a condition to make sure the train doesn't run empty. If water >= (1 << 0) and we have cargo loaded, the train will go to the drop assigned to bit 0. This is why the order of the interrupts of the train is important. When the train unloaded the cargo and the amount of items reached the threshold, the combinator will deassert the corresponding bit.
An example for the water train:
[*] water drops 0 and 2 need water, so bits 0 and 2 are 1. So Water = 0b101 = 5.
[*] First interrupt will trigger since 5 Water >= (1 << 2) aka 4 and the train has cargo.
[*] The train will deliver water to stop 2.
[*] Stop 2 is full, so bit 2 will be deasserted. Water will drop to 0b001 = 1.
[*] Second interrupt will not be triggered because 1 Water >= (1 << 1) aka 2 is false.
[*] Third interrupt will be triggered since 1 Water >= (1 << 0) aka 1 is true.
[*] The train will deliver water to stop 0.
[*] Stop 0 is full, so bit 0 will be deasserted. Water will drop to 0b000 = 0.
[*] No interrupt will trigger and the train will return to the schedule, so it will return to the load stop.
This is why the position of the interrupt is important. The highest bit must be the first interrupt or else all the other interrupts would trigger when a higher bit is set and not on top of the other interrupts to be cleared first. The possibility to use AND to properly de-mask unwanted bits would make this much easier.
As I mentioned, I need to add depots, but I liked some ideas mentioned above.
Pros:
[*] I can send multiple sorts of items on demand to the same stop.
[*] changing the threshold is very simple and can be done by adjusting the decider combinator in front of the bit shift arithmetic combinator.
[*] its quite simple and the train will deliver its cargo until its empty as long as all stops are connected to the network and return to the load stop when empty
[*] easy to expand when you chose your bit positions carefully, see last point at cons.
Cons:
[*] I need to connect all stops from which the train should trigger the interrupt to the network
[*] Every stop needs an interrupt (at least I think so, haven't checked out the wildcard stuff.)
[*] changing priority aka bit position might get messy if you cant go lower because you already assigned all numbers down to zero
I think there is more potential to this approach, I will keep on thinking about it.
I solved this by assigning each train stop an individual bit for each item that should be delivered to that stop. All stops are connected to the same logical network. For example a stop needs crude oil and water, I assign it i.e. bit 0 for water and bit 3 for oil. So if the amount of water drops below the threshold, the combinator sends (1<<0) aka 1 Water to the network. If oil is missing, (1 << 3) aka 4 crude Oil is send to the network. The bit chosen is also defining the priority as we will see later.
Other train stops that need oil or water might add a 1 to their assigned bit and all adds up on the logical network.
The Train only has one stop (I didn't add depots so far) to load water or oil or whatever, the rest is made by interrupts. Since we cant use AND in the interrupt conditions to properly mask a single bit, I use a >= comparison to solve this. Additionally we need a condition to make sure the train doesn't run empty. If water >= (1 << 0) and we have cargo loaded, the train will go to the drop assigned to bit 0. This is why the order of the interrupts of the train is important. When the train unloaded the cargo and the amount of items reached the threshold, the combinator will deassert the corresponding bit.
An example for the water train:
[*] water drops 0 and 2 need water, so bits 0 and 2 are 1. So Water = 0b101 = 5.
[*] First interrupt will trigger since 5 Water >= (1 << 2) aka 4 and the train has cargo.
[*] The train will deliver water to stop 2.
[*] Stop 2 is full, so bit 2 will be deasserted. Water will drop to 0b001 = 1.
[*] Second interrupt will not be triggered because 1 Water >= (1 << 1) aka 2 is false.
[*] Third interrupt will be triggered since 1 Water >= (1 << 0) aka 1 is true.
[*] The train will deliver water to stop 0.
[*] Stop 0 is full, so bit 0 will be deasserted. Water will drop to 0b000 = 0.
[*] No interrupt will trigger and the train will return to the schedule, so it will return to the load stop.
This is why the position of the interrupt is important. The highest bit must be the first interrupt or else all the other interrupts would trigger when a higher bit is set and not on top of the other interrupts to be cleared first. The possibility to use AND to properly de-mask unwanted bits would make this much easier.
As I mentioned, I need to add depots, but I liked some ideas mentioned above.
Pros:
[*] I can send multiple sorts of items on demand to the same stop.
[*] changing the threshold is very simple and can be done by adjusting the decider combinator in front of the bit shift arithmetic combinator.
[*] its quite simple and the train will deliver its cargo until its empty as long as all stops are connected to the network and return to the load stop when empty
[*] easy to expand when you chose your bit positions carefully, see last point at cons.
Cons:
[*] I need to connect all stops from which the train should trigger the interrupt to the network
[*] Every stop needs an interrupt (at least I think so, haven't checked out the wildcard stuff.)
[*] changing priority aka bit position might get messy if you cant go lower because you already assigned all numbers down to zero
I think there is more potential to this approach, I will keep on thinking about it.
-
falconfused
- Manual Inserter
- Posts: 4
- Joined: Sun Oct 27, 2024 8:47 pm
- Contact:
Re: 2.0 train schedule setup
@Cylarc , I seem to have developed the same interrupt schedule setup as you posted on Wednesday, It's so close to working with multiple simultaneous requesters/providers/materials but I have the same problems about scheduling several trains at once (race conditions). I tried the solution proposed by someone about setting a counter that only allows one train at a time to check the conditions. But that solution still wont work, because as @Cylarc says, the station doesn't get marked as "full" until the train is actually on the way.
After investigating and testing, I now understand that there are two different categories of trains that get assigned to stops. Select a train station and observe the tabs at the top "Trains on the way" and "Trains with this stop". From all the ways I've tried to combine the logic, all of the parameters that are available (including and "Read train count-C" and "Enable train limit") seem to be dealing with the "Trains on the way" type. If I could access the number of "Trains with this stop" I could use that as a check when the interrupt is scheduled.
The Reason it's a problem is that "Trains on the way" only gets updated when the train is in directly coming to that station. and that might not happen as the first stop on the interrupt schedule.
If the interrupt could check "Trains with this stop" which gets updated immediately after an interrupt fires (no matter how far down the schedule a stop is), then we could avoid multiple trains being scheduled on a 1-train-limit stop (in which case they just go to sleep until the stop is open again). Even better would be if we could use the "enable/disable" (AKA "train limit") and make it check the number of "Trains with this stop" instead of using "trains on the way".
I'm new to this whole forum and bug-report/feature-request world, so I don't know how to get this elevated. I just want access to that one variable (Like "Read train count - C" is accessible now, which is the number of "trains on the way"). It seems like not a hard fix, and it would allow a requester-based multi-material system. Please add "Trains with this stop - O" as a possible circuit output of stations!
After investigating and testing, I now understand that there are two different categories of trains that get assigned to stops. Select a train station and observe the tabs at the top "Trains on the way" and "Trains with this stop". From all the ways I've tried to combine the logic, all of the parameters that are available (including and "Read train count-C" and "Enable train limit") seem to be dealing with the "Trains on the way" type. If I could access the number of "Trains with this stop" I could use that as a check when the interrupt is scheduled.
The Reason it's a problem is that "Trains on the way" only gets updated when the train is in directly coming to that station. and that might not happen as the first stop on the interrupt schedule.
If the interrupt could check "Trains with this stop" which gets updated immediately after an interrupt fires (no matter how far down the schedule a stop is), then we could avoid multiple trains being scheduled on a 1-train-limit stop (in which case they just go to sleep until the stop is open again). Even better would be if we could use the "enable/disable" (AKA "train limit") and make it check the number of "Trains with this stop" instead of using "trains on the way".
I'm new to this whole forum and bug-report/feature-request world, so I don't know how to get this elevated. I just want access to that one variable (Like "Read train count - C" is accessible now, which is the number of "trains on the way"). It seems like not a hard fix, and it would allow a requester-based multi-material system. Please add "Trains with this stop - O" as a possible circuit output of stations!
- difference between "on the way" and "with this stop"
- 10-27-2024, 15-10-00.png (203.23 KiB) Viewed 1598 times
-
LightThemeIDE
- Manual Inserter
- Posts: 3
- Joined: Mon Oct 28, 2024 5:09 pm
- Contact:
Re: 2.0 train schedule setup
Edit: ignore my ramblings here just see what I said in my next post. 
I found this thread and wanted to share what I have been doing based off of the information provided in this thread so far. I am using radars to carry signals wirelessly across the entire map. Every requester, provider, and depot gets a radar. When a requester needs a resource, it will output a -1 signal of that resource. For my interrupts I followed what @cylarc posted on October 23rd. When a provider station has a train on the way to it, it will output the C signal of 1. I then translate that signal to be a signal of the resource type it is providing. Now back at my depot I have a radar that connects to the first depot stop. When a requester stop asks for a resource it will put out a signal of -1 triggering the interrupt and causing a train to depart. I then have a wire going from my first depot spot to a decider combinator. It checks to see if C = 0 and if so outputs everything with their current input. C cannot equal 0 until after the train has left which means that the provider no has C = 1 which means that the signal of the resource being provided should be 0 preventing any further trains from departing. I am not sure if I am on the right track or not and I need to do a lot more testing but if I get something working I will post a more coherent message
I found this thread and wanted to share what I have been doing based off of the information provided in this thread so far. I am using radars to carry signals wirelessly across the entire map. Every requester, provider, and depot gets a radar. When a requester needs a resource, it will output a -1 signal of that resource. For my interrupts I followed what @cylarc posted on October 23rd. When a provider station has a train on the way to it, it will output the C signal of 1. I then translate that signal to be a signal of the resource type it is providing. Now back at my depot I have a radar that connects to the first depot stop. When a requester stop asks for a resource it will put out a signal of -1 triggering the interrupt and causing a train to depart. I then have a wire going from my first depot spot to a decider combinator. It checks to see if C = 0 and if so outputs everything with their current input. C cannot equal 0 until after the train has left which means that the provider no has C = 1 which means that the signal of the resource being provided should be 0 preventing any further trains from departing. I am not sure if I am on the right track or not and I need to do a lot more testing but if I get something working I will post a more coherent message
Last edited by LightThemeIDE on Tue Oct 29, 2024 4:56 pm, edited 1 time in total.
-
LightThemeIDE
- Manual Inserter
- Posts: 3
- Joined: Mon Oct 28, 2024 5:09 pm
- Contact:
Re: 2.0 train schedule setup
I think I was able to get things working but I am not a big fan of the result. In a nutshell what I did was make it so that the trains in the depot depart one at a time, left to right, and double check the input signal before triggering the interrupt.
The flow is now
* Trains wait at the depot
* Requester uses logic to determine if it needs a resource and if puts a -1 signal of that resource per train needed
* The signal is put onto the global red wire that is transmitted by the radar
* Back at the depot the negative signal will come through and trigger the logic loop
* If it is said train's turn to leave the depot, and, if there is a negative signal on the global red wire, then output a green check mark of 1
* When the green check mark becomes 1 it will start a 180 tick (3 second (it can be lower I just did this for testing)) timer. If at any point during those 180 ticks the green check mark of 1 goes back to 0, then the timer stops. The green check mark has to be 1 for 180 ticks.
* The timer outputs the green check mark of 1 into a decider combinator on the green wire. This decider also takes the global red wire as an input.
* The decider then checks if any signal is less than 1, and, if green check mark is 1. If both are true then it outputs every signal with its original input count on the green wire.
* The decider's output on the green wire then goes to the train stop which passes the signals to the train.
* The train's "Generic Interrupt 2" will trigger when there is a signal with a negative value, and, it is at the depot, and, the provider is not full, and, the requester is not full
* The train will then go to the provider and pickup resources
* At the provider station there is logic that says, output the number of trains that have me as their next stop as the resource I am providing. By doing this we negate the negative number put onto the global red wire by the requester. This is where the race condition happened as the moment the train would leave there would be a race of which update would tick first, the provider taking the positive output off, or, the requester adding the positive output, or, the train depot seeing the negative number now that the provider was not negating it. This is where that timer of 180 ticks comes in as it ensures all three of those events are propagated to the global red wire.
* Once the train is filled up with the resource it will head to the requester. The requester has the same logic of, output the number of trains that have me as their next stop as the resource I am requesting, so that the global red wire knows how many requests are still in need of fulfillment.
* After the resources are dropped off the train heads back to the depot.
I really hope there is some nerd out there that is going to 200iq this and make it all work with simple magic. I feel like I vastly over complicated this. I think maybe having the trains wait at the stacker of the provider will potentially be more of a simple solution. I am using a depot because I am use to it being that way from my time with LTN. Regardless, wanted to share my success in the hopes it helps
The flow is now
* Trains wait at the depot
* Requester uses logic to determine if it needs a resource and if puts a -1 signal of that resource per train needed
* The signal is put onto the global red wire that is transmitted by the radar
* Back at the depot the negative signal will come through and trigger the logic loop
* If it is said train's turn to leave the depot, and, if there is a negative signal on the global red wire, then output a green check mark of 1
* When the green check mark becomes 1 it will start a 180 tick (3 second (it can be lower I just did this for testing)) timer. If at any point during those 180 ticks the green check mark of 1 goes back to 0, then the timer stops. The green check mark has to be 1 for 180 ticks.
* The timer outputs the green check mark of 1 into a decider combinator on the green wire. This decider also takes the global red wire as an input.
* The decider then checks if any signal is less than 1, and, if green check mark is 1. If both are true then it outputs every signal with its original input count on the green wire.
* The decider's output on the green wire then goes to the train stop which passes the signals to the train.
* The train's "Generic Interrupt 2" will trigger when there is a signal with a negative value, and, it is at the depot, and, the provider is not full, and, the requester is not full
* The train will then go to the provider and pickup resources
* At the provider station there is logic that says, output the number of trains that have me as their next stop as the resource I am providing. By doing this we negate the negative number put onto the global red wire by the requester. This is where the race condition happened as the moment the train would leave there would be a race of which update would tick first, the provider taking the positive output off, or, the requester adding the positive output, or, the train depot seeing the negative number now that the provider was not negating it. This is where that timer of 180 ticks comes in as it ensures all three of those events are propagated to the global red wire.
* Once the train is filled up with the resource it will head to the requester. The requester has the same logic of, output the number of trains that have me as their next stop as the resource I am requesting, so that the global red wire knows how many requests are still in need of fulfillment.
* After the resources are dropped off the train heads back to the depot.
I really hope there is some nerd out there that is going to 200iq this and make it all work with simple magic. I feel like I vastly over complicated this. I think maybe having the trains wait at the stacker of the provider will potentially be more of a simple solution. I am using a depot because I am use to it being that way from my time with LTN. Regardless, wanted to share my success in the hopes it helps
Code: Select all
0eNrtXetu4ziWfhXDPxdOrXgXC90LTM8MFrOYxSxm6l8jCBRbSYx2rLQtp6bQqAfY99h9sX2SJamLlYS0zqdUpS6d/tEVWtLHw3Ph5ZxD8rf55eZQ3u3W23r+9rf5qtwvd+u7el1t52/n73bFerufvS/W9Wy9ndU35WxV3lX1m9lfrmbF7IzN9uvrbbGZLavbcj8rlrtqvw+vXW+qS/f7rlzN3q93pf9t674Qs325rLarWb2+LXezX9bLX/az6urqzexv22XpYe42ZV26N/1ba0+GQ3m/3mxml+7xTbn8xSHWlYMpZ+uHNOxr/1r5z/W+dqS4OtzzfTVzpN8V+70nzz2urgJ5zSd7j+SLtW/nm1nbXNfEYle7Kn49lNt67T77MNuUV7V/e7e+vnHNf+c+Cj/dVvu6+byhstqGl4v7sqmnLnwbPCmehQ1vwjvNN0U9ZOq7G/fGprpeL2fbslw5imebdV1vytnhbuWAttfu7epwffNmNl/M145F+/nbn3+bN63x4qs/3JVObvfrXX1wvyzm2+LW/9C8cVZsP9Q3Dmb+0X2+XZX/nL9lHxdDgPb9TeVEUdXr+3LwKv94vph7jtTrsqk4FD5cbA+3l+XOYfX1LQ+7+3J15troKnVk3FX7daNTv80d0hmXejH/4P4Q1uGvnIYsm8eMe3oe4XIAl8dxdQRWRGEvY7CKtbCGQK6k4woTx42RqwByVQsrHsLGqNVHJfE66dQ7AEeplS2sHKfWALCdzPg4bA7AZi1sNg5r6RqmWpHxfJy3LKOTy/M4boxcdrS0XbEqdhE8ZtibVgu4fqM+xlA4QJ3usAjUiQncfKRSeQxXAvTKOG6U3qNlXa6vz8qNe3m3Xp7dVZsyxlmre+wYmsbQDDuJZjA0eZq2HEPjp2mzENpptnHEVNoOgxM6DD4wleqyuqt29UkpuPFwvvMj/76+uFpv6nK39y/tmzqaYa8fOs+jLeGkGvknrFHgQwOz4wbHgZHMK0MMl8kYsBr0Xw6xnX9Eba3rxVjuerEH0FHko/WFGdbZvq7uosAJPvhOsZ21OYyf3/35H+9m/Hz29/LqUG7msRoNtS0GbUtOReYCRLZ0Y/O9eUA247gio/f8TMZxowojGEAwAwgGhsDMArgCwDUALjAEZgrAVQAuohDA7DJD5EafXjKLyC0HcBG5WQAXkJvMAFxAbpIBuIDcJN3eWA7ITQoAF5CblAAuIjcF4CJy0wAuIjfA3gwiN8DeDCI3wN4MIDcF2JsB5KYAezOA3BRgbxqQmwLsTQNyU4C9aURugL1pRG6AvWlEboC9KURugL0pRG6AvSlAbhqwNwXITQP2pgC5acDeJCA3DdibBOSmAXuTiNwAe5OI3AB7k4jcAHsTiNwAexOI3AB7E4DcDGBvApCbAexNAHIzgL1xQG4GsDcOyM0A9sYRuQH2xhG5afKCnnVeOUaIZRjA3jiiDzlAbwbQC9gbA/QsB+yNAXqWA/bGAD3LAXtDHEc5PWTAGKBnOWBviN8oB+wN8RvlwPiG+I1ywN4Qv1EOjG+I3ygH7A3xG1m6g9LmdDWzjOiptap31JrHjloVA+Z4jJopgkPVHg3utlytD7eEsJfsaVfxgKIdWltZbs6WN+W+jvuieiyZwBoE5Q6bX87W2325q8vdCJp6zNVYXMNqMlePva4iqMHRym6KzdXZal1c+wSW8a6XAp7Tic4Qoi0Zt/cgEmBZluHZIEwQVDcYPNWp3C8uxHjnwDIgGtCvLkjAQDigX16QgIF4QL++IAEruvREQnpxtUDyTRRCMZJxAmkFknMCaQWQddIls5B4DKWdIOrGAMvjiLoxIMWrS+2gsQKYWJpULxRN7QGyUY6uYBIv1ARfMAkYWMyZDOKFmeBmJpGcT/Azk4DtBEczBZjThz2mJcJkzib4sEkkc4BkDhgfFxO84ySK5QT3OAlYTfCPk4AB21PIeMrNBM87ieJ8guudBGwBViDDXiL75PLkYp8ETF3euTlWvxJhj1cicasWwAqvn10wCtFAUljvaiQBT8kKIwHTM5yPwWtGYrIm52idEiCLYhs61UZBVJPzv465vmSq6au+44hNonqQkjJCtT7yOqNRLRmd6r57pqie5AAwYoWSboXHABsJWAKdneiBo1CA3WUjUHTPSm5PI1HTKrlPeWygnuQ+xv0Hw6STw2WX7BmLELTzMxun0OIOmTiSyoCuukUycSTySHVMGTU0rilgoOpCNgkigZGp85AlkAAjyHuk8W0bCrCILt2JhAs4Hrs1IwkXGIOUOMlRwMsoT6siYB7ypL7ojKzU/YjyxA/MVBSaai+ObSg0p0JLmGpBhmYotAQCca3UdFxqdA9iH8JJINHXTl1uZwJoYCbV1nX82/psWd1errdFXcUjC7zfRPUksLDwIPWu2lxcljfF/dohPNi2kdjCsZj3mzwe/NoSVqzui+3StXG53i0Pax89+fVQbFw73MNttbsNgvYbZYtdoPrt/Mfww8Fv4D3zO0TO/ZbN/YUn8qrY7Ms4L/LxLWRMDlsfRRm4URxlm/EoEuNjmEgOSqeCIo5Etu7MpuUcReZouzMz2m7AVdnFaBN7xiRM3bhUyFt2MgHyUuOx3oS8qXNGi4o7Bxlq81F+opZj2RgkkEzS9ZNxPuZUu8kVxscccfN3yHESgT2mnRMigSQBJHESSaFmd5QpS8kU8Bt2QuWEGWNO3rV2lHFGkzGQgtV5cUgUW7I3xGIUA0khvQeHQjE5K8R1/SDFgMdesVM6a4FBR560SAvMHMVJi7RqQtJWHIm6G7TP0foYn9W1k7GLcltcbsrV/G29O5SL/uf+sBL/7tV6t68vJp3J0c1K52+zR3O8H/zj0IYL34a7ckWv4d087DAuVhcBYH/RThabNgx/o2P+ce4YPtwou67L2x+bDq/aui6vZc357Gz292Zzc7lzf/MwV900XHX/y95Yaf1/eZ4ZmxmWSWm5656cDlwHNlyG/xfhpJL5bbF11HTt2Kxv3QT5bdRVaKdkvMWVKKcqkXhVok+gRI9XQF9OhaYkIcbPNshoKmRfu6HvSYM4kKnW70qNKxCnKVC/B/W7VaB9WT/i/AP9Cb/RIf/6Ajp5VVWXwb8S1ZssKm4gX7BdJyX0BsgPbJdJCSAFnxiRANLjfqd+WZTFV0UcyPXrVkUJaqhje95x+bRdPTCgtBX8+Dwr+Bg9ouRP/hC56Akl2WNfw6a4jbeyW4cklqN8mFl4MnTWblrP4igM3qUeFx8jdotdkCYlvpcTxSAf8bQo+kSEpCgkvMU9wURFZaL4WpioqUxkY0w0RH1uEy0T+pzDu4kTorDwdtw4EM/g/awJIAavxRNAHF6PJYAEPCtPAEkwGtR7jSOpXV9nMMivO26Lf3azGsndPFcbZnWIEsW5otApa4K7Gp7CiDiQgacwCaAcnsIkgI5WuiqX61W5G4siNmrIqWrToh5nE/t2OtGXfoan59e7stw+nJvzyKzkObgPoc4X8+pQ3x1q8IzaAeDdh3bufbWrbi/WWwfWhTQT2jtIAYVEI56cmvZykjkunJ7H/k6sLNoj+B/Kixat2K6mCyicwjxZQAyNkeRdr5sIe/FhBi0tqt9Dis8d1B9h5R+wDj34GLrDmEfBf0LBk2OCwE/Xivecg9Th1Xp/tyk+nN0V2/J03KnpNmNi8e24LXu2P8d7MVDqk4s2f+g23Sw9Dz4zVT8AVO1KZ/ZNegjwwWJebN4XH/YX+5vqfeMaicoWjn7mfGCGUUgN9ua5jJv1Fx5o2dcyOhp43Z2w45xux8a+2vE3Zcfo7Nbkr0Z3wuiGR3TS+sX+nOBUv4iczmlOra0G2x7G7Vi82vG3ZMfIkajqVGcv8TPiEkAKdkolgDQ642cPJ5OfP433aSbEC/huBntmit26vnG26Os/zZkux5cnjPqI9KjHfmw76ZaHsJ3/+GLQPfv2VXflrvP7/uu8651pmAkW5ODoxcRI+z/zkn/qmFTel7sjSIIZdoI+8E+lD+Nh0phaPFSKf/kkSqHwjPJ4xzPYXkXseDL7wh3PF3AZD3aGkdUsyz9xt/Ok3c/udJ4iJpovwC6n3wrwHXY5gx15dF3Q30qXQ1YJBQe7Eh0OvjciAYRPDdpkNE50jX9DBgvOEWz+NcUIPqv1WjT4F9e24Y7N9BVI3aFW6vkXIA32cVKuoup2UceX15rDocsEkIBDlwkgCYcuE0CKdDdVa/ryEwhGT7pbLX5F2GD/JjW690b1KjY+9/oclvvTI69U/thh8G9fKBKn0ZWSzb44M//wJND8DO79lO4H9YSFUx9UpLHnU81pymJ5Mxg6cd0ZnfuQCIjzcbCVd3CjbDpqKN9kmbCZ5p6HTY7yhb8Pd+/YtL94f7N25dvq3o9hjXI7cndrV2vbgOxZed0+d7zt1FaDacWyKjbz42Pf5TkDu3e1VrsPbR/Yl1hIZXOcbWhp1lCZ17PzKIMYHFmNd+yGw/v5JHFF2ue2bqp92etFy/7uYcih7p4Fl2SUSgGH6jlI7e88VD/Y+g2FTOVrAszLDLuDffQjXSL7nrtEle4S8SvMEl2igTcMf4kuMZ8Wbn012JcyWIuOWX389nXMIo1ZOXWWaNR33CUKnewSczzeH+8Scw6fSPAFusQcj1wnmotHrhNAeOQ6AaTh85KG0/UopIGDWwmgHD41KB+jzcJ+8DiQhZNoMjFCm2Wwaz0BhIe/rIHG8G8u/mEF6kdOsFbCnlgTB1KwJzYBpGFPbALITNupYL7VeV8kd+pzz/soIQ+bT96QoFM9i4WdOlEdEVkGL+Y70l793U+YyWAPmX7xuY/I+OQsehNXRzE4TIDuzOaQIv0enNkig11r4otb4wsFTESmYKdNosvTsDvktctLSgX3gH2JLg/2gJnfj13ZyZsHUsPB4AgP8nDQg74OB0c+4k6ZeJfHcKeMppwSKRjuR0lQiPtREkC4HyUBdBwmrop9febAtnufzXJ2WW6iKS1saBcE3hm4ApWqIHpPihgcGkKtQYI1UI/96XO+EysaMThOhEqrwGgdnDMyet0r4ylsGYXmsIMsrnScenZPn9Ca5KeE/WIJkhSVpFER45mmCZIM6vtJ4OSw78fGgSzs+4kDiQz2/SSA4G0Efe5VTnT/fK6QUjO0TrmTIM4JDrtKEizFM0u6Hsp+ZyydmAGSvzoWP6VjUQh8SZxQbT0tQ+BVoJ9YoPDtMf1C9XvrYnJ46ZNQbUs8fk9nJ1BkBq9zEkAMXuckgDixXfLUNAHZwS1OTVyGO7hPX3h3slFq8porJ625Btu6x9cAemBaUTA8LJ5oNvW2wOykCPBIeBwI2cuanWrXYC/ryXbZk9RwdLKfwJlw4DGLI0048TiBNOHI4wTS4LyCYnddnb0vrhPH5poOZ2pm0yDLaHvYbKLkTDg9OdGwnNww9hINs/i5wvGGDTawjTTMqBdomMZ9jamGcfyo2gSSoPfWsj85NSPOhJ5zUH1L1fuqWj2aRWaPIzP/99//E44f/hxnefjJ6GFfHnfOJU5qEQ9295VlmK7towOqzId8jGI9GqQPrjG7652b062Sw7TUSemwYx5oM6+eRysFBu7+ssuIKkSxDX4kckJh8wms4c9ljZ1QqaBU2gQAY3U+uEDxtD71zUsckC0M4Jc90s2+QSufdHAG2cYH+7PG+cjSfIxiiwk6liXroCm2kfgJ43G7NPC6QpzqsKJV6OlVMGIVBheCMBQhnDD0/Dl1TuxcLMxKCUorz6ZXQZTWIKOeWoVCW8GnV0FthYCrEGgVEq6Co1Wo6a2gykJPbwW1CjhgLBjKKDhiLDK0Cju9FURG2Wx6K6hVwNbNLcgoC1s3z9EqxPRWUBklp7eCWgVs3dygjIKtm6OjuzXTq6AyKp/OKGoVsHVzcEiSGWzdXKJVsOmtyIhV8OmtoFaBW7dAGYVbN0erUNNbQWWUnt4KahW4dTOUUbh1Z2gVdnoriIxi2fRWUKuArZuBY7dksHWzHK1CTG8FlVFyeiuoVSggIPdoMHrh20dJOQPRaLZkekorX8LF9RnbbKguQqZHXITywe13RKwshWUBWSjITSYnJLGiUxPOpleRUWLkkvPJmbhPGxGvQUyvgdivcIn7rRh/nsNScvWcSrOJlWr8+sSol1QO02qJO+DtmLXxCf7D7Hk+S8knBEQy/UzZi+w5DZ3kKJUCiJxkGgqKSTHhMs24Wgkx+WCFpFqJCeadieeplQCmKhnHBg6Bp8anuA3nxqeA8OR4JuJIeHZ8Akni6fEpJPxUxBQSxzNCEkgCT8FIIEk8BSOBpPDYeAJJ49G8BJKhG+IxFsVfA8aP+UieVR9DlYkbMqV8RsyO06Z0g7TEcbGrtNij2Gx69IZKPp8eg6JWIaaHVqhVyOmhFWoVanpQglqFnh6UoFZhpvvaqVXk0yMG1Cqe4c4nVqGf4c6nVsGmu5CpVfDpLmRqFWK6Z5RahZzu36VWoab7FKlV6OmeUWoVZopDj3/TDj09wQmXmi7oSU442lhunuGEI4rfsOkOLGoV+JbyxHTZiOlunZT8DL67PEWdwle+CSQNr3wTQAZf+SbYlOMr3wSSxVe+caQ8w1e+CSSGr3wTSBxf+SaQ8ANJUkj4iSQpJPxIkhQSfitp3xV/6ZOiJ2wQbfaHLubr/YUnuDmIKsoXfCdeisM53rElkCzescWRbAZ3bAkghndsJo7E8Y4tgSTwji2BJPGOLYGE76tPIWm8Y0sgoYe5qo5Zn/XS9JM38p72f/3vlzmyTtocHyISMkHvsZfmBWUSu/3wq5SIyjJ8qDVxJIZKhL1KJMZHjk9ZEhIR+NCcQJL4gJpAUvg4aONIGh8HE0gGHwcTSDk+DiaQJmx2jiOxDB8HE0iMeByZ6t0GeXwRq9iES6VVRxy1v/j27jJXTEycatjP2olSGPSpzkv9Y/KMHsUmxFYTqkw9We+4tz2pyhpXZWm/VVUm3hGhmJk4P/t9KHKOz7oSikw9BfS4fTulyHzC0cFSfO+KzKdOa38XiswnTFbjiswnTFYTSMdRYnnY3TsRh4OXi1N+pPyRqLIo8AR/eYJETSaxmybSKDz2up7A7dm+ru5O3JDO2RO/ZHdU1Nv5u5vqttjP/nrwR+/FKsOz1DiLs8NSyWbjZP9nsavX29lPh11dbaOEQye92lOED7JATxPO1Djh/3HYbj9wLkScaA4vUlJEC3iRkkKS8CIlhaTgRUoKSdNE0s2cIyL5KuPCi6Y5F745dyVwXP47/224qyEA7C9aD3/TgOFv0PDycai6P/t7EX98usw5n53N/mtX3fvxzf3JHdBtsXWIHS2b9e26u5vyiSQNPNtP6URO1AlpvjGdCHINrqXQsAdS/ZpV5fHsK6Ioz7jEE9AxC0/EEzo2yI8e0TH2qmNfi47RFQVJWhcn5wwSzy5JIQn4zjPOKbvE1CCJnXq1EBVZwdehUJH1AHlV7E46Jn2SYZyn8EYs9YDOKGZObbPio1jwlUH9kXxJzEF29wh9/VmCaSwG08dGMclX6PTnnqWxjjZzU2yuzlZrf/Sn60OSC7l2SiAeqiCPgiMrz9a0OWVdN8jLHgJfxtaLNkpvApe+Du2XcJJgi4MM7FHcboVFws0BXAHgWrrguiWRpDB4eNLsKDBDgBkd2CgEmNOBFaOzeJBCPYorAVXTgM0JQNW0ouMySHKa2JvxPp+fP7kRjKkoNPVGQN5nXZOhczK0QKEHCcnr6/EBwyf2BPhoBz9IQSahGXYSjWFXGPB41NuQbwzgJ2EE1jZ+um3kSR7LkiK1UWT6cNWdq+9aTLAdQ7Wd4+X13NBINgDJAiE5JwPbOK6MwloyLOctriV0e3lGx2UGwGUALgNwOV1u3dTIUuSWCwBYIMCSDmwMAjxYWlWXld8TcarDs2Ed/uuh3NfH/aqJvGMf/onVqOlNkRYQKmCMElFuui0ygSi3JXGefzrOW7qZMoZopyXfo96f6cCfRjrj0Bxbetm4BKLdoUWih80YKzLCig5JbM40gKvQZWijO4JRmEEdJW03CxRPj+WIesGsAXrxxuDF44VonOQcABYIMDBOtkt9ErDOAAu0cYrjuAwYdwyAiwyUDMAFxsl2XUdkMHl6Kno1Fk/UWEShgfmpsAjNwIAoBAJMvuu9P7mAzAxgUGSIwlkAV9FxWQYvLmi4DO2SEaI54LhqbuwUiqIYDNnDw6LAcVzgoq2OyyRculuFZznCCCAdvOvoSQQDyeGdRpBwgeyZdsFJw7UAgznAYA5kzWSApnEgsmYBTeOAI9PmAC4w1bSAoiG3hltA0ZCsNQsoGnL4oUX0wQBy4wAusjcD0TMkdqDpuAIIHcgMMGSBhLIBBUaOLRSAAgsgciCQsRNJXxOAZSDJbAKwDOSkQg5osAAsjiNjMnKTMEc0Dcja4YCmIVcNc0AhkOQRDiiEBIY4DnSVErA4ngG4gMExQIGRkxIZoGfIuYkM0TPA4BKrgTguYG8M0V9giGOAPtATT46eKk06w0crsh+zP6YyCn2+mO+XN+XqsCkbx+ymWla3Vb2+D2VusgU3asHzbPBmyFosl9Vu1e60OGamvfvzP97N+PnsT+VdVYctGf7o3Dv36N/LbblbL2fvQpKdvzi2Lne7w127W6NtTPfWX7qnba7kg80iTQ5fedGmzRXb1bw/I+R4nOVzcgfbf3ym4G3pD496kEb4eDP1D/PgxD5FVuEq78OiaX6NoOzvyuX6ar28WJX72m/RcSgX26q+uDpsNg+B25a1Lfkx0a4nOYNfhIK/N8GCjgSnNHWxuy7rJ9o1sVGL+ftimEw6rkWuZc5G7v1hMu639fKXvd+ikvkjY377FG3EKSpv7xwx/tQabzp717aL3oK6HfeL3ozeuapclVeHcoMakP/mwieYtlmqxfbDmDH15wa54qNzByKWkhZvZwwN4ROYFGgPmniaUeeBin1dLX/x8NthZCr86qPUPuu68H8KpRuxtw/U8UE+fJAfv9DZ4EG4Qf1qV3mOONgHT/LBEzV84hMuuide8RwzXMftSfzZDcVqwfRCnS+av92ytv+b6/aB9i+Z5m/j/86bv3P/tx38LdsH2iyYe8v9Ekq5L2nblqwvGT4ocfedGJRsU/LvuDdl82YocSUGz7iSbUmGN/P2zVCfsYMSV20NTckthkPJU7jgmW7etHrBAy1yULILHkq5L7na5aAkwzOeZaHUfNeWXA3NM+1rcAtUNiixthRQRIcSSh7Zl5y6OwG0TG9LrTg44+G77k1fEllbnxOcp3pYEpltS1523M3cVV8SohEf5zLUnjVvuiWRKxnel2RoQyj5thzb0JSs6UvuTd3W599xb6r2GXvwZpBfqxPhnUDZoNTKvSkJ0ZV0aBFra9C+PtNyUNjwzPQl/6zlkgx0thrSlITQbSlIOtftm+ZRSQadCCU3VfLPuhJ/VJJBQ5qSGfJTBRTVvqnZUJr+34XP7GpK4TvdvRm+s22LdN4+k22p4XUomUCLad80wrcvE037gnX0HHQlGZ41bzatbSUdrKPni/E1CNa2wdtTKIVnnj8Lf+NNeOZ5sPA3c4SSb/XCX6jQlJo25IOSEI38RLAVkcm+JAOdTSnotSvJUBKB6q4k2++aUqMTefudDii6LeXtM9mWmhY1paAvXod8ydN7rE80KE2LgpUshLMq1Zd8vlso+V/dM9mWZCjlg5LPRWtKvo8Uqv1O+zbIVrb+qnJfaizH3zfFFv4+JhZKvtfwh7k2JTPgdeDywh+eGUpeTxeqtY7wxcKfxhe+C9rTvxnkoFou+Xp9qeGg/96VZCN3FfoXf9qGbEuuNbKhxf/KexR/vIN/07Rv6vCmbd804c22Bu5b6/eLy7bk3lRNj+J/5cfapW97X5//94jp/z1+pxupNL1b+LeXUfh34VML1bkfyt2MxOcFbg7l3c4N6G7Q3xSXbpbwaGUxC1Off5T1we9Oui93+zC5UJr7LVZK8swYqT9+/H+loRxB
Re: 2.0 train schedule setup
This is the part that bothers me (which isn't your fault of course). I'd like to keep my input stations with the name "<icon>Input", but it seems that currently there is no pattern matching for station names (except in interrupts and then it only matches with the cargo that the trains has currently loaded).
Actually trains waiting fully loaded at input stations is a good thing IMHO. It means that your cargo/fluid requests will be fulfilled that much faster. For that purpose, I'd actually make the input step part of the regular schedule and not an interrupt and instead the Depot part would be part of an interrupt (with the condition that the train is empty).this works but not ideal. trains are going to inputs and unload at output. seems fine. But sometimes they go to inputs and fullly load even if no drop stations require this input. So loaded trains wait in stations or depots. Which is an issue.
The problem that you cannot have a station name like "<icon>Input", but must use the same name "Input" for all station sadly remains...