LTN like system in vanilla 2.0 (Pull-Push with no loaded train with nowhere to go)

[giuzy]

Hi guys, so these are my findings about a FTL like system (sorry if the topic is outdated) and what I managed to do. I think I miss the last step and would gladly listen to any help.

- General system Provider, Requester and Depo stations.

- Station are all called "Item icon R" and "Item icon P". They activate themselves when there is enough item for provider and deactivate if not enough space for the receiver (I did this with a decider, can be done with the station hooked directly to the chests).

- Requester send a -1 on the green network when need items, provider +1 on the red network when items are available (it can also be done with only the requests on a single network cable as the provider is not active when there are not enough items)

- At the depo, a decider combinator check if there is a +1 and -1 of the same item and in case forward that signal as +1. (The signal are sent in order of the items in the UI and this means that if a signal is sent and for whatever reason it cannot be taken, the ones after it will wait and never be forwarded until the first signal is taken care of. Can be solved with the new randomize feature of the Selector Combinator.)

- The schedule is nothing special, interrupts only. The main one is: 1) if item signal > 0 and the provider and receiver are not full, go to "wildcard P" station, full cargo then go to "wildcard R" station, empty cargo. Another interrupt for refueling and one for going to depo (when no cargo).

First issue: The requester send the -1 when the train is in route to it causing too many trains to take the request.
Solution: Add a Decider and check the parameter C from the station that is the number of train that are using or arriving it. Make the signal only be send when C=0.

- Second issue: When a train goes to the provider, the requester still send the -1 causing too many trains to take the request (this seems to be because the station is consider occupied only if the train is in route there and not if it's part of a train schedule, so making the schedule "like go to the provider then the receiver" vs "just go to the provider then with an interrupt check what cargo you have and find a free requester" doesn't seem to change anything)
Solution: The provider send a +1 on the green network when a train is in route to it so it negates the -1 of the requester

Third issue: Liquid trains. In order to be able to distinguish between item and liquid trains, I had to do a separate Depo, called LiquidDepo. Added a condition to the schedule, a train should be at LiquidDepo to be sent. Added 2 combinator with a list of all the solids and the liquids respectively (checked like "if item part of the list, forward the signal otherwise not). (I tried to play around with the liquid wildcard, but I could not use it as I hoped, in the rich text to set the station name or to check the kind of item for example. If someone know a better method here, please share.)

At this point I thought to have done it, but no, another issue surfaced.

Fourth issue: if you have many free providers, the system send as many trains resulting in some of them blocking because of the receiver station shut down after receiving the items from a previous train. This seems to be because the signal is sent to all the train at the same time, so there is no time for the provider to result occupied.
Solution: The only thing I found online is to have a sort of clock that send the signals to a single train at a time with at least a delay of 2 ticks. This can be done by adding a combinator to every Depo station and another condition in the schedule. The clock send a 1 in different moment to every train, so the train that has the 1 active the moment the signal is sent will take the order and no other one.
This last thing for me is too complicated and I don't like the idea to add a clock for every single Depo stations. Someone knows an easier way to send a signal to only a train?

And I'm finished, this is the state of my logistic network at the moment. It kinda works because if you consume many resources, some trains that wait for a station that is soon open don't create too much chaos. But I am surely not satisfied with it, and after all the hours I dedicated to it I begin to think about Cybersyn.

So, any help appreciated, thank you!

[mergele]

Alright, this is very convoluted, and limited, but it's not a clock, so heres an initial (bad) suggestion.

You read at the depot stop the train ID.
You send that train ID onto the global line.
You also send a 1 on another signal onto the global line if there is a train, this counts the trains currently ready.
If the train ID signal on the global line / your train ID >= number of trains ready you stop sending your ID to global. You also stop sending the +1 for the train count.
The memory cell remembering the above condition resets if train ID on the global line == 0.
If the ID of the train at a depot is equal to the ID number on the global line send another1 +1 signal to the station
Trains add a circuit condition to wait for this signal on their depot stop.

The idea is that we need to ensure only one train attempts to leave at any one tick. For this we use the train ID and filter out all depot stations that do not have the train with the highest ID at them.
Problems: This breaks if the sum of all train IDs exceeds maximum number and becomes negative. I do not have a solution for that case, except hoping that your system is small eough to not run into it.

[Tertius]

- General system Provider, Requester and Depo stations.

- Station are all called "Item icon R" and "Item icon P"

If your setup in general is:

- each train has the same amount of locomotives and wagons
- each full train carries just a single kind of material, for example just [iron ore]
- each station loads/unloads one single material, for example [iron ore]

then your setup is perfectly suited for the interrupt system exactly as it was presented in fff-395.
No circuit network connection between stations needed.

This is the relevant configuration:

11-20-2024, 14-12-12.png (162.8 KiB) Viewed 700 times

Notice this:
- all loading stations are called the same, regardless of the material they provide. In the screenshot: "Item input". You have it differently - rename all your provider stations to the same name no matter the material they provide. That's the crucial thing to enable universal trains.
- the interrupt shown determines the cargo type that was loaded in "item input" and selects the destination station name. The wildcard is replaced with the cargo name, in the screenshot it is [iron ore] which was used to create the destination station name "[iron ore] drop".

How to handle the depot is in https://factorio.com/blog/post/fff-389 chapter "The depot problem".
Relevant interrupt:

11-20-2024, 14-16-22.png (151.42 KiB) Viewed 700 times

[giuzy]

Alright, this is very convoluted, and limited, but it's not a clock, so heres an initial (bad) suggestion.

You read at the depot stop the train ID.
You send that train ID onto the global line.
You also send a 1 on another signal onto the global line if there is a train, this counts the trains currently ready.
If the train ID signal on the global line / your train ID >= number of trains ready you stop sending your ID to global. You also stop sending the +1 for the train count.
The memory cell remembering the above condition resets if train ID on the global line == 0.
If the ID of the train at a depot is equal to the ID number on the global line send another1 +1 signal to the station
Trains add a circuit condition to wait for this signal on their depot stop.

The idea is that we need to ensure only one train attempts to leave at any one tick. For this we use the train ID and filter out all depot stations that do not have the train with the highest ID at them.
Problems: This breaks if the sum of all train IDs exceeds maximum number and becomes negative. I do not have a solution for that case, except hoping that your system is small eough to not run into it.

thanks a lot for the idea. To be honest, it's also quite complicated and I am not even sure to have understand correctly the logic. I've also thought of using the train id, or assigning positions to the trains and always send the lower/higher one available. But again too complicated and too many deciders for my liking...

[giuzy]

- General system Provider, Requester and Depo stations.

- Station are all called "Item icon R" and "Item icon P"

If your setup in general is:

- each train has the same amount of locomotives and wagons
- each full train carries just a single kind of material, for example just [iron ore]
- each station loads/unloads one single material, for example [iron ore]

then your setup is perfectly suited for the interrupt system exactly as it was presented in fff-395.
No circuit network connection between stations needed.

This is the relevant configuration:
11-20-2024, 14-12-12.png

Notice this:
- all loading stations are called the same, regardless of the material they provide. In the screenshot: "Item input". You have it differently - rename all your provider stations to the same name no matter the material they provide. That's the crucial thing to enable universal trains.
- the interrupt shown determines the cargo type that was loaded in "item input" and selects the destination station name. The wildcard is replaced with the cargo name, in the screenshot it is [iron ore] which was used to create the destination station name "[iron ore] drop".

How to handle the depot is in https://factorio.com/blog/post/fff-389 chapter "The depot problem".
Relevant interrupt:
11-20-2024, 14-16-22.png

Thanks for the suggestion (even if it made my feel a little stupid but it's not your fault eh) Sorry if I ask but do you have a system working like this? Because in the fff you mention, they just talk about the wildcard icon so you can avoid to specify an interrupt for every item. They don't talk about how to handle the requests so you know when an item is needed for example.
Naming all the provider station the same will make the train knows to which item provider to go?

For what I understand there is still the need for a network signal for the requests right? Otherwise how can you know when the item is needed. I am unable to understand how to do it without circuits. Could you please elaborate a little more?

[mergele]

I have a system working like that and it works quite well. You don't need any kind of global circuitry for it, actually you need no circuit stuff at al if you want it barebones. An important aspect I think Tertius missed is that all station have a train limit activated.
So, let's play a loop through for a train sitting at the depot:
- It sees there is a loading station that is open (fewer trains there or on route to it than it's limit), so it activate it's loading interrupt and drives there.
- Once there it get's loaded with iton plates.
- Once it is full it looks for the next station to go, replacing the wildcard with the iron plate, so it is looking for an open iron plate dropoff.
- Currently all iron plate dropoffs are already serviced (no open spots due to train limit), so it just waits with full cargo at the pickup station waiting for one to become open.
- Once a iron plate dropoff station has a spot open it drives there and unloads.
- Once it is empty it either heads to the depot if all loading stations are full with trains, in which case back to step 1. Or if a loading station has an open slot it heads directly there, back to step 2.

This system requires that there are a) equal or more trains in the system than combined number of train limits on stations, to ensure smooth operation, and b) number of depot slots >= number of trains - sum of all loading station strain limits. However in practice that is not a real problem because a) even if a few are missing the actual impact is low, b) since you can just blueprint the trains it is super easy to place more, c) depot stations are quite compact and cheap so having a whole load of those around is also easy.

Edit: A item is always needed if there is no train waiting to be unloaded.

[Tertius]

I have this running, yes. As shown as in the fff. I actually copied the schedule and interrupt settings from the fff. The depot and refuel is slightly different, because these are not freely accessible in my base but located behind the unloading stations, so the depot and refuel interrupts have additional constraints so they don't work if the train is currently at a loading station. But cargo transfer is 100% as it is in the fff.

I run without any dynamic train limits. No circuits. Both loading and unloading stations have a static limit of 2. There is space for 1 train in front of every loading station, and the same for every unloading station, however the latter are combined in a stacker for a bunch of unloading station directly in front of these unloading stations. These stackers don't have an extra depot station, they work by using chain signals.

You need to deploy enough trains in this scenario. And it's supposed to have slightly more supply from the loading stations than is consumed by the unloading stations, so trains will start to accumulate in the waiting areas in front of the unloading stations. Then, it happens trains at the loading stations will start to stay in the loading stations, because all slots in all unloading stations are full. And this is totally fine, because it's another full train ready to deliver its content.

If a train at an unloading station gets empty, it gets replaced immediately from a train from the stacker, and the stacker space is immediately filled from a train previously at the loading station. Then the loading station has space again, some waiting empty train proceeds from the waiting area in front of the station and starts to being loaded, and the next empty train will move in either from the depot or directly from a loading station that just got empty. If a train gets empty and all loading stations are full, the depot interrupt fires and the train is directed to the depot - the depot needs its own stations in contrast to the stackers.

The common case is to have every station being occupied with one train that is either being loaded or full, or being unloaded. Empty trains will either move into the depot or directly to a free slot at some loading station.

You don't need any network signal for this. No circuit. Not a single one. The signaling mechanism for a train to come is the static train limit. As long as there are less trains than the limit, the next train becoming free will be called to this station. And if both trains are driving to or waiting at a station, both slots are occupied and trains will be assigned to other stations.


For example, the [iron ore] unloading station:
It has a static limit of 2 (will of course work with static 1 as well, but in this case the latency is higher - the next train is dispatched only if the previous one is empty, and the station chests have to last until the train drove came in from the mining area).

Ok, it has some static limit. As long as there are free slots, the next train that got full with [iron ore] at a loading station, will get it as destination and drive there. This reduces the number of free slots. If it got 0, no more trains get it as destination, and if it's still > 0, one more train gets it as destination.

There is a difference between a train getting a destination and getting the schedule entry. Creating the temporary schedule entry is done by an interrupt. A train getting a specific station as destination takes place later, when the train consults its schedule with the list of stations to drive.

The destination name is determined by the "Generic input" interrupt you see in the picture. It uses the wildcard. Any full train about to leave check its interrupts. It detects it has [iron ore] as cargo in the interrupt condition and replaces the wildcard in the "<wildcard> Drop" station name, so it becomes "[iron ore] drop". This will result in the temporary entry you see on the left in that image, where you actually see the "[iron ore] Drop" destination with waiting condition "Cargo [Iron Ore] = 0".
The destination assignment to the station is the immediate next step: the schedule is checked, it finds the next station name, and if there is one station with that name with a free slot, the train will get that station as destination and drive there.

The loading stations must all have the same name. An empty train goes to a random loading station (ok, it goes to the nearest station with a free slot, but it's unknown which material is being loaded at this station). The train arrives and gets loaded with some unknown material. Now the train is full and it checks its interrupts. And in this moment the wildcard is used to detect what is currently loaded in the train. The wildcard is replaced as I explained above, so now finally the train got its identity and it will be assigned an unloading station with the proper cargo name. This will happen even in the case there are no free slots at any unloading station, but that doesn't matter. The train will stay and wait until the next slot becomes available. And since it already got its schedule, it will start and use this schedule if it gets the next free slot.

[giuzy]

Thank you both for your posts, now I understand better the system you're talking about that was hinted in the fff.

In this system, trains wait at the requesters station for a provider to be free, it's different to what I am trying to do, aka trains are only called when there is the need for a cargo of item somewhere. However I can see the pros about your method, the more important one being no logic needed. And thinking about it, the system should not clog, you only need a sufficient number of trains.

Regarding the wildcard, I am using it and find it one of the new nice addition to the game systems. Would like to understand better how other wildcards works though, as the liquid and solid item (I guess) ones don't work as the general one (for setting station names).

In any case, ultimately I don't like having all my trains already loaded and waiting at a station with nothing to do. I'd really prefer a Pull-Push system rather than a Push-Pull one. Probably it's stupid but that was my idea when beginning the "journey". If there no need for an item, no train should be loaded imho and the idea that trains just go to a random station (the nearer one) without need is not really Factorio like for me (but it's just me). So I'll update the title of the post if I can and continue to try to make a Pull-Push system in the simpler possible way. Thanks again for all the info and hints, much appreciated, they helped me understand the difference between the 2 systems.

[mergele]

quick aside correction: Trains wait at the depot or the provider station until a requester is free, not at the requester for a provider.

You could pretty easily modify it to do what you intend by having a global logic network where requester stations put out a signal of the item they require once they require it, and the provider stations only activate once a signal for the item they provide is set. This does have the disadvantage that it only reliably works with a single source of each item, so you would probably need to have a proxy station that collects from producers and distributes to consumers in the middle.

[giuzy]

quick aside correction: Trains wait at the depot or the provider station until a requester is free, not at the requester for a provider.

You're right, they'd wait at the provider station because all requesters would be full.

You could pretty easily modify it to do what you intend by having a global logic network where requester stations put out a signal of the item they require once they require it, and the provider stations only activate once a signal for the item they provide is set. This does have the disadvantage that it only reliably works with a single source of each item, so you would probably need to have a proxy station that collects from producers and distributes to consumers in the middle.

Yes and we return to my very first post as I was describing a system like that. It's not so simple in reality, you' have to consider all the cases (requester still send -1 when train in route there or to the provider so multiple trains are dispatched, then there is the liquid train management). My not solved issue (the fourth) was, as you said, that you need a single source of item as the signal is sent simultaneously to all the train in the depo. Only solution found for that is a sort of clock sending a signal in a different moment to all the trains but I was searching for something easier for this problem and for the liquid trains if it exists...

[mergele]

Preventing other requesters from becoming active if one is already active would solve the on-the-road issue, but will murder throughput.
sigh we by now a whole list of approaches to solutions that are all not carrying some kind of flaw or another. I do hope someone finds a way to solve that knot, I would be interested in seeing it.

[giuzy]

I agree for sure, also doing some search online no clear solution seems to have surfaced a part from the clock one. And you still need at least 2 deciders for every station, plus a very "manual" list of items that has to be checked to distinguish between solid and liquid. So already the system is not so simple, if you insert a signal into the wrong cable color you could finish searching for it for hours (it happened to me). So I hope someone find a solution to this, or the devs just add some small feature to make it more feasible.

[TurningGears]

I would recommend to centralize the logic using radars. I have all the logic at a central point that processes the data from all stations.
With radars now all having the same network independent of the distance as long as they are on the same ground (planet), you can even add a self powered radar with a few solar cells and accumulators to very remote train stations.
You can then send signals based on the count of trains (which includes the trains on the way) going to the the loading and unloading stations.
Combining that with interrupts you can solve most problems and even setting wagon limits centrally at one place and things like chest thresholds etc..
You can even implement more complex logic for optimization like using memory cells to save requests from the network (like iron ore signal), tracking trains going in and out and orchestrating the number of input and output trains, even setting priorities remotely, but I currently still use the increasing clock based priority which is fine in most cases.
You can also use the central signals on the radar network to intelligently dispose trains from the depot by sending different signals to the depot stations, randomly going though them, weighing them, filter out fluid requests and only dispatch fluid wagons (seperated by train name, station name or something else) or whatever you like.
I currently have the trainbrain called combinator array with a radar at my depot and configure everything there. In combination with varying complexity of supplier stations, most are simple as all variables are defined centrally and you just define the wagon count and resource at the station, I was able to handle all challenges so far, but I haven’t tried to implement mixed trains with fluid and cargo wagons or asymmetrical numbers of wagons at loading and unloading.