[0.18.22 / 1.13.1] Several trains at the same depot problem

[ZlovreD]

Tested on blank save with only LTN and Creative mods, plus ZReGroup (modded) it is QoL mod to rearange recipes in craft UI.

I'm wanna to create depot with more than 100+ trains and with stations with names like: [D] L2C, [D] L3C and so on... And when I tried to create a prototype and test it, I ran into the problem that sometimes different trains trying to use the same depot at the same time, which leads to blocking all traffic (station signal is Blue-1).

f0gWzFa.png (225.84 KiB) Viewed 5047 times

When "Supply" depleted some trains not to erase their schedule and just goes to the first station in their list (Depot). But in some cases that station is already occupied by other train.

VNY5XKA.png (101.95 KiB) Viewed 5047 times

I'm already tried to specify the network id for all stations, change the names of the depot (in case of forbidden characters).
Maybe i'm doing something wrong or in case of such depot size i must use unique names for stations (if it helps)?


Log and Save:

factorio-current.zip

(372.54 KiB) Downloaded 96 times

LTN bug.zip

(3.87 MiB) Downloaded 96 times

[Optera]

LTN does not control train path finding to depots.
Trains always path to stop name with least penalty. When two trains set out to find their way they don't check if there's other trains already on the way.

There's several mistakes with these depots:
1) only use chain signals from start of a junction to the end or trains will be stuck in junctions like those you marked in red squares.
2) only assign as many trains to a depot as it can physically hold
3) that screenshot shows 4 different depots, name them differently

[ZlovreD]

1) only use chain signals from start of a junction to the end or trains will be stuck in junctions like those you marked in red squares.
2) only assign as many trains to a depot as it can physically hold
3) that screenshot shows 4 different depots, name them differently

Signals - yes, my mistake. And giving different clusters of depots a different names solve the problem. But...
There are many more depots than trains. I thought LTN control how many trains assigned to the same depot entity, even if their names is identical (blue signal?).


I see two disputable solutions:
- using train signals to prevent more than one train entering parked area of each depot cluster.
- force trains to return to the same depot station which they leaving from by adding to the end of each new route a temporal rail coordinats.


In first case we get awful throughput of depot clusters.
Second, as i thoughts, if we remove rails on path to selected depot, then train couldn't find any alternatives.

So plans to make a huge depot is facing with fact, that trains may (will) stuck?

[ZlovreD]

I noticed a strange train behaviour:

11.png (644.99 KiB) Viewed 5010 times

So, at each crossroads with such setup of signals, train change their destination to the next depot, but not at the last one. It litteraly can't (won't) find any alternatives (but they exists - "1" mark). But, if i place new station close enough (at "2" marker) - then train find it and change destination to this new station.

22.png (37.45 KiB) Viewed 5010 times

[Optera]

I see two disputable solutions:
- using train signals to prevent more than one train entering parked area of each depot cluster.
- force trains to return to the same depot station which they leaving from by adding to the end of each new route a temporal rail coordinats.


In first case we get awful throughput of depot clusters.
Second, as i thoughts, if we remove rails on path to selected depot, then train couldn't find any alternatives.

So plans to make a huge depot is facing with fact, that trains may (will) stuck?

1) With correct signaling a depot for 100 trains will hold 100 trains. I'm using massive stacker depots myself.

2) Trains will always return to their original depot by name. Using temporary stops is equivalent to using different names on each stop.

I noticed a strange train behaviour

All I see is intended behavior when using Rail signal instead of Chain Signal inside junctions.
Again use ONLY chain signals where trains should not park:

2020-05-11 164308.png (203.67 KiB) Viewed 5007 times

[ZlovreD]

1) With correct signaling a depot for 100 trains will hold 100 trains. I'm using massive stacker depots myself.

Yes. I never tried to hold more trains than actual amount of depots for them.
I just trying to break all depots on several parts, to prevent traffic issues and minimize stations list using identical names for all depots.

- force trains to return to the same depot station which they leaving from by adding to the end of each new route a temporal rail coordinats.

2) Trains will always return to their original depot by name. Using temporary stops is equivalent to using different names on each stop.

By "temporal" i means not a another station, but rail coords where train was parked before dispatcher assign a new route. Something like NewScheduleRecord(nil, "time", 0, nil, 0, railAtDepot) at the end of schedule.

All I see is intended behavior when using Rail signal instead of Chain Signal inside junctions.

I've tried to make some sort of "fail-safe" schematics. If i use only chain signals, like in your screenshot, then train will wait at the first signal until any of already parked trains not leave. But when i'm adding usual signals, then train may pass all way and leave this cluster when/if it find something else at the end. This means, theoretical, no traffic jams.

I'll trying to play with it once again. Maybe i'll found a better way...

[ZlovreD]

Ok...

About fail-safe signals

If using only chain signals, then if somehow a train comes into filled depot cluster, it just stop and wait.

2020-05-11_20-15-13.gif (936.08 KiB) Viewed 4991 times

But if im add usual signal, then train tries to find alternatives.

2020-05-11_20-13-15.gif (2.49 MiB) Viewed 4991 times

2020-05-11_20-17-01.gif (9.25 MiB) Viewed 4991 times

About splitting whole depot on several clusters

At the end of "parking road" must be a way out.

CqwIDQf.png (19.21 KiB) Viewed 4991 times

[Optera]

If that final gif is the normal speed of your trains finding into depots that's not something I would ever want to use.

Usually any seeming randomness in train pathing boils down to train_waiting_at_signal_tick_multiplier_penalty as mentioned here:viewtopic.php?p=474245#p474245
After disabling that penalty entirely with pathological the worse case for my trains is stopping once at the first chain signal for a few seconds before pathing directly through all chain signals into a free spot.

[mmmPI]

Ok...

About fail-safe signals

If using only chain signals, then if somehow a train comes into filled depot cluster, it just stop and wait.

But if im add usual signal, then train tries to find alternatives.

When seeing the gif i thought 'that is happening because there are regular signals between the main branch and the stacker, ( i count 2 ?) those should have been chained signal to prevent more train entering and getting stuck. to not even let them engage into the potential dead end, at the cost of throughput, the longer the branching from the main lane and the regular unload bay are, since they need to receive all chained signal, except for the entrance of each unload bay. they either go in because they fit, or bypass without even trying'.

the second gif is showing something you have when you have the third-gif-setup, instead of the train not entering the depot at all , the bypass lane is located afterward , more to the east, depending on frequencies of train, and spacing between the different depot you may find that behavior more useful.

4 depot(D) getting each one 10 trains, for 40 trains allocated to depot (D) could work using both i think. the more train or depot you add the less convinced i am by the 2nd proposition.

i think the intended logic would be to name those with a d1 d2 d3 d4 name and give them only 10 trains each this way you can use as many part as you want without losing on reliabilty. The system you are using is functionning with more restrictive parameter , those i expect having the bigger impact being :the relative proximity and traffic flow between the different parts that are called the same. That's what you are trying to do you said earlier finding a way to cut down a depot in small part, the 3rd gif makes me wonder if the system is fast enough to be relevant at the scale of the depot on the previous gifs.

Also nice gif

[ZlovreD]

About gifs.. I just added one extra train. That why on the last one with slow reactions for clarity.

Anyway, thx for responses. Now i finally realize how to build "mega" depot and bypass most of troubles. I hope. =)

[ZlovreD]

And after another few tests... 16 clusters per 10 trains. All depots with same names. Providers and requesters with random names. Same combinator settingss for all providers. Requesters with [<= 2 train] settings.

With both rail sigmals

222.png (26.82 KiB) Viewed 4969 times

Only chain signals

111.png (14.85 KiB) Viewed 4969 times

As you can see if using both signals trains do not stuck on main road as in second example with only chain signals.
While im tested it i found another problem - if train schedule is aborted by time limit, then much more trains stuck in depots. Or when something happens what breaking trains schedule.

[khalismur]

Seems like you are having;

[...]if using both signals trains do not stuck on main road as in second example with only chain signals.

Issues with signals and

[...]if train schedule is aborted by time limit, then much more trains stuck in depots

Issues with station and depo design.

I might be wrong, of course, but that doesn't sound like an LTN problem per se.

[mmmPI]

interesting to look at ! despite having two massive and chaotic congestion they both stabilize in around the same time

this wiki page may help you understand a bit more about the trains that ends up out of place at then end : https://wiki.factorio.com/Railway/Train_path_finding

my guess would be that this depot is "too big" defined by the fact that some trains seemingly prefer an occupied-by-train-path, rather than a looooong way to find a free depot slot.

I would expect the path finding penalty for a train to wait (mistakenly) behind another train or in main lane to not be enough in this case to make them look for another path, or the other path being "too long" so that the train prefer to somewhat take its chance at waiting behind another train rather than going all the way.

To test this hypothesis you could manually force all train to repath when it has stabilize by adding another station with the same name as the others somewhere on the map, or have 1 that open/closes , this would force "stuck" train to repath, and if they do not repath toward a free slot but instead keep waiting towards the "perceived" closer slot but in reality occupied slot, then i would see it as a confirmation.

another hint would be the time limit, it's been quite a while since i last used LTN and it may have changed, but i don't think it is supposed to occur in a regular mode of operation, instead i thought it should act when extra-ordinary event occurs, such as biters eating rails because if it 'can' happens otherwise, it 'will' happens , there are enough trains for it to occur often.

This particular system seems to have proportion problems, where what takes the most time for a train is waiting for the train before it, while it could be rolling far away to get material. It makes it mesmerizing to watch, but will show limits if the aim is to carry around ressources in a reliable timeframe.

Also following the same hypothesis those train getting stuck might not occur if you keep the system under a certain threshold of usage at any given time ,since there would be more possibilties for trains to find a closer path that would actually trigger the repathing instead of having the only opens bay left too far from the the wrong parking position to be detected.

The main bottleneck i see i would say is the entrance lane of the depot, it would be like comparing a road in the country side and a lane of a highway, there would be a maximum throughput if everyone was to closely follow the breaking distance and maximal speed. It could even be the same amount of car per hour, but the trafic would look different, one would be slower going, packed car, the other one car going very fast with big gap between them. Some useful data are [1] the minimum time it takes for 2 car to clear a block in a row, ( depends on [1a]speed , [1b]size of block and [1c] breaking distance, it is hard-capped in game ), [2] the total number of car you expect to clear this block in a row (12000 car , or 160 trains ), and [3] the total timeframe available ( The whole day, two hours, 2 minutes ).

For cars like for trains it is very-suboptimal when the flow is poorly distributed over the time period , traffic jams at peak and empty roads otherwise, so the gifs are showing extreme cases but even if it was 2 minutes of average traffic flow, there would still be congestion i think; in this particular situation, out of [1a] [1b] [1c] [2] and [3] the only parameter that is problematic to me is [2] given [1x] and [3] set up already.

You could analyse the exceeding of the time limit as the consequence of the system not being able to meet the objective [2] given [3] while [1x] is capped by fuel, train composition, breaking distance research, and number of rails between signals . The congestion being an aggravating factor due to impacting the [1x] ,very negatively for [1a] and marginally positively for [1b] and [1c] . It's an overall shift away from the optimal flow, that intuitively i think can't be found within reasonnable [1x] to meet [2] within [3]

a visual metaphora would be, there's too much water in the tank for too small pipe anyway, the resolving is it takes more time for all the water to drop, the wondering about the air bubble and their impact on the flow is secondary because you would require physically impossible water speed to empty the tank within a day.

In my view this advocate for 4x40 each of them called [D1]to [D4] and located at each corner instead of in the middle of the structure because it makes designing a single depo way easier and naturally distribute traffic without worrying about counter-intuive results from the pathfinding rules and instead having a simpler relation between distance and time limit, having smoother average speed considering traffic is always good.

[Optera]

Those depots have terrible inefficient connections to the network while also wasting a ton of space.

I'd build a 2-3 train long stacker with at least one output and input track per direction.
Note, there are waiting areas big enough to hold a train without blocking other tracks when entering and leaving the main line.

2020-05-12 082338.png (1.91 MiB) Viewed 4936 times

It still is inefficient. Trains going to the depot from north and trains leaving south will cross the northbound main line.
Ideally there would be no crossovers, we can eliminate the main line crossover points by looping the northound mainline around the depot:

2020-05-12 083328.png (1.35 MiB) Viewed 4935 times

[ZlovreD]

Good morning brain...

Note, there are waiting areas big enough to hold a train without blocking other tracks when entering and leaving the main line.

Dual signals solve such problem too.


Btw, if wiki is right and "The train has waited at a chain signal for a multiple of 5 seconds." and "If the trains has waited for a multiple of 30 seconds or if multiple train stops with the name of the destination exist, the train is forced to recalculate its path." is worked as indeed, then there is a problem in pathfinder.
And in case of:

Train must rerouted to free depot, eventually. But it's not happens.
Or sum of penalties to find new route is higher than just wait?

I would expect the path finding penalty for a train to wait (mistakenly) behind another train or in main lane to not be enough in this case to make them look for another path, or the other path being "too long" so that the train prefer to somewhat take its chance at waiting behind another train rather than going all the way.

To test this hypothesis you could manually force all train to repath when it has stabilize by adding another station with the same name as the others somewhere on the map, or have 1 that open/closes , this would force "stuck" train to repath, and if they do not repath toward a free slot but instead keep waiting towards the "perceived" closer slot but in reality occupied slot, then i would see it as a confirmation.

Hm...

[ZlovreD]

Aaaand... one more time. =)
Now with "Pathological" mod.

Default settings

It may be a proof for mmmPI

If i set "Train In Station With No Other Valid Stops In Schedule" to 7000+ (in my case), then pathfinder send a train to far depot.
Tests shows what it works without any problems. But there is a question: It is safe enough to change this value so dramatically ?

And what about to adding this setting to the LTN (if it really helps)?

[Optera]

And what about to adding this setting to the LTN (if it really helps)?

I won't rip other mods to feature bloat mine. Pathological, Wide Chest and so on all are great mods, use the originals and at least show appreciation to the original authors by downloading their version.

[mmmPI]

Btw, if wiki is right and "The train has waited at a chain signal for a multiple of 5 seconds." and "If the trains has waited for a multiple of 30 seconds or if multiple train stops with the name of the destination exist, the train is forced to recalculate its path." is worked as indeed, then there is a problem in pathfinder.
Train must rerouted to free depot, eventually. But it's not happens.
Or sum of penalties to find new route is higher than just wait?

i expect the train to repath as the wiki state multiple of 5 seconds or 30 second or the other case, the problem is that train doesn't repath where you want it to repath. you can use the F4 key to open the debug menu, there is a tickbox called show-train-repathing, (located roughly 60% in the long list) if you tick it trains will leave a pop-up text "repathing" everytime they do, most of the time they repath towards the same path and you can't tell it happened.

yes sum of penalties to find new route is higher than just wait i think; given the results of your tests. They are repathing, they see the closest path, which is occupied, and is given a score, counting the penalties, then i think the algorithm exclude path that would be located further than the first one found. It's not really about time, it's about distance.

maybe i was unclear earlier. it looks like they wait, but really are repathing towards the same occupied path over and over, the penalty system giving 1000 makes it more likely "usually" that the trains would repath toward an occupied station over and over rather than a far-away one. Thus "usually" the trains would stay behind another train that is at a station, seemingly waiting for the first one to leave, rather than doing a 1000+ rail long bypass to find another station.

this is intended behavior as far as i can tell.

then if you increase the penalties given to the closest path over and over , i would expect the pathfinding algorithm to go through deeper research in every branch available to find another valid train stop for destination. ( eventually finding the far away depot but i guess at the cost of potentially exponentially more computing power)

If i set "Train In Station With No Other Valid Stops In Schedule" to 7000+ (in my case), then pathfinder send a train to far depot.
Tests shows what it works without any problems.

i haven't used the mod https://mods.factorio.com/mod/pathological yet so i can't say for sure, but the results seems coherent with previous attempt at explaining. I however did not expected the parameter "Train In Station With No Other Valid Stops In Schedule" to be the one giving this result in your particular setup.

I think this means the penalty given to the closest path is increased by the equivalent of 7000 rails, if the far away depot was even further away, then you'd need 8000 9000 and so on. For the original depot it seems to mean that the distance between station named the same is too high given the 1000 penalty. Trains sometimes don't find the free slot (too far) so they "just wait" ( repath to the same station).

for safety i think it's better to change the depot rather than the penalty, and also one is part of playing the game the other one is modifying it but i can't say for sure.

[ZlovreD]

then if you increase the penalties given to the closest path over and over , i would expect the pathfinding algorithm to go through deeper research in every branch available to find another valid train stop for destination. ( eventually finding the far away depot but i guess at the cost of potentially exponentially more computing power)

Depends... I'm not planning dynamically increase penalties, just increase it once, globally and only one. So, theoretically there is no performance issues. In usual cases i don't need to increase penalties so much, just rise it enough to cover all train park.

There are two options for penalties that may fit my needs (full list):

And I think the second is more suitable, because more specific and does not cover those trains that are busy by loading or unloading.

And seems there is some sort limits in pathfinding calculations. If all potential pathes took more than X segments or exceed Y penalties threshold, then stay with previous path. And adding to one of variant 6k extra penalty points pushes this limit further away. Or maybe somthing similar. =)
Even in such awful setup, i don’t think it’s necessary to add too much to allow trains find a free depot.

[ZlovreD]

And what about to adding this setting to the LTN (if it really helps)?

I won't rip other mods to feature bloat mine. Pathological, Wide Chest and so on all are great mods, use the originals and at least show appreciation to the original authors by downloading their version.

You know what? Actually there at least two and half reason why you can adding this option ( i mean "train_in_station_with_no_other_valid_stops_in_schedule" only) to the LTN:
1) Chance, what you meet a train on station w\o another station in schedule, when you playing without LTN, is going to zero and pathfinder is not setted to handle such cases by default. So It looks like this option was originally added for use with LTN-like mods;
2) As a consequence of the first reason - different players may built different setups of their depots. And this settings may vary for each of them;
2.5) This is a default game constant. Not a script or modification of prototype, not even another author's IP.