wiki/train repathing: when/how are train stop selected

[mrvn]

TL;DR

Be more specific in what situations a train can switch from one station to another stations with the same name when repathing.

What ?

In https://wiki.factorio.com/Railway/Train_path_finding is a long list of when a train with revalidate it's path and when it will repath.

What isn't clear is in which situations the train might switch from one station to another station with the same name. Can it ever change directions on a repath? (don't think so)

It's also undocumented I believe what happens when a train reaches a (temporary) train stop without a schedule condition. The trains schedule advances as soon as the breaking point hits the targeted rail. But how is the path for the next schedule index then calculated? Or more precise: from where?

Will the train always pass the targeted rail or can it repath to bypass the rail? Can a train change direction at a schedule stop with no condition or will it only search in the direction the train is moving? Can it get stuck with "destination full" in the middle of a junction or hit itself? Or will it follow the previous path till it hits the rail target before getting stuck?

Why ?

It's unclear how trains will behave in detail making it hard to predict the behavior and to get the most out of trains.

[mmmPI]

One way to know is to make a test setup, this way you know in detail what happen in your test setup.

You can test a rule specificly, or you can just ignore them and make a design, then when it breaks, you debug it using the rules to understand for example why your train changed destination during a repath. ( because that can happen like in this setup : )

0eNqlm11u4zYUhfeiZzsQ/yk/dBV9ahEYis1JBMiSIclpg8AL6C66tq6kon/lzGV8j+dlBoqtT7w8PJcUef2ZvdS7sO2qZsgWn1m1aps+W/z5mfXVa1PW8W/DxzZki6wawiabZU25iVddWdXZfpZVzTr8nS3E/nmWhWaohioc7z9cfCyb3eYldOMXLnf2w3jv69swPyBm2bbtx7vaJj5qJCnvZtlHtnBuv5/9hJEXTKQ0835otxSjODNm2RjR0LX18iW8le9V28XvrKputauG5fjZ+nLjj6rrh+WduFftdhu6+bYuh5Ad6f1Qxs7L48VmW3blEB+S/Xb4+PSg0JQvdViuqz7+ny2GbhdmxxiWMYZtWP/85PeqG3ZlfX348Rvz3yO5D8PycH+/rKtNNdwwT3/DgjlG04RV7JA+3iTiP11YTwWtxiu/f47fHgM/9l32R0ZopbiSayG+kVyzJNdCXSW/0zDDHov2NI4KqmGWNxadODOmDSuphjnYJGTD/AQTQj1fvYV+ICCFeDJHjH8yfPVlVJ94bAHrTbZe5Kg8XpAcOOUkOBKNK8FRcFyK5Gg4Lppj4LhojoXjMiQHHv0JjofjojkFHBc9ZeVwXDRHwHHRHAnHRfpUKjgumqPhuGgOnNYL0qfSonElOA6NK8HxcFykT2UBx0VyVA7HRXMEHBfpUyXhuGgOvF5JcDQcF+lTZeC4aI6F46I5Do6L9KnycFw0B15v0BwNrzdEThpVwwuOFAhecaRACg+N9KrWeGg0yOCh0SCLh0baVTs8NBrk8dBoUHHzlj0/vcQRGHlav4+gwwJ+XXXH9fv4IfXe88BIJ1OBuY701a57D+tkj9kjRuS3rTMUVPLCVt5fwrassBWvtTq+ebBbq/G+JNOPgZctQpBmN7gjBGkt47jqnvvL3vaXpKBA1leX1t1gFYUtmNrmmt9Wy1/h5I7fVitwgcgEYblOcfnZKUJznGLZ84X0Z7Bj9KfmYx2ANXxsAWDZPpKFALCOj1UA1vOxiGQFHwtI5nI+FpDM8Z2VA5I5/ptFDkjm+KuyHJDM8WekHJGMPz/liGT82Uogkl1dVrerdtMO1XugmPZJKi+9kNMebrtq5J22aPOn+FncMD/shvZtXa3nP3ahjks9Ki07/hQnkOHCf28XwHDx/MWgAIaL51tRAMPF860ogeHi+VaUgGSeb0WJSMa3okQk41tRIpLxX6wUIhnfZQqRjO8yBUhW8F2mAMkKvssUIFnBd5kGJCv4LtOAZAXfZRqRjO8yjUjGd5lGJOO7zCCS8V1mEMn4LjOAZCLn28w4hMv3mSkQLnAGIxAusOGnEC6w2wHpBmx+QLo9sBfi6MNo9wiJ0UK+wRw0AvgOc8gIAE7lHTICgFN6h4wA/qm9cohuwCm+R3RDTvUh3YBTJEg3+JSUyQW24yHd+H4rIN34fkO2dQRQNYDs6wh+FYFCNnYEUFWA7OyISZXBiG36bdsN85dQD+Rb9WW7s3iiazqkBnDFfZxh7sRKd2H5rzuxliRbJlkZlOyYZJOjZM8kW42SC3wWpovLJtUL31ftqQvmdpD+ekFpqqwzltrdVJSKLxWl//3z7/2a0j406+XQHmtDs8WPsu5/qdKUXxcoFK8uVEwqPwBPS5EwoZIP4fIUTj2SItKteyjjpFuHHxfKRDkivkaWdAEgXhkyJk6adM0gm7Cudpt5qMeR11Wr+batqY1cd0klUiNFrGMimDTg8BctEoWtQuHpR9KvEw8Um0g6kU2qTe4k28vUo/JzD6XzV9324ZIfTsnj/GEXymvuiNkGzg1kIHA94phAaJKCz0VPXXLnXFRo/LRfJYp3cf8q2isPVMCoxKDE/asSgxKuVYyuI0m45XSizBm3nKZ73OAH+Jru8Umty7fHVGeMEU9KyVzFvPn1mCp1RpXoDbwkTNNaG2Biuy74jPhqOHLZP6mKuQ83KNwCcIvCcTMZ2gIGN5NJiD6pkim713b+V/k63vwNx3873pr38brtxm82u7omfxOAm87QprPioWFmWWJZ+dAwY8Jxqxk6XVh8+jG0aS0+/Vh6dFp8+rGJ34/gjrGJsYI7xiZ6HJ9+LN3jDneCo3vc4dOPo3vc4UsuN/b48/hqt3oL6119+o3nde6K185NvnD8Den0RfA5tuT2jnEeTN9Sxluej7PbeHn9meosew9df/SdH2fYQjptC2lzv9//D2FqMgM=

Copy blueprint

pause the game, set the 2 train to automatic, watch the lone locomotive repath to the newly open Z station.

[ssilk]

IMHO: It's part of the game to find things out.

Can it ever change directions on a repath? But how is the path for the next schedule index then calculated? Or more precise: from where? Will the train always pass the targeted rail or can it repath to bypass the rail? Can a train change direction at a schedule stop with no condition or will it only search in the direction the train is moving? Can it get stuck with "destination full" in the middle of a junction or hit itself? Or will it follow the previous path till it hits the rail target before getting stuck?

Also don't know where the relevance is.

As programmer I need also to say the wiki is a documentation for users. What you want is a documentation for software developers . But devs documentation is the code. All other documents to describe what the code does tend to lie (over time).

In other words: I think this would go too deep for a game-wiki. That's where forums come into play.

The documentation about train pathing on the other hand is important, because they include things, which cannot be tried out.

[mrvn]

I'm looking at it from a modders perspective. So somewhat between user and dev. I would love to be able to just check the code but that isn't an option. I can only ask for details here or on the wiki.

All of this might be things you can try out. But you can only try out things you know or suspect. And then you never know if the behavior you get is because that is how trains always behave or just because the way your test was set up. If I use that in a mod to make trains behave a certain way then it might work for me but the next person trying the mod will build the rail system differently and get a different outcome.

Current point in case is the temporary stop in LTN schedules. Currently they do have a condition of "0s passed" for temporary stops. This makes the train drive to the temporary rail target, break to a stop and then accelerate to it's next schedule index, which is the train stop connected to the rail. The question now is if the behavior will change when the condition is removed. Will the train still always choose the targeted station when the condition is removed? Or can it switch train stops because it now repaths one breaking distance away from the stop instead on the rail the stop it at. Maybe it will only happen with nulear fuel because then the breaking distance is greater?

[ssilk]

Ok,good reason. But the wiki is here the wrong target. I would expect such docs in the api-description as side notes.

[boskid]

This topic is not for the wiki, nor for the train repathing (most likely). I looked at the described behavior (train ignores a train stop after arriving to rail target at the same rail/rail_direction).

The way the waypoints logic works is that once a braking point reaches its current path end, there is a train pathfinder request done starting at the current path's end (not at the current train position) and looking for a possible path extension. If the extension is found and it has at least 2 rails (one is shared with current path) the path is extended and the train continues, but if there is no path or if it has only 1 rail (which is the same as last rail of the current path), the train goes into ARRIVE_STATION state and no longer checks for the waypoints.

There is one non obvious part of logic in game related to train stops. If you have a schedule which consists of multiple schedule records consecutively going to the same station name, then it is expected that the train after arriving to one train stop under given station name, will not choose the same train stop goal but a different one. In 1.1.x this check is done by means of a rail/rail_direction to filter some of the candidate goals.

Described behavior is because the rail target is exactly at the spot where the train stop is. If there is only 1 train stop after the waypoint, the it is ignored due to matching rail/rail_direction and the waypoint logic fails due to no_path at the extension making the train to arrive to station. If there are multiple train stops, the one it is expected to arrive is ignored and the train goes to the other train stop (assuming the train does not have to stop and change direction which for the waypoint logic is not allowed since the path search happens only in one direction from current path's end). The train simply ignores the train stop it is supposed to reach because the logic which collects candidate targets skipped this train stop.

I made a lot of refactoring for the expansion and the logic here will be slightly different since the path is aware of the train stop at the end of path and it is the one which will be skipped. In that case since the rail target is not pointing onto a train stop, the train stop is not removed from the list of candidate goals and the train will correctly arrive to the train stop directly at the waypoint position (pathfinder will find a path to it but it will have a length of 1 rail and as such will cause the train to immediately go into arrive_station). For now i am not sure if i want to back-port those changes into 1.1.x branch.

[mrvn]

This topic is not for the wiki, nor for the train repathing (most likely). I looked at the described behavior (train ignores a train stop after arriving to rail target at the same rail/rail_direction).

The way the waypoints logic works is that once a braking point reaches its current path end, there is a train pathfinder request done starting at the current path's end (not at the current train position) and looking for a possible path extension. If the extension is found and it has at least 2 rails (one is shared with current path) the path is extended and the train continues, but if there is no path or if it has only 1 rail (which is the same as last rail of the current path), the train goes into ARRIVE_STATION state and no longer checks for the waypoints.

There is one non obvious part of logic in game related to train stops. If you have a schedule which consists of multiple schedule records consecutively going to the same station name, then it is expected that the train after arriving to one train stop under given station name, will not choose the same train stop goal but a different one. In 1.1.x this check is done by means of a rail/rail_direction to filter some of the candidate goals.

Described behavior is because the rail target is exactly at the spot where the train stop is. If there is only 1 train stop after the waypoint, the it is ignored due to matching rail/rail_direction and the waypoint logic fails due to no_path at the extension making the train to arrive to station. If there are multiple train stops, the one it is expected to arrive is ignored and the train goes to the other train stop (assuming the train does not have to stop and change direction which for the waypoint logic is not allowed since the path search happens only in one direction from current path's end). The train simply ignores the train stop it is supposed to reach because the logic which collects candidate targets skipped this train stop.

I made a lot of refactoring for the expansion and the logic here will be slightly different since the path is aware of the train stop at the end of path and it is the one which will be skipped. In that case since the rail target is not pointing onto a train stop, the train stop is not removed from the list of candidate goals and the train will correctly arrive to the train stop directly at the waypoint position (pathfinder will find a path to it but it will have a length of 1 rail and as such will cause the train to immediately go into arrive_station). For now i am not sure if i want to back-port those changes into 1.1.x branch.

Thanks. That answers my question about the temporary stops. The "at the current path's end" was the missing detail. But the extra behavior you describe explains why removing the condition from the temporary rail target sometimes works and sometimes doesn't in my tests. Because whenever the train has an alternative stop which train limit isn't reached it would redirect all of a sudden.

So I see two choices then:

1) Keep the temporary rail target with condition so the train always stops and then path finds to the stop connected to the rail.

This does not work well for bidirectional stations. The train will stop outside the station with the nose at the stop facing the wrong way. It then starts driving again to the right stop as that is generally the closest.

2) Pick the rail before (between) the train stop as rail target

This might not work in some special cases where the train stop is right after a junction. That would have multiple rails to choose from and some might be unreachable. So this would have to be detected and then use option 1 as fallback. Or always use option 1 unless it's a bidirectional station.

For bidirectional stations a rail between the two stops would be the target. The path would then be able to extend to the stop facing the right way. It could still run into a case where a stop is right after a junction. A train station with 3 stops with the same name in a triangle configuration? I think that case can be safely ignored for the use case with LTN. Only bidirectional stations with 2 stops will be supported by me.


Can you answer one more detail please: Where does the train stop relative to the rail when setting a rail target or a train stop connected to the rail. I assume a rail target it right in the center. Where is the stop?

From test it looks like that isn't the same spot with the train stop being further along the track. I can place train stops one train distance apart on opposite sides of the track and setting the schedule to go to one stop and then the other has the train not move. But setting the rail of one stop as rail target and then the other stop makes the train make a loop to reach the other stop.