Eagle_rainbow wrote:

The major difference between the current implementation and my calculus above is the fact, that the implementation is "forward-looking" (e.g. for a given order n, it tries to look at the orders n+1, n+2, ..., n+m to determine what will be the distances for the upcoming orders), whilst my variant is "backward-looking" (e.g for a given order n, it tries to find out which distances need to be flown to get to this order). As such, both approaches appear to me being valid.

Here's how the logic currently (r24869) works in the case above:
1: lookup order 2 - find B; calculate d(A,B) = 146 tiles
2: lookup order 3 - find conditional, look both at order 1 and order 3; calculate max(d(B,A), d(B, C)) = max(146, 53) = 146 tiles
3: no "goto order" - no distance calculated
4: lookup order 5 - find conditional, look both at order 1 and order 5; calculate max(d(C,B), d(C, A)) = max(53, 193) = 193 tiles (i. e. out of range)
5: no "goto order" - no distance calculated
6: lookup order 7 - find conditional; look both at order 1 and order 1; calculate max(d(B,A), d(B, A)) = max(146, 146) = 146 tiles
7: no "goto order" - no distance calculated

This also solves my statement

"Apparently, the order list distance algorithm "thinks" that the plane is located at A!"

before: It does not think that plane is at A, but it detects that if you exchange order 6 with A, that it has to fly to A, which is the same airport.

I looked up the manual in the wiki; there is nothing said about this feature yet. So at least, we should enhance the documentation on how ranges are calculated and how the distance values shown (or at least the statement "out of range") are being calculated. Otherwise others might also fall into the same pit and will not know how to fix a complex order list which says "out of range" somewhere.

This comment was imported from FlySpray: https://bugs.openttd.org/task/5409#comment11823

Rubidium wrote:

What is exactly wrong here? It says that the "next destination is out of range", for exactly the order where the next destination would be out of range.

With backward looking you only make things more complex for the end user because with those conditional orders you could "arrive" at the goto from dozens of locations, whereas with forward looking you leave from one goto order and you could follow the conditional orders.

This comment was imported from FlySpray: https://bugs.openttd.org/task/5409#comment11960

Eagle_rainbow wrote:

Yes, you are totally right.
The problem for me was that the UI does not state what "out of range" means. I understood that my order list does not work, but I was not able to understand how to fix it :) Also looking at the wiki manual did not help me either.

So, in short words:
* No, my backward looking approach is not a good idea and the current algorithm should not be changed.
* On the other hand, no, I do not like the current way of presenting the information :) it's "out of range" for order X - but that is not enough for me, as it does not state which order Y is causing it.
* As I do not have a magnificant idea how to improve the screen short-term, my request (partly also to myself :) ) would be to add some words in the wiki manual describing how the algorithm works. Ideally, it would also give some hints on how to determine which destination is causing the "out of range" message. The idea would be to enable the player to fix his order list on his own.

Sorry to leave this ticket in quite an unclear state before, but for the last couple of weeks I did not find time neither to work on OTTD topics nor to update this comment :-| Hope this will become better soon...

This comment was imported from FlySpray: https://bugs.openttd.org/task/5409#comment11972

andythenorth closed the ticket.

Reason for closing: Won't implement

Flyspray clean up: nearly 5 years old, and not obvious what should be done with this next, so closing. If this offends, discuss with andythenorth in irc. Thanks.

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