Train chooses shortest blocked path instead of longer free path

[danteeh]

In this picture you see that the chain signal properly signals that the left path is blocked and the right path is free

Untitled.png (1.31 MiB) Viewed 1858 times

Capture.PNG (9.42 KiB) Viewed 1858 times

Now I have an iron train stop very far to the left that can be accessed from any of those 3 blocks. Problem is if I tell my train to go to the iron stop from this split it'll choose the path on the left and will be stuck

Capture1.PNG (7.89 KiB) Viewed 1858 times

Whereas if I tell it to go the rightmost block it'll choose the free path (obviously because it's the shortest one and free)

Capture2.PNG (7.33 KiB) Viewed 1858 times

[JimBarracus]

you could try to use network controlled signals
wire them to the train station
they turn red, when T != 0

[Loewchen]

Or you could lay out the paths to the stations so they have equal length from the forking point.

[eradicator]

If the "free" path doesn't get the train any closer to the station it wants to go to it won't take it.
Try using circuits to disable the first two stations when they're occupied (you have to leave one always active to prevent no-target).

[Pi-C]

Or you could lay out the paths to the stations so they have equal length from the forking point.

Nope, that's nice in theory but in praxis, there will always be edge cases where this doesn't work (additional curve on one side, so you can't place stations/signals exactly in the same distance etc.).

I've come up with something much better in my current game: "waypoint" stations! I've put "waypoint" in quotes because they work different from the waypoint stations introduced with 0.17:

waypoints-map.png (35.28 KiB) Viewed 1829 times

Trains enter via the station marked with "Entry". Once a trains stops there, the signal marked with "Reset" will turn to red, type and contents of the train are read, and some circuit magic is performed. Finally, one of the "Waypoint" signals will be opened, the others will be closed. In my setup, all stations will have the same name. The next regular stop may be some way off (so equal distance from the forking point is impossible). That's where my waypoint stations come into play:

They will usually be closed. When one of the signals turns green, the waypoint station behind that signal will be enabled. That ensures that the closest path to the next station will be free, so the train will be guaranteed to path to that waypoint. As soon as the head of the train passes the signal before the waypoint station, that signal will turn red. The waypoint station will be disabled at that moment because it's only enabled if the signal before it is green. That doesn't matter because the next station behind the waypoint will have the same name as the waypoint (i.e. "Node"). Thus, the train slows down but doesn't stop at the waypoint station; instead, it will go on to the next free station behind it. Once the complete train has passed the signal before the waypoint station, the "Reset" signal will turn green again and reset all waypoint signals to to their original state, so the next train can enter.

I should add that all trains have the same schedule set:

• Node
  Wait until
  • Inactivity: 1s (fluid trains: 2s to make sure pumps can attach to the train)
  • Circuit condition: Green > 0
• Node
  Wait until
  • Inactivity: 1s (fluid trains: 2s to make sure pumps can attach to the train)
  • Circuit condition: Green > 0

This way, trains will always pick the expected path with minimum delay.

[Pi-C]

If the "free" path doesn't get the train any closer to the station it wants to go to it won't take it.
Try using circuits to disable the first two stations when they're occupied (you have to leave one always active to prevent no-target).

This post wasn't there yet when I started to work on mine. It's more or less the same thing I suggested -- guess one could call it the TLDR version of mine.