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

Trains not chosing closest platform on large station #2631

Closed
DorpsGek opened this issue Feb 14, 2009 · 5 comments
Closed

Trains not chosing closest platform on large station #2631

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

Comments

@DorpsGek
Copy link
Member

IguannaB opened the ticket and wrote:

Win XP, trunk r15471

In the attached save 'Big station pathfinder bug w problem.sav' there is 1 train running which should go to the top platform of the station, but instead it choses to go to one further away (pls see attached screenie). I'm pretty sure that the top station has a lower path cost from looking at the yapf debug. It seems to be related to the station size because reducing the size of the station by 2 platforms corrects it 'Big station pathfinder bug - station smaller, ok.sav'.

I tried to reproduce this in a new game, but couldn't 'Big Station pathfinder bug - not reproduced.sav'. I've got no idea why it works ok here.

Also, I changed some of the pathfinder settings earlier in the save with the problem, but I don't think this is the cause cuz I ran a script to set everything to default made from a config file created after renaming my old one. After doing this, I still got the same behavior.

There were other places where trains didn't seem to taking the lowest cost route too, which I thought might perhaps be related to whether there were trains on the platforms, so I went back to a save with no trains, and looked with just one then found this.

Also I was using copy and paste when I built this. Loading it in unmodified r15471 produces the same behaviour.

Attachments

Reported version: trunk
Operating system: Windows

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

Rubidium wrote:

The following YAPF settings are not set to the default: rail_lastred_penalty, rail_lastred_exit_penalty, rail_station_penalty, rail_curve45_penalty, rail_look_ahead_max_signals, road_slope_penalty. Some are even set so low that it might cause this issue.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2631#comment5575

@DorpsGek
Copy link
Member Author

IguannaB wrote:

Thanks for looking at this Rubidium.

I don't think the settings are the cause for couple of reasons:

  1. When I set them back to defaults (save attached), by executing 'defalut_settings.txt' (also attached) the problem still occurs. This script's is a bastardized config file r15471 made when I deleted the existing one, which I'm assuming sets everything to default values when it's run in console, as they are the values written to the config when it's created from scratch.
  2. Looking at the yapf debug output you get running 'defeloper = 5','debug_level yapf=5' shows it takes the higher cost path instead of the lower cost one it should take. The path cost towards the top platform, where it should go is reported to be 2297, compared to the cost of the path it actually takes, 3497 (shown in screen shot I attached earlier). I'm pretty certain this value is the cost for the path which yapf works out is best after being called at the branch. I had to delete a piece of track to force it to chose the lower cost (correct) path, and print the cost for that path.

Since it is not choosing a valid path with a lower cost, and this problem corrects if the station is made 2 platforms smaller, I suspect that maybe there is some code somewhere that causes it to not check for a path to the platform which it should be going to. Eg, something like, 'check tiles up to 28 tiles from the center of the station', when it should be checking maybe 32 tiles away, or something like that. Anyway I think something like this is causing it to ignore a valid path of lower cost. If I get a chance I'll have a look at the code tomorrow, maybe I can see something, but not very likely - yapf code makes my head spin.

Attachments

This comment was imported from FlySpray: https://bugs.openttd.org/task/2631#comment5579

@DorpsGek
Copy link
Member Author

IguannaB wrote:

I forgot to ask, which of those settings did you think might be the cause?

This comment was imported from FlySpray: https://bugs.openttd.org/task/2631#comment5580

@DorpsGek
Copy link
Member Author

frosch wrote:

The easiest fix for this would probably be:
http://devs.openttd.org/~frosch/diffs/fs2631.diff

Though maybe it is better (and more correct in sense of A*) to change the heuristic to use the nearest corner of station spread instead of center like NPF does.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2631#comment5581

@DorpsGek
Copy link
Member Author

Rubidium closed the ticket.

Reason for closing: Fixed

In r15518.

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

@DorpsGek DorpsGek added flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) Vehicles 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