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

[Bug]: Train fails to pick free path through the station, resulting in trains getting stuck #9609

Open
baysupercool opened this issue Oct 11, 2021 · 8 comments

Comments

@baysupercool
Copy link

@baysupercool baysupercool commented Oct 11, 2021

Version of OpenTTD

1.11.2, Windows 10

Expected result

Train picks the path through the station

Actual result

Train always picks the passing track, and if there is already another train in the passing track, it does not pick the other track through the station. Depending on the situation this can result in both trains to become stuck forever.

Steps to reproduce

bug

  1. Copy the shown track schematic. Red tiles are stations. Signals in front of the stations are one way path signals. The rest are two way path signals.
  2. Buy two trains and set their orders to go non-stop to both end stations. The trains should not stop at the middle station.
  3. Send the trains to the track.
  4. Eventually trains get stuck facing each other. I can consistently replicate this issue.
@LordAro
Copy link
Member

@LordAro LordAro commented Oct 11, 2021

Can you provide a savegame exhibiting this behaviour?

Loading

@LordAro
Copy link
Member

@LordAro LordAro commented Oct 11, 2021

Went ahead and did it myself anyway. I wonder if this might be pathfinder-caching related...

image

Loading

@James103
Copy link
Contributor

@James103 James103 commented Oct 11, 2021

Here's my reproduction attempt:
image
Save game: #9609 testing.zip

Loading

@glx22
Copy link
Contributor

@glx22 glx22 commented Oct 11, 2021

Wondering if #9554 could have a similar cause.

Loading

@frosch123
Copy link
Member

@frosch123 frosch123 commented Oct 11, 2021

The relevant pathfinder penalties are: (default values)

  • pf.yapf.rail_pbs_signal_back_penalty = 15 * YAPF_TILE_LENGTH (once per signal)
  • pf.yapf.rail_station_penalty = 10 * YAPF_TILE_LENGTH (per station tile)

So, currently it will prefer waiting for the reverse-pbs signal, if the station platforms are longer than 1 tile.

I think the problem here is the station penalty:

  • The penalty is currently per tile, because this is part of the "pathfinder prefers platform matching train length".
  • But this makes no sense, if the train passes through anyway.

So, I think there should be two different station penalties:

  • A penalty per station tile, if the train will stop at the station.
  • A penalty independent of platform length, if the train will not stop at the station.

Loading

@glx22
Copy link
Contributor

@glx22 glx22 commented Oct 19, 2021

Tried the save game with NPF, trains don't use middle track with it.
So with YAPF trains always prefer to use middle track, and with NPF they never want to use it.

Loading

@JGRennison
Copy link
Contributor

@JGRennison JGRennison commented Oct 19, 2021

To follow on from earlier comments, there are two further YAPF penalties which need to be considered for this type of layout:
rail_pbs_cross_penalty and rail_pbs_station_penalty.

rail_pbs_cross_penalty is the per-tile penalty for a reserved non-station tile.
In many cases the total cost is different depending on how long the train is and how far away it is from the signal it is approaching.
In this type of layout, if you are unlucky you could have different behaviour for short trains blocking the middle track than for long ones.
This defaults to 3 * YAPF_TILE_LENGTH.

rail_pbs_station_penalty is the per-tile for a reserved station tile. As station platforms are always reserved either not at all or in their entirety, the total penalty is proportional to the platform length, and is predictable.
This defaults to 8 * YAPF_TILE_LENGTH.

The problem here is that the cumulative rail_pbs_cross_penalty cost of the occupied centre track is too small to make the centre path more expensive than going via the platform.

I happen to use a similar layout frequently in my own games, except that going via the platforms is the normal path, and the centre track is only used for bypassing trains when the platform is occupied. To make this work the cost of the centre track is artificially made more expensive than the cost via the platform but less expensive than the cost via the platform when occupied.

So, I think there should be two different station penalties

The trouble with this is that it makes the track cost a function of the instantaneous state of the vehicle which is problematic for the segment cost caching which is used outside of the signal look-ahead distance.
You could do this only inside the signal look-ahead distance but this creates the risk of inconsistent pathfinding.

Loading

@Eddi-z
Copy link
Contributor

@Eddi-z Eddi-z commented Oct 19, 2021

You could do this only inside the signal look-ahead distance but this creates the risk of inconsistent pathfinding.

I don't quite see the problem with this. By the time you arrive at the station from outside the lookahead distance, the situation probably changed anyway.

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants