FS#634 - Cannot order ship to depot - too far from previous destination

Attached to Project: OpenTTD
Opened by KeeperOfTheSoul (KeeperOfTheSoul) - Saturday, 17 February 2007, 23:52 GMT
Last edited by Jonathan Coome (Maedhros) - Sunday, 18 February 2007, 13:36 GMT
Type Bug
Category Core
Status Closed
Assigned To No-one
Operating System All
Severity High
Priority Normal
Reported Version trunk
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Revision: trunk@8787

Trying to assign the ship an order to go to the dock fails with the error STR_0210_TOO_FAR_FROM_PREVIOUS_DESTINATIO

Expected behaviour:
The ship should accept the order

The command is failing in CmdInsertOrder around line 357 due to the distance check. For some reason the station is returning with a tile index of 0 (and just about every other value).
If you build new docks in the same area they do work, but occationally there will be another dock that doesn't work.
The previous order to the selected order must be a station for the check to take place.

In file 1, the only depots exibits this behaviour.
In file 2, the left and bottom depots exibit this behaviour, the top and right depots work.
This task depends upon

Closed by  Remko Bijker (Rubidium)
Monday, 19 February 2007, 21:42 GMT
Reason for closing:  Fixed
Additional comments about closing:  In r8802
Comment by KeeperOfTheSoul (KeeperOfTheSoul) - Sunday, 18 February 2007, 01:06 GMT
I've located the problem:

When the previous order is a station,
and the vehicle is a ship
and _patches.new_path_finding_all = 0

It tries to verify the distance between the previous order and the current order.
When verifying the distance it makes the assumption that the target destination is a station and uses GetStation(new_order.dest)

If the new_order is to a depot it should be using GetDepot(new_order.dest)

I am unsure with the old path finding whether it is a bug that it is allowing an order to go to a depot, or a bug with looking up the tile index of the new order.

The intermitent trouble was caused by the fact that sometimes new_order.dest would happen to map to a station in range, and sometimes it wouldn't.
Comment by KeeperOfTheSoul (KeeperOfTheSoul) - Sunday, 18 February 2007, 01:39 GMT
This bug also exists in 0.5
Comment by KeeperOfTheSoul (KeeperOfTheSoul) - Sunday, 18 February 2007, 03:01 GMT
I think the behaviour is that it should allow orders to go to a depot, this patch should fix things.

I've added a new method that will get the tile index of an order's destination, or INVALID_TILE if the order isn't recognised.

The distance check now uses this method to get the previous order's tile index and the new orders tile index. This should allow it to support checking distances between all types of OT_GOTO_* orders.