Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mexican Stand-off #8128

Closed
Mysteron347 opened this issue May 9, 2020 · 2 comments
Closed

Mexican Stand-off #8128

Mysteron347 opened this issue May 9, 2020 · 2 comments

Comments

@Mysteron347
Copy link

Version 1.10.1

Result: Allowing the scenario to run, train "B" and "C" stop, facing each other. Ditto "D" and "E".
Reversing "B" will trigger "C" to use clear path - whether "B" is moving or stopped. "D" has to be reversed until it resumes its original direction of travel by taking the loop - only then will "E" start.

Expected: Both "C" and "E" should take the alternative path without "B" / "D" needing to reverse.
test2.zip

@nielsmh
Copy link
Contributor

nielsmh commented May 9, 2020

Initial situation:
image

If I remove the opposite-facing (two-way) path signal on the passing track, a train chooses a route through it:
image

It looks like the PF does not want to reserve a path through an opposite-facing path signal.

Note that your design goes against the usual recommendations, and against prototypical railroad design. Your path signals on the single-line segments of the network are what I would consider unsafe, as they can allow a train to wait in a position where it can deadlock with trains wanting to pass the opposite direction.
The following setup works:
image

@Yexo
Copy link
Contributor

Yexo commented May 29, 2020

While it's possible to tweak the pathfinder costs so it doesn't cause this particular deadlock, in general that's not possible. What happens here is that the cost of going around is higher than the cost of the train standing still on the tracks in front of it (the small train length has a large influence here to make that cost low). The PF makes the assumptions that trains in front of it will eventually move, and in this case it thinks that going around is more expensive than waiting.

You can resolve this on your tracks by not allowing trains to stop where they would be blocking other trains. If the South-east signal was not present for example, the train couldn't have stopped there and would have gone to the bypass route directly.

Closing this as it doesn't seem feasible to make code-changes to prevent such situations.

@Yexo Yexo closed this as completed May 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants