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

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

Closed
DorpsGek opened this issue Feb 18, 2007 · 4 comments
Closed

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

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

Comments

@DorpsGek
Copy link
Member

KeeperOfTheSoul opened the ticket and wrote:

Revision: trunk@8787

Problem:
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

Notes:
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.

Reported version: trunk
Operating system: All

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

KeeperOfTheSoul wrote:

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.

This comment was imported from FlySpray: https://bugs.openttd.org/task/634#comment935

@DorpsGek
Copy link
Member Author

KeeperOfTheSoul wrote:

This bug also exists in 0.5

This comment was imported from FlySpray: https://bugs.openttd.org/task/634#comment936

@DorpsGek
Copy link
Member Author

KeeperOfTheSoul wrote:

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.

Attachments

This comment was imported from FlySpray: https://bugs.openttd.org/task/634#comment937

@DorpsGek
Copy link
Member Author

Rubidium closed the ticket.

Reason for closing: Fixed

In r8802

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

@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