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

Jump to bottom

Wrongfully bad signal #109

Closed
DorpsGek opened this issue Apr 10, 2006 · 5 comments
Closed

Wrongfully bad signal #109

DorpsGek opened this issue Apr 10, 2006 · 5 comments
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)

Comments

@DorpsGek
Copy link
Member

ghostmaster opened the ticket and wrote:

I'm playing with r4264.

It is a rarely emerging bug, since to reproduce it, the order of steps shown in the screenshot is neccesary.
* First build the depot
* Then train half inside the depot
* Then line to the end of the depot
After these the signal turns erroneously red and remains that way even if the depot is removed.

Before one would ask why would anyone build a dead end line to the back of a depot, I would tell that the bug exists if you place a station to the back of the depot and the signal do not let trains enter the station.

Attachments

Reported version: trunk
Operating system: All

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

Darkvater wrote:

In 0.4.7 signal does indeed turn red in steps 1/2 but once the depot is removed the signals are green again and if the train enters the depot again, the signal is also green.
So it is indeed a bug but not in the severity as in the bugreport.

Confirmed that trunk (r4608) exhibits this exact same problem. I thought that PF planning through depots was fixed some time ago?

This comment was imported from FlySpray: https://bugs.openttd.org/task/109#comment245

@DorpsGek
Copy link
Member Author

DorpsGek commented May 2, 2006

Darkvater wrote:

Proposed fix by glx

Attachments

This comment was imported from FlySpray: https://bugs.openttd.org/task/109#comment250

@DorpsGek
Copy link
Member Author

DorpsGek commented May 3, 2006

glx wrote:

I've made a patch that seems to work.

This is what it does : when the "signal updater"-pathfinder enter in depot from wrong side, there's no need to check if a train is running in the depot (because you can't collide with it). I think there are no side-effects, because the modified function is only used for signals.

Edit: Darkvater was faster than me to attach the file :)

Attachments

This comment was imported from FlySpray: https://bugs.openttd.org/task/109#comment251

@DorpsGek
Copy link
Member Author

DorpsGek commented May 3, 2006

KUDr wrote:

r4715: - Fix: (#109) — Wrongfully bad signal - Don't allow OPF to enter train depot from the back

I had the same problem with road depots in the YAPF branch after updating GetTileTrackStatus() to report track in it (r4419). I fixed the OPF for road depots in r4442 using the same way. Hope it will work.

This comment was imported from FlySpray: https://bugs.openttd.org/task/109#comment252

@DorpsGek
Copy link
Member Author

DorpsGek commented May 3, 2006

Celestar closed the ticket.

Reason for closing: Fixed

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

@DorpsGek DorpsGek closed this as completed May 3, 2006
@DorpsGek DorpsGek added Core flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) 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