Attila7 wrote:

I have done some digging into this problem and it seems that the error is deep within the pathfinder, more specifically at line 130 in follow_track.hpp. Code on this line is trying to determine if the next tile has any tracks, but does not care in which direction they are going.

Looking at the screenshot I uploaded above, when the pathfinder is looking for the next tile at the end of the road it finds that the tile at the top of the hill has track bits, even though it cannot get there. So, QueryNewTileTrackStatus returns ROAD_Y and the TryReverse routine is not called. Pathfinding fails on the next line when CanEnterNewTile fails.

If the road tile at the top of the hill is removed, the nearest depot is properly found, because there will be no track bits returned for that tile and the TryReverse routine will be called.

If a drive-through station is placed on the top of the hill and the bus is told to go there instead of the nearest depot, the bus will go there correctly. This seems to be because a search for the path to the next station is not done immediately when the bus leaves the station. The bus goes to the next junction and it looks for its destination at this point only. By then it has turned around and the pathfinder reversing problem has been avoided.

I would appreciate a fix for this as my AI tries to send vehicles to the nearest depot via conditional orders when they get old. Because of this bug, vehicles never go to the depot and are never renewed on routes where vehicles need to turn around after going through a drive-through station.

This comment was imported from FlySpray: https://bugs.openttd.org/task/4130#comment8811

Attila7 wrote:

double post

This comment was imported from FlySpray: https://bugs.openttd.org/task/4130#comment8812

Rubidium closed the ticket.

Reason for closing: Fixed

In r21229. Your analysis was a great help, though it wasn't the CanEnterNewTile line that caused the problem.

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