[2.0.11] Train pathfinding takes much longer path

[robot256]

A "path" as defined in Factorio is a series of sequential rail blocks that can be reserved in one direction from A to B. You are trying to redefine it to be "any way to drive a train without violating signals".

How would the train identify that path? It would have to know how long the train is, identify a long enough stopping point beyond the junction, and then calculate the remaining path from there. If there were multiple possible reversing points/junctions, it would have to compare them all. If both reversing and non-reversing paths are available, would calculate the reversing time penalty based on current braking level?

That would have a significant effect on performance and, more importantly, add hundreds of new edge cases and potential bugs.

[BlueTemplar]

Yes - so thank you for providing an even more detailed explanation about why it's (probably) not worth fixing.

[BraveCaperCat]

A "path" as defined in Factorio is a series of sequential rail blocks that can be reserved in one direction from A to B. You are trying to redefine it to be "any way to drive a train without violating signals".

How would the train identify that path? It would have to know how long the train is, identify a long enough stopping point beyond the junction, and then calculate the remaining path from there. If there were multiple possible reversing points/junctions, it would have to compare them all. If both reversing and non-reversing paths are available, would calculate the reversing time penalty based on current braking level?

That would have a significant effect on performance and, more importantly, add hundreds of new edge cases and potential bugs.

No, they're not trying to redefine anything. Assume for a second that the junctions are all one block. Now, you said that a path is a series of sequential rail blocks, this could mean the direction used to enter the junction, then the direction used to exit it. The entrance direction is set in stone, but the exit direction could be any one of the other directions connected to the junction-block. This includes directions requiring reversal(s) to reach from the start path.

To generalise the statement above for any junction, not just the ones which are made of one rail block, I say that every multi-block junction must be made out of smaller single-block junctions and non-junction blocks, as a junction-block could be as simple as the point one rail branches off from another (where the curved rail-entity connects with the straight one), surrounded by signals of course. As every such point must be entirely within a block, the generalisation is true.

If the above statements hold, then paths with reversals are completely allowed within your definition.

[robot256]

A "path" as defined in Factorio is a series of sequential rail blocks that can be reserved in one direction from A to B.

If the above statements hold, then paths with reversals are completely allowed within your definition.

If you want to be that pedantic, maybe try reading the whole sentence first. Plus my definition doesn't even matter, I'm not a dev. Have a nice day

[BraveCaperCat]

A "path" as defined in Factorio is a series of sequential rail blocks that can be reserved in one direction from A to B.

If the above statements hold, then paths with reversals are completely allowed within your definition.

If you want to be that pedantic, maybe try reading the whole sentence first. Plus my definition doesn't even matter, I'm not a dev. Have a nice day

You said this:

A "path" as defined in Factorio is a series of sequential rail blocks that can be reserved in one direction from A to B.

The statement I have shown you says that sequential rail blocks can include reversals. You are saying that such a sequence of blocks can be reserved in one direction from A to B. Note that means I cannot use any block more than once. I can now perform a reversal inside a junction-block and the additional rule you specified is satisfied. Please do not derail this topic.

[robot256]

I apologize for making my first comment without reading the OP more closely--it's an interesting observation since it does make paths in both directions but doesn't appear to choose the shortest one.

The topic was derailed when BlueTemplar brought up the concept of paths that change direction midway, which has nothing to do with the OP's case of making single-direction paths from a standstill. I thought it was clear that when I wrote "in one direction", I meant the train was traveling in one direction (forward or reverse) over all the rail segments, sorry for not being more clear.

[BraveCaperCat]

I apologize for making my first comment without reading the OP more closely--it's an interesting observation since it does make paths in both directions but doesn't appear to choose the shortest one.

The topic was derailed when BlueTemplar brought up the concept of paths that change direction midway, which has nothing to do with the OP's case of making single-direction paths from a standstill. I thought it was clear that when I wrote "in one direction", I meant the train was traveling in one direction (forward or reverse) over all the rail segments, sorry for not being more clear.

Ah. Sorry for the confusion. Though that is a really good idea for a feature - so, I've created a new topic in Ideas & Suggestions about implementing this.

[boskid]

Annoying part of this is that its caused by goal being in the middle of a rail segment as it happens only with temporary rail targets. All standard cases where trains pathfinder is running have their goal at the end of rail segment as the split is forced by a train stop entity placement next to a rail. Trains pathfinder does not account for goal being in the middle of rail segment so the effective penalty of the goal is as if the entire rail segment was to be travelled which means trains pathfinder will always prefer a path that does not cross rail segment boundary (there is always a rail segment boundary even when it is a loop): by crossing rail segment boundary a path penalty is part that leaves rail segment + full length of the goal rail segment, while staying within rail segment has only penalty of the goal rail segment. Annoying part is that to handle just this case that can happen when using rail targets i would have to do some intrusive changes for the trains pathfinder logic that is used also in normal cases since i would have to create temporary nodes related to goals that are in the middle of rail segments.

[SteelGiant]

Annoying part of this is that its caused by goal being in the middle of a rail segment as it happens only with temporary rail targets. All standard cases where trains pathfinder is running have their goal at the end of rail segment as the split is forced by a train stop entity placement next to a rail. Trains pathfinder does not account for goal being in the middle of rail segment so the effective penalty of the goal is as if the entire rail segment was to be travelled which means trains pathfinder will always prefer a path that does not cross rail segment boundary (there is always a rail segment boundary even when it is a loop): by crossing rail segment boundary a path penalty is part that leaves rail segment + full length of the goal rail segment, while staying within rail segment has only penalty of the goal rail segment. Annoying part is that to handle just this case that can happen when using rail targets i would have to do some intrusive changes for the trains pathfinder logic that is used also in normal cases since i would have to create temporary nodes related to goals that are in the middle of rail segments.

Sounds like time for a dirty hack where temporary targets act as if they have a segment break either side of them!