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.

Sign up for GitHub

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

Jump to bottom

Inconsistant yapf.rail_pbs_cross_penalty #2722

Closed
DorpsGek opened this issue Mar 11, 2009 · 3 comments
Closed

Inconsistant yapf.rail_pbs_cross_penalty #2722

DorpsGek opened this issue Mar 11, 2009 · 3 comments
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)

Comments

@DorpsGek
Copy link
Member

IguannaB opened the ticket and wrote:

Please see attached pic (savegame to reproduce)

I think there are a couple of minor problems due to the yapf.rail_pbs_cross_penalty being applied in non path signal blocks.

  1. The penalty due to a train ahead on bridges and tunnels varies greatly depending on whether the train is at the start or end, and neither case results in a penalty the same as you would get due to a train ahead on normal track. This can override the look-ahead signal penalties and mess up the load balancing if there are tunnels/bridges in the area after the branch.

  2. If the yapf.rail_pbs_cross_penalty is set higher (eg 3000), the penalty resulting from a train ahead in the look ahead zone can easily exceed ones like yapf.rail_firstred_exit_penalty (10,000). I had a large station where traffic ahead was causing trains to go to occupied platforms instead of free ones because of this. As far as I know, increasing the pbs_cross is the only way to make trains use detours rather instead of stopping and waiting at path signals, so leaving it at default 300 is not always possible.

Solution?
I wonder whether it might be better to make is so the yapf.rail_pbs_cross_penalty was not applied if the last signal passed was a non-path signal, as this would solve both those issues. This would effectively mean the penalty only applies in path signal blocks and not in the normal signal blocks where I don't know that it is needed for anything. The path under the trains can still be reserved.

I had a quick look into how this might be implemented, and I think it maybe possible to check the n.m_segment->m_last_signal_tile to determine what type the last signal passed by the track follower was. I'm not sure, but I think the last_signal_tile of the current segment or any parents is the last signal which was passed so probably this could be used. But I've spent as much time looking at it as I want to now, sorry to say - I don't enjoy programming like I used to.

There was a little discussion about this, and how the penalty is applied over bridges and tunnels in this thread http://www.tt-forums.net/viewtopic.php?f=31&t=42094

Attachments

Reported version: 0.7.0-beta2
Operating system: Windows

This issue was imported from FlySpray: https://bugs.openttd.org/task/2722
@DorpsGek
Copy link
Member Author

Rubidium wrote:

The signal before a signal block doesn't tell whether that block is (or is not) a PBS signal block; you can enter a PBS signal block via a normal signal, but you will only enter when there is no train in that whole block.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2722#comment5762

@DorpsGek
Copy link
Member Author

IguannaB wrote:

Yeah, what I said in the details was not exactly right. Maybe I should have said 'where the last signal was a non-PBS signal' rather than 'normal signal blocks' etc. but I tired to keep it short.

Actually I thought about the scenario you describe earlier and came to the conclusion that there would be no problem. Having the penalty applied in PBS blocks when the path being considered enters them via a normal signal would be fine, as there is no need for the penalty in this case since a train taking this path does not use any PBS signals. It would still be applied for all paths which enter blocks via a PBS signals, where the train would need to reserve a path, and I suspect this is the only time the penalty is needed. So the type of the block being entered is not really what is important, rather the type of signal which is used to enter it. Just some thoughts anyway.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2722#comment5765

@DorpsGek
Copy link
Member Author

Rubidium closed the ticket.

Reason for closing: Fixed

In r18535

This comment was imported from FlySpray: https://bugs.openttd.org/task/2722

@DorpsGek DorpsGek added flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) bug labels Apr 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@DorpsGek