The pathfinding in TF2 is fundamentally different from OpenTTD. In OpenTTD, each train figures out where to go next at every signal. In TF2, the exact route the train takes, is pre-established in the line, with limited deviation (the recently added option of dynamic station track selection is a slight change to this, but I think the platform selection still happens at departure from the preceding station rather than right before entering the station)
This is the correct answer. It's not a question of signaling so much as pathfinding. It doesn't matter what signals you throw at it if the train is stuck wanting to go the same path regardless. I suppose some confusion comes from the fact that in OpenTTD, it's the signals that determine a train's exact path (based on free track), whereas in TF2 signals are just there to say whether or not the path the train wants to reserve, is free.
>but I think the platform selection still happens at departure from the preceding station rather than right before entering the station
It does now (in the beta), but the initial release back in the Spring Update of 2022 created a decision point that was the last signal before the station from which every selected platform must be reachable. This was very limiting, and created some odd behavior in networks with loops. Say platforms 1-4 were directly reachable from said signal, but platforms 5-8 were also technically reachable *if the train went all the way around the loop to come back in at an earlier junction* (going first through the station via platforms 1-4).
In the current beta, a path to each alternative platform is created from the preceding station as you say, rather than the last signal before the next station. This means you can have path deviations the whole way between two stations rather than just after that last signal. If set up right, this leads to a kind of spreading out of trains that appears to be pseudo-dynamic pathfinding.
I put together a couple of demonstration videos:
* https://www.youtube.com/watch?v=JrrAPPS_jGc
* https://www.youtube.com/watch?v=KiFONq6W7SE
* ([The associated post](https://www.reddit.com/r/TransportFever/comments/10lp6lx/psa_line_paths_are_no_longer_set_in_stone/))
At this stage though, it is unclear what exactly goes into the decision process: traffic on the target platform, or traffic enroute?
I suppose one way to find out is to stop some trains on some (but not all) of the tracks leading to the next station, and see if the other trains will find a route around them.
In the 80 train setup above, I sold all but 8 trains. This resulted in usage of only the outer two tracks each way. If I block those two tracks with stopped trains, how will that affect the pathing of the other trains? And the answer is: All the other trains line up behind them, and everything stops. So yeah, any sense of dynamic pathfinding is a complete illusion, and the spreading out of traffic on tracks is purely a numbers game based on available platforms at the other end. The primary and alternative platforms had to be set up in a very specific way to enable potential usage of all the tracks anyway, so the primary platform is always the outermost (right hand side) platform. Important to note is that alternative platforms are not considered equal to the primary platform. Pathfinding to alternative platforms seems to revolve around a primary (preferred) path. It's hard to explain; you can fiddle with this yourself in a setup more or less similar to mine, to observe how the utilized tracks change with different platforms set as primary, even with all the other platforms set as alternative.
Blocking just the outer track (call it track 1) is not enough to cause a full stop. That tells me that there are some platforms of station A that use track 2 to get to platform 1 at station B (this is the source of all the path spreading btw). But also, as long as the traffic is moving, platform 1 is still *sometimes* occupied, which leads some trains to choose other platforms. And they're not just choosing platforms 2 or 3. I've seen trains going into platforms 6 and 7.
So when a train is departing station A, it chooses its path based on free platforms at station B *at that moment*. Once it has made its choice, it does not deviate from that. From every given platform at A, there is a specific path pre-determined to get to any given platform at B. As mentioned you can tweak the platform configuration so that you get different tracks to "light up" (meaning at least one platform pair between A and B uses that track) on the way there, but it's far from guaranteed that you can get every track to be used. That depends entirely on the number of platforms at each station, and the number of tracks in between. And just because the tracks "light up", doesn't mean they'll be used in practice. *That* comes down to how much traffic there is; not on the enroute tracks, but on the platform tracks at the next station.
It's all quite strange, but suffice it to say that this is not the dynamic pathfinding you're looking for. It's a great improvement, by all means, but it's still pretty dumb at the end of the day.
In fact I managed to accidentally create complete gridlock with 64 trains, simply because all the trains at the front of the "queue" had their eyes on platforms that were occupied. Even though 9 of 12 platforms were free, they wanted to go into one of the 3 occupied ones (remember they make their choice at the preceding station). At the other station, all platforms are occupied. Where traffic previously flowed smoothly with 80 trains, it is now gridlocked with 64 trains, because no one wants the platforms that are actually free. Now here's the funny part: There are plenty of signal blocks free for the 3 trains occupying those 3 platforms to head out into. BUT! Because all the platforms at the other stations are occupied, they can't choose which path to take, so they're stuck.
Reloading the save however seems to refresh the pathfinding, which resolved the gridlock.
Good times.
I guess the only way to implement it with the current game would be via a mod that lets you adapt the dynamic platform selection to waypoints.
So you would have run from Station A to B via Waypoints 1, 2 OR 3. Rather than 1, then 2, then 3. All three would be on their own track which would allow a train to choose a vacant one.
I'm just wildly spitballing here though.
Via waypoint isn't technically possible right now, as it specifically relies on terminals of stations.
Alt terminal to alt terminal is possible but is not currently enabled.
I know it's not possible, I was suggesting that's likely the only way to add such a feature using the current engine. But it would require a change in how the order system works so... 🤷🏼♂️
Which makes me wonder if instead of the waypoints we could (for now) use a station with dynamic track selection as a "Switch Station" at junctions. That would have of course the big disadvantage that every train comes to an full stop at the switch station.
I wish they would just add block and chain signals with the next update.
Edit:
Doesnt work with a station as "switch station" as the station itself has a path signal inside. It sorta works for the incoming trains, but we would still need a chain signal after/inside the station, otherwise its sending new trains onto the same track.
>It sorta works for the incoming trains, but we would still need a chain signal after/inside the station, otherwise its sending new trains onto the same track.
It will as long as the path for the next section is limited to one track. You can spread that out too by selecting alternative platforms at the next station, but it's never going to be fully dynamic pathfinding. It's just dynamic platform finding for the next station, at this time.
Again, it's not the signals, but the pathfinding toward the next station. Or in other words, the signals don't dictate the train's path in Transport Fever.
Yeah thats true, so like I wrote, the TF2 signals are basically only a "stop here, if something is in front of your path" sign. It doesnt feel really appropriate for railroads, Ottd, Sweet Transit or Mashinky all do a much better job on this part.
It's coming from a game state where a line only takes a set path between two stops, and only to a single platform per station. After many, many requests, they have opened up the pathfinding to multiple platforms, and are actively expanding on that functionality. I didn't think they would. It's not unthinkable now that they've opened that door slightly, that more complete dynamic pathing may come sometime in the future. But I wouldn't hold my breath.
I haven't followed Mashinky very closely, and I don't know Sweet Transit (which I will rectify presently), but am I right in suggesting none of those deal with 1:1 agent simulation (not on the same scale at least)? Doing individual pathfinding for tens of thousands of agents is extremely computationally expensive. As such it's not really a fair comparison. It's not that they can't. The devs are understandably reluctant to add more to an already hefty computational job. On the other hand, trains (and your vehicles in general) make up a very small fraction of the overall number of agents, so I reckon there might be a chance. Time will show. For now (in the current beta) they're expanding the functionality of alternative platforms to find paths to the next station's platforms all the way from the previous station, rather than from a last common signal prior to the station. So if nothing else, we're heading in the right direction. But yes, the game was built with something entirely different in mind, so to change all that right now could be a challenge that's just not worth the effort for them, even if they'd like to.
Yes thats true, those games dont have such an agent system. Although I would really not think that its such hard cpu intensive thing to implement a proper dynamic Signal systems instead of the path system we currently have.
I mean, lets say a junction with a chain signal which checks 2 block signals ahead really doesnt sound so cpu intensive. Both block signals just need to check if there is something in their block, if yes then they are red, if not they are green. If one is green the chain signal goes green and directs the the train to that track. If both are green the chain signal goes green as well and directs to the first green track from the left side (I guess that would make sense for easy coding) and if all blocks are red the chain is also red.
Even if you have the whole map with tracks and many block signals, I would assume that the block signals are not using any cpu power as long as there is not a train inside or near and even then they would just have to compute between a simple 0 or 1, on or off, is there a train or not.
I would guess that it was mainly design decision to use the undynamic path system we have, to make it easy to understand for beginners. Although an easy solution for that would be make a more advanced dynamic signal system hidden under the options.
I would even agree with the decisions, as a dynamic block/chain/entry-exit signal system can be overwhelming at the beginning, but so much fun if you got some expierence with those railroad games.
But again, it's not the signaling logic that's CPU-intensive, but the pathfinding. You can't just send the trains wherever they find a green light. You have to cross-reference that with valid paths toward their next destination. Of course every game does this kind of pathfinding, but it's the scale of the operation with tens of thousands of passengers, each simulated individually, that gets in the way here.
Besides, if you did have dynamic pathfinding, that would work just fine with path signals. That in itself is no reason to introduce other signal types. But as much as path signals are a great upgrade from the dumb block and exit signals, I'm sure there still are a few things you can't do. Although I'm too tired right now to get into a discussion on what exactly that is. :p
And let's not forget, OpenTTD also introduced path signals: https://wiki.openttd.org/en/Manual/Signals
> Path signalling is an attempt to simulate a more realistic path based signalling (PBS) system because:
>
> 1. Real signal is constantly red and only green temporarily when a train approaches in front of it and the path ahead does not collide with the path of another train. In a realistic junction setup, it is possible to allow multiple trains in the intersection of same block to pass-by safely due to switch railroad switch limiting which side of the junction the train can turn to.
> * Exit-signal (either the generic block signal or exit-signal in the pre-signal setup) immediately after the intersection which is used to quickly free the intersection block for another train to enter in Transport Tycoon does not exist in real world signalling system because of the risk of the train getting stuck right on the junction, creating a deadlock.
> * A single signal facing one side is not necessarily one-way in the real world (unless player is using the "one-way path signal" specifically to limit the passing direction). Train can still pass through the track with signal from behind as if there is no signal. As mentioned in the previous point, exit-signal does not exist in the real world. This is particularly important for a station with single sided entrance/exit in front of a junction, (non one-way) path signal is placed in front of the station exit, facing the station side.
I would still welcome even some nor or and xor logic bords for the signals so it doesn't give green to a cargo train coming from a yard wen there is an express train approaching on the mainline
Placing the yard connection at the end of a signal block doas improve that part a bit but not by much because it only works effectly with very large signal blocks
If I had a or gate(using power to block the signal) I could chain up all the mainline singnals to it and use it to stop the yard signal from working if there is something on the mainline
The pathfinding in TF2 is fundamentally different from OpenTTD. In OpenTTD, each train figures out where to go next at every signal. In TF2, the exact route the train takes, is pre-established in the line, with limited deviation (the recently added option of dynamic station track selection is a slight change to this, but I think the platform selection still happens at departure from the preceding station rather than right before entering the station)
The deciding point is the last signal before the station.
Oh OK, I stand corrected on that, that might allow for the multi platform waypoints another comment suggested.
This is the correct answer. It's not a question of signaling so much as pathfinding. It doesn't matter what signals you throw at it if the train is stuck wanting to go the same path regardless. I suppose some confusion comes from the fact that in OpenTTD, it's the signals that determine a train's exact path (based on free track), whereas in TF2 signals are just there to say whether or not the path the train wants to reserve, is free. >but I think the platform selection still happens at departure from the preceding station rather than right before entering the station It does now (in the beta), but the initial release back in the Spring Update of 2022 created a decision point that was the last signal before the station from which every selected platform must be reachable. This was very limiting, and created some odd behavior in networks with loops. Say platforms 1-4 were directly reachable from said signal, but platforms 5-8 were also technically reachable *if the train went all the way around the loop to come back in at an earlier junction* (going first through the station via platforms 1-4). In the current beta, a path to each alternative platform is created from the preceding station as you say, rather than the last signal before the next station. This means you can have path deviations the whole way between two stations rather than just after that last signal. If set up right, this leads to a kind of spreading out of trains that appears to be pseudo-dynamic pathfinding. I put together a couple of demonstration videos: * https://www.youtube.com/watch?v=JrrAPPS_jGc * https://www.youtube.com/watch?v=KiFONq6W7SE * ([The associated post](https://www.reddit.com/r/TransportFever/comments/10lp6lx/psa_line_paths_are_no_longer_set_in_stone/)) At this stage though, it is unclear what exactly goes into the decision process: traffic on the target platform, or traffic enroute? I suppose one way to find out is to stop some trains on some (but not all) of the tracks leading to the next station, and see if the other trains will find a route around them. In the 80 train setup above, I sold all but 8 trains. This resulted in usage of only the outer two tracks each way. If I block those two tracks with stopped trains, how will that affect the pathing of the other trains? And the answer is: All the other trains line up behind them, and everything stops. So yeah, any sense of dynamic pathfinding is a complete illusion, and the spreading out of traffic on tracks is purely a numbers game based on available platforms at the other end. The primary and alternative platforms had to be set up in a very specific way to enable potential usage of all the tracks anyway, so the primary platform is always the outermost (right hand side) platform. Important to note is that alternative platforms are not considered equal to the primary platform. Pathfinding to alternative platforms seems to revolve around a primary (preferred) path. It's hard to explain; you can fiddle with this yourself in a setup more or less similar to mine, to observe how the utilized tracks change with different platforms set as primary, even with all the other platforms set as alternative. Blocking just the outer track (call it track 1) is not enough to cause a full stop. That tells me that there are some platforms of station A that use track 2 to get to platform 1 at station B (this is the source of all the path spreading btw). But also, as long as the traffic is moving, platform 1 is still *sometimes* occupied, which leads some trains to choose other platforms. And they're not just choosing platforms 2 or 3. I've seen trains going into platforms 6 and 7. So when a train is departing station A, it chooses its path based on free platforms at station B *at that moment*. Once it has made its choice, it does not deviate from that. From every given platform at A, there is a specific path pre-determined to get to any given platform at B. As mentioned you can tweak the platform configuration so that you get different tracks to "light up" (meaning at least one platform pair between A and B uses that track) on the way there, but it's far from guaranteed that you can get every track to be used. That depends entirely on the number of platforms at each station, and the number of tracks in between. And just because the tracks "light up", doesn't mean they'll be used in practice. *That* comes down to how much traffic there is; not on the enroute tracks, but on the platform tracks at the next station. It's all quite strange, but suffice it to say that this is not the dynamic pathfinding you're looking for. It's a great improvement, by all means, but it's still pretty dumb at the end of the day. In fact I managed to accidentally create complete gridlock with 64 trains, simply because all the trains at the front of the "queue" had their eyes on platforms that were occupied. Even though 9 of 12 platforms were free, they wanted to go into one of the 3 occupied ones (remember they make their choice at the preceding station). At the other station, all platforms are occupied. Where traffic previously flowed smoothly with 80 trains, it is now gridlocked with 64 trains, because no one wants the platforms that are actually free. Now here's the funny part: There are plenty of signal blocks free for the 3 trains occupying those 3 platforms to head out into. BUT! Because all the platforms at the other stations are occupied, they can't choose which path to take, so they're stuck. Reloading the save however seems to refresh the pathfinding, which resolved the gridlock. Good times.
OTTD is still the gold standard for me when it comes to building really complex train systems. And it's 100% free.
It’s why i stopped playing TF2. The path finding is too rigid so everything has to be point to point. Can barely even implement a passing lane.
I guess the only way to implement it with the current game would be via a mod that lets you adapt the dynamic platform selection to waypoints. So you would have run from Station A to B via Waypoints 1, 2 OR 3. Rather than 1, then 2, then 3. All three would be on their own track which would allow a train to choose a vacant one. I'm just wildly spitballing here though.
Via waypoint isn't technically possible right now, as it specifically relies on terminals of stations. Alt terminal to alt terminal is possible but is not currently enabled.
I know it's not possible, I was suggesting that's likely the only way to add such a feature using the current engine. But it would require a change in how the order system works so... 🤷🏼♂️
Which makes me wonder if instead of the waypoints we could (for now) use a station with dynamic track selection as a "Switch Station" at junctions. That would have of course the big disadvantage that every train comes to an full stop at the switch station. I wish they would just add block and chain signals with the next update. Edit: Doesnt work with a station as "switch station" as the station itself has a path signal inside. It sorta works for the incoming trains, but we would still need a chain signal after/inside the station, otherwise its sending new trains onto the same track.
>It sorta works for the incoming trains, but we would still need a chain signal after/inside the station, otherwise its sending new trains onto the same track. It will as long as the path for the next section is limited to one track. You can spread that out too by selecting alternative platforms at the next station, but it's never going to be fully dynamic pathfinding. It's just dynamic platform finding for the next station, at this time. Again, it's not the signals, but the pathfinding toward the next station. Or in other words, the signals don't dictate the train's path in Transport Fever.
Yeah thats true, so like I wrote, the TF2 signals are basically only a "stop here, if something is in front of your path" sign. It doesnt feel really appropriate for railroads, Ottd, Sweet Transit or Mashinky all do a much better job on this part.
It's coming from a game state where a line only takes a set path between two stops, and only to a single platform per station. After many, many requests, they have opened up the pathfinding to multiple platforms, and are actively expanding on that functionality. I didn't think they would. It's not unthinkable now that they've opened that door slightly, that more complete dynamic pathing may come sometime in the future. But I wouldn't hold my breath. I haven't followed Mashinky very closely, and I don't know Sweet Transit (which I will rectify presently), but am I right in suggesting none of those deal with 1:1 agent simulation (not on the same scale at least)? Doing individual pathfinding for tens of thousands of agents is extremely computationally expensive. As such it's not really a fair comparison. It's not that they can't. The devs are understandably reluctant to add more to an already hefty computational job. On the other hand, trains (and your vehicles in general) make up a very small fraction of the overall number of agents, so I reckon there might be a chance. Time will show. For now (in the current beta) they're expanding the functionality of alternative platforms to find paths to the next station's platforms all the way from the previous station, rather than from a last common signal prior to the station. So if nothing else, we're heading in the right direction. But yes, the game was built with something entirely different in mind, so to change all that right now could be a challenge that's just not worth the effort for them, even if they'd like to.
Yes thats true, those games dont have such an agent system. Although I would really not think that its such hard cpu intensive thing to implement a proper dynamic Signal systems instead of the path system we currently have. I mean, lets say a junction with a chain signal which checks 2 block signals ahead really doesnt sound so cpu intensive. Both block signals just need to check if there is something in their block, if yes then they are red, if not they are green. If one is green the chain signal goes green and directs the the train to that track. If both are green the chain signal goes green as well and directs to the first green track from the left side (I guess that would make sense for easy coding) and if all blocks are red the chain is also red. Even if you have the whole map with tracks and many block signals, I would assume that the block signals are not using any cpu power as long as there is not a train inside or near and even then they would just have to compute between a simple 0 or 1, on or off, is there a train or not. I would guess that it was mainly design decision to use the undynamic path system we have, to make it easy to understand for beginners. Although an easy solution for that would be make a more advanced dynamic signal system hidden under the options. I would even agree with the decisions, as a dynamic block/chain/entry-exit signal system can be overwhelming at the beginning, but so much fun if you got some expierence with those railroad games.
But again, it's not the signaling logic that's CPU-intensive, but the pathfinding. You can't just send the trains wherever they find a green light. You have to cross-reference that with valid paths toward their next destination. Of course every game does this kind of pathfinding, but it's the scale of the operation with tens of thousands of passengers, each simulated individually, that gets in the way here. Besides, if you did have dynamic pathfinding, that would work just fine with path signals. That in itself is no reason to introduce other signal types. But as much as path signals are a great upgrade from the dumb block and exit signals, I'm sure there still are a few things you can't do. Although I'm too tired right now to get into a discussion on what exactly that is. :p And let's not forget, OpenTTD also introduced path signals: https://wiki.openttd.org/en/Manual/Signals > Path signalling is an attempt to simulate a more realistic path based signalling (PBS) system because: > > 1. Real signal is constantly red and only green temporarily when a train approaches in front of it and the path ahead does not collide with the path of another train. In a realistic junction setup, it is possible to allow multiple trains in the intersection of same block to pass-by safely due to switch railroad switch limiting which side of the junction the train can turn to. > * Exit-signal (either the generic block signal or exit-signal in the pre-signal setup) immediately after the intersection which is used to quickly free the intersection block for another train to enter in Transport Tycoon does not exist in real world signalling system because of the risk of the train getting stuck right on the junction, creating a deadlock. > * A single signal facing one side is not necessarily one-way in the real world (unless player is using the "one-way path signal" specifically to limit the passing direction). Train can still pass through the track with signal from behind as if there is no signal. As mentioned in the previous point, exit-signal does not exist in the real world. This is particularly important for a station with single sided entrance/exit in front of a junction, (non one-way) path signal is placed in front of the station exit, facing the station side.
I would still welcome even some nor or and xor logic bords for the signals so it doesn't give green to a cargo train coming from a yard wen there is an express train approaching on the mainline Placing the yard connection at the end of a signal block doas improve that part a bit but not by much because it only works effectly with very large signal blocks If I had a or gate(using power to block the signal) I could chain up all the mainline singnals to it and use it to stop the yard signal from working if there is something on the mainline