Factorio Forums

hello everyone,

I have a question and I think I am confused about the train station limit. I have a large base and I have several ore outposts. all outposts share same name like "(S) Iron" and "(D) Iron" (supply and demand). there is no special logic and every ore train is same.

my problem (or question to you all). my trains hardstop in the middle of road, especially on T-junctions. I managed to capture what is happening on the train ,which is very difficult because it happens randomly. I realized they are switching stations, from one (S) station to another, to closer one. for example they drop reservation from one station which is far away and then get reservation from a closer one. but also they hard stop in the middle of the road and accelerate again as usual. this happens on the travel from (D) to (S) (they are empty and they are going back to outpost).

I thought train station limit would mean the trains would really go there, and not drop the reservation. why do they drop the reservation when they are forced to slow down on a T-junction for example and get another reservation from a closer outpost when it is freed? is this really expected?
I was suspicious of the T-junction signaling and simplified it a lot but still they hard stop and change reservation on a station and move to another one. sometimes they are not even slowing down (because they have the green signal) but they suddenly hard stop and accelerate again. signals are just vanilla chain signals mostly.

environment: I have over 200 trains and over 70 outposts. every outpost has 6 train input (2 station with 3 as limit, never changed with circuit network etc). this is one T-junction I captured and it might be happening all over the train network which is huge. it happens on random trains, not specifically for a single outpost.

is this happening because of rules described here? https://wiki.factorio.com/Railway/Train_path_finding

The train limit of a train stop that is part of the train's schedule becomes not full.

since I have many outposts then this shall trigger repath frequently and then they shall move to a closer station? or did I misunderstand this case?

thanks

Hm. The rule you mention only applies to trains which have no path/destination full, so I do not think that is the cause here. However, the behavior you describe is strange.
The only reasons i know of a train stopping in the middle of its journey:
- no fuel
- destination is unreachable because:
1. destination gets disabled
2. destination gets unreachable by removing a railsegment, placing a wrong signal, or renaming the destination station while all others are unreachable
[EDIT] triffic is right. I meant to write the opposite here:
3. setting the train limit to 0 with no other station being availableTrains keep their reservation even i9f you change the trainlimit to 0

Can you recreate this in the editor?

Trains will perform a repath at the drop of a hat. Basically, anything which might make a train slow down will make it repath, at which time if it finds an open station that has a lower path cost, it will drop the old reservation and pick up the new station. The stop limit being set to 0 doesn't stop a train, my system drops limits to 0 with incoming trains all the time, and they never hard stop because of that, nor does dropping a limit cause a repath. My base is currently 317 trains with 2070 stops and IMHO, train limits are darned near perfect for running large bases.

If your trains are coming to a dead stop at junctions, then it is the signaling that is causing that, not any repathing or limits. In the grand scheme of things, repathing should only be an occasional nuisance (and is usually a good thing that helps avoid congestion), not something that causes real problems. If it is causing problems, it is almost always an issue of not enough supply, not enough trains, or design problems.

If your trains are hard stopping on a junction without another crossing train being the reason, post up a screenshot of the junction.

I tried to capture a video in game. it happens in one t-junction because I realized it there but every t-junction is same design and I am trying with alternates I also thought signaling was bad so I am testing other t-junctions on same place. if you think there is a mistake then I would like to know it as well.
no, I do not disable stations, never do that, the (S) and (D) stations are always active. I did not need to.
I uploaded three videos, repathing to a different station and also the hardstop I am talking about.

repath: https://drive.google.com/file/d/1TXRM-L ... sp=sharing
hardstop: https://drive.google.com/file/d/1_M05qY ... sp=sharing
2min run: https://drive.google.com/file/d/11QZxbB ... sp=sharing
hardstop without any train in t-junction is at end of 2min run. I hardly doubt it is signaling but I might be wrong. also there was a "no path" error but I could not find any rail damage/unaccessible station, all are just fine. that is also strange, all trains are from blueprints and they are identical except names of the stations in route.
longer 2 min run on the same t-junction. I did not touch the T-junction for versions (was also same in 0.16 I believe) and never had such a problem.

thanks, sorry for the bad quality videos.

Post the save please.

I can't say for sure what causes that early train to "no path" but given that it happens at almost the same instant as a "something destroyed" alert going off, I'm guessing they are related.

The trains that hard brake in the junction on the left are doing so because the chain signal leading into the next junction (the one on the right) is going red due to a train passing through. Even if it is obvious that the other train will clear the junction in time (assuming it doesn't have to stop for some reason), trains only see signals, and red means it must brake in order to possibly stop. When the other train clears the junction, the signal goes green and the train stops braking as it is now able to reserve the blocks in the junction that it needs to proceed. You can see that the onset of the hard braking coincides with a chain signal in the right side junction turning red.

The junctions themselves seem to be signaled to prevent deadlocks, but with them that close together, a train will have to start braking in one if it has to stop before the next, and that can cause slowdowns that propagate through the system. If you changed fuels and are running on a fuel that allows faster speeds, then trains have to begin braking sooner because they are going faster. If the original design was done with higher braking force research, that could also cause the different behavior.

Train stop limit was decided to not cause any "go away" repaths so it is unable on its own to cause trains to hard stop. It is either stop being disable by circuit network, stop/signal/rail being destroyed by something or a regular repath that changes path in a way that within braking distance of a train at current speed, using new path it is unable to reserve some of the signals but that should not happen inside of an intersection.

Save file to look at would be helpful. If not possible, a video showing the issue while having following debug options turned on: show-train-repathing, show-train-stop-point, show-train-braking-distance and show-rail-paths

thanks for answers.

what I realized and did:
- captured trains which suffer hard stop and realized all ore types have this problem, not only a single type. I deleted all copper, uranium and stone stations one by one and set up a dummy train to go to each of them one by one, not manually but within train route. I can confirm there is not even a single station that is not accessible (did not test iron). as I said, I do not disable stations.
- in the map there is T + T junction which should be visible in the map view in videos perhaps. straight to east-west and one facing north, another facing south. I checked another place where I have T + T junction but the train traffic is not much there and I did not see same behavior there
- destroyed stuff is turrets, biters are agitated because of artillery range search, there are some rail/signal damage but they are not relevant as I see. I shall use another save from before artillery search to make investigation easier (maybe even remove all biters)
- all trains are nuclear fuel powered and also braking force is researched to max

- no path train: I captured one, it was stone, but as I said above, I set up a dummy train which can travel to each (S) stone station (it took me some time to delete all stone trains to enable reserveation)

another point:
- I deleted first T-junction that is in the videos. problem went away.
- (before deleting T-junction) I managed to capture one of the uranium trains that gave the hard stop. the train was driving straight but made a hard stop and turned to south in the second T-junction (east one). I saw another copper train doing same, turned south. so my theory, train did not have enough time to acquire signals so it had to hard stop?

save has many mods which are not in portal so I shall try to create another video with the mentioned settings on. or maybe provide it as it is but then the train traffic shall suffer drastically.

edit: video with debugging options enabled: https://drive.google.com/file/d/1s_tfJb ... sp=sharing
edit2: and the save, I guess the local mods I have are not so needed for train pathing. https://drive.google.com/file/d/1Kz1bLu ... sp=sharing

In the video, that little red ball that travels ahead of trains is the point at which the train will stop if it applies maximum braking. If that red ball hits a chain signal, the train must be able to reserve all blocks along its path until it has reserved one guarded by a regular signal. In terms of this junction, it means that the train has to reserve all blocks it will travel through the junction, as there are no regular signals until the exit of the junction. If one of those blocks is already reserved by another train, it triggers an attempted repath and one of two things can happen. The train successfully repaths to a route it can successfully reserve, or it must begin braking. You can see that trains that are traveling very fast have their red ball quite far out in front of them because it takes them a long distance to brake to a stop. For a train that is traveling left to right at high speed, that red ball hits the chain signal leading into the junction on the right while train is in the junction on the left. So if the train is unable to repath away from the blocked path, it's going to start hard braking while it is in the junction on the left, potentially leading to a snowball effect on other trains wanting to use the left junction.

I didn't see any trains "no path"ing in the new video. If I missed it, post the time in the video where it happens.

You just have two congested junctions next to each other. If you move them farther apart so that trains that have to brake between them don't have to start braking while they are in a junction, things will improve, but there's still going to be a fair amount of congestion and repathing because of that.

Ok i looked into the save file and it is indeed a bug that i have to fix. It has nothing to do with the train stop limit feature so i updated the topic.

The issue shows here because of a specific intersection signalling where a train has to go through the same block twice. When the front joint of a train enters onto a rail above Arrow[1], it repaths during train movement so it cannot change movement direction so in case of a failure to find a new path the train will halt. When the train enters rail above Arrow[1] it enters the yellow block. There is a special rule to prevent intersection deadlocking which causes the train to choose a path where it can make a reservation for all the required signals until it leaves the intersection, but the used check only checks if a signal is a/Open, b/Reserved by given train. Signal above Arrow[2] leads into a rail block in which the train repathing is currently in, so the signal is considered Closed and it has no reservations because train is already in that block. Because of that the pathfinder finds it cannot leave that intersection as every possible path cannot satisfy the (broken) immeidate reservation condition. When the pathfinder gives a NO_PATH, the train releases its reservation to the train stop which reduces its trains count from full(3) to 2 which schedules the goal train stop to perform trains limit logic. That logic then looks if there are trains in the no_path or destination_full state and causes another repath on them. This causes this train to repath but outside of the movement logic where the pathfinder is able to drop the "in chain signal section" flag if having it considered there was a no_path and so it does ignore that flag and the train pathfinder manages to find a path out. From the description fix from my side is quite obvious: i should also check if the block behind a signal contains given train already and that will cause the train to not no_path in the first place. Workaround for you right now is to remove the chain signal above the Arrow[2] and the chain signal that is immediately on the left of it as you do not have any trains that are 2 tiles long (or less).

@boskid, I did not think it was a signalling bug, sorry for the confusion.
thanks for looking into the issue. I was going to ask about the no-path problem as well but actually it is part of the bug then and it shall be fixed too. sweet!

Issue is now fixed for 1.1.33.

-- edit:
In case someone would like to see the broken behavior in vanilla 1.1.32, here is the save file (paused in editor):