Implicit rail signals every tile...?

[myridium]

Hello, after playing this game for a long time I have realised that when placing rail signals, a common paradigm is placing down highways of rail with standard rail signals placed every so often along the way.

Ideally, one would place standard rail signals every tile along the side of a track. This allows trains to squeeze in close together. And, for chain rail signals, placing a chain signal every tile along a simple (i.e. no intersection) rail segment is equivalent to having just one chain signal at the beginning of that segment. As for intersections, one tries to place the rail signals in such a way as to minimise unnecessary waiting when the path is clear.

I question why the rail signals are designed this way. I think that when a rail signal (normal or chain) is placed, that should indicate to the rail network that every tile beyond that point along the line, up to an intersection/fork or a different rail signal type, has that same rail signal in place.

Now I don't know how the rail's block system works in detail, but I'm fairly sure this wouldn't add any significant computational complexity as it doesn't affect pathfinding or have any influence on intersections. Basically the only difference to behaviour would be that trains squeeze up close together whenever in a 'normal signal segment'. But for the player, this would alleviate the need to put down a ton of normal rail signals all the time, weighing up how often to put them down on a straight rail segment.

E.g. here is an example of the effect that would have. Rail signals placed on left copy, and 'interpreted behaviour' is shown on the copy on the right. The one on the right is technically superior, because it allows two 1-segment trains (e.g. locomotives) to park behind each other in a couple of places where they could get out of the way of a train behind them that was going the other way and whose path was clear and didn't need to wait.

20200418211652_1.jpg (1.05 MiB) Viewed 2062 times

This is just a toy example. It's a minor thing but it seems like a strict improvement. It improves the efficiency of railway lines, reduces space requirements, and removes the inconvenience of having to place so many damn signals on rail highways especially.

[astroshak]

Actually, it would affect pathfinding.

Each signal separates the rail into more Blocks. In that left picture, a train going on the bottom rail from left to right would enter fewer blocks than the train taking the same route on the right picture.

Trains do not seek the shortest *distance* they seek the smallest number of *blocks*. This is why a stacker works so well; from the first chain signal to the first rail signal (in a properly signaled stacker) it is the same number of blocks regardless of which actual parking space is used. The same thing for leaving the stacker going to the station; the same number of blocks regardless of which station (assuming all stations are in parallel and there are no stations in a series) means that each station has the same distance.

If you were to put all kinda of chain signals on the exit of a stacker, then trains would favor the physically closest station, simply due to the increased number of blocks as the stations move further from the stacker.

For straight, turns, etc. sections of rail, it may not appear to do much. Simply due to distance a further away mine is going to require the train to pass through more blocks than the closer mine, already, and increasing the number of blocks to one per tile won’t change that. What it might change is the time the pathfinder needs to process the paths, due to the dramatic increase in number of blocks.

[Jap2.0]

Ideally, one would place standard rail signals every tile along the side of a track. This allows trains to squeeze in close together.

Correct - however, if your rail network is congested enough that this could be of significant benefit, you already have an extremely congested rail network and might want to consider widening it. Additionally, trains keep enough space between them and the next red signal that they have enough room to stop, so they will not get very close to other trains unless they are going very slowly, in which case, again, you probably have a very congested train network. If they stop, you will get the same space efficiency by having signals placed with a distance the length of one train between them.

Thus, it is very little practical benefit, especially for well-designed train networks.

Now I don't know how the rail's block system works in detail, but I'm fairly sure this wouldn't add any significant computational complexity as it doesn't affect pathfinding or have any influence on intersections.

Incorrect. Rail signals divide the rail network into segments (nodes on a pathfinder), and the more segments the pathfinder has to go through, the longer it will take.

[Jap2.0]

You beat me to it!

Trains do not seek the shortest *distance* they seek the smallest number of *blocks*.

This is actually also incorrect (although it could still affect pathfinding). The penalty for one block in the pathfinder is equal to the length of the block. It could affect pathfinding in that when a signal is red, the penalty that gives is also based on the length of the block - so a train in a long block will give more of a penalty than a train in a short block. Not a huge difference, though.

[Optera]

I imagine performance would tank, updating all these tiny blocks instead of few big ones.

[myridium]

Do you guys know how pathfinding algorithms work? Splitting up a straight line segment into several of them is not going to affect performance in a well-designed path-finding algorithm. E.g. maintain a connected graph that only has nodes at intersections or when the rail signal changes.

If the path-finding treats every block of rail as a node then no wonder it's slow... this issue would be alleviated with the suggested change.

[PunPun]

Do you guys know how pathfinding algorithms work?

Umm yes we do.

Splitting up a straight line segment into several of them is not going to affect performance in a well-designed path-finding algorithm. E.g. maintain a connected graph that only has nodes at intersections or when the rail signal changes.

Yes it will. Maintaining that graph is going to cost more and you need additional logic to handle trains not running into eachother between the nodes.

If the path-finding treats every block of rail as a node then no wonder it's slow... this issue would be alleviated with the suggested change.

That's because it kinda has to. If it didn't then the logic to handle the path cost for segments that have trains in them would be more complicated and the end result would be harder to maintain code with probably worse performance. Trains would have to constantly look ahead of them to see if there is a train there instead of trusting that since the next block is free there is no train there causing massively worse performance. It would also break a lot of setups that rely on the current behaviour. And it would take time to implement. All that for a marginal increase in train throughput. No sane developer would even consider making this change.

The reason that train path-finding has been seen as slow is that it uses dijkstra and people have been making train networks that are basically the worst case for it. Or atleast it used to. I vaguely remember that it was going to be changed to A* at some point. Haven't checked if it actually was.

[boskid]

Having implicit rail signal every rail entity is a bad idea.
1/ performance: pathfinder uses segments, every extra signal would break rails into more segments and on every path search there would be more nodes to check
2/ intersections: in most cases when building intersection, on entrance and inside there will be chain signals and on exit there will be regular signal. By having implicit signals it would mean that if train is able to reserve even single rail after intersection, it would be allowed to go through intersection but because of the length of reserved segments after, it could have rest of rolling stocks still on intersection making it to jam.
3/ there would be also a problem of showing state of such signals since there would be no rail signal entities on map if they would be implicit

Having pathfinder with nodes on junctions maybe is possible to implement, but there would be a lot of issues of "what if there are multiple trains within given section of rails without intersections" (since there are signals inside and more trains is allowed) - every time looking into connection from one junction to another, it would require to go through all segments between junctions and so no performance gain would be here. At some point before 0.18.0 when doing fixes and optimisation i checked how would "rapid fast forward" on rail network work - every time when expanding node (which relates to a rail segment), if it has exit with only one next rail segment and if that rail segment has only one input from that side (simply saying: it is trivial junction of 1 to 1, most likely due to signal), advance 1 rail segment immediately - this way i was trying to reduce amount of min-heap interactions, but as i recall, it was slower because of overexpansion happening. Existing solution based on nodes over rail segments is a good solution and i see no point in changing it.

If the path-finding treats every block of rail as a node then no wonder it's slow.

It is not based on blocks, but on segments. Look into quick glossary in FFF-331. Two rail segments that intersect without a junctions are within single rail block but train cannot cross from one rail segment into another here so it could happen that train would be inside of a block from which there is a path to goal, but train would not be able to reach it because it would be on a wrong rail segment.

I vaguely remember that it was going to be changed to A* at some point. Haven't checked if it actually was.

Heuristic was added for 0.18.0 and this gave a huge speed boost for a trains pathfinder.