Eagle_rainbow wrote:

I personally would not like to see option 1: My reasoning there is that ranges of aircrafts can be very large while your zoom level might be very narrow. You then cannot decide whether the position of the airport still is in range or not, because you need to scroll back and forth (or change the zoom level) to see "where the border of the range" is. Yet, I could imagine (once you are in "go to" mode) that all the tiles visible in the viewport are coloured in red/green transparently to indicate if it is (un)reachable. However, I am not a friend of such screens either as they are "just red" (for instance) all over the place. It will make scrolling and seeking for details much more complicated.
Option 2 sounds much better to me, whilst I (currently) wouldn't have an idea how to implement it (which should not mean anything, as I am quite a newbie :) )
Option 3 sounds quite artificial to me and I would wonder, if everyone understood immediately what was meant (well, if playing around a bit, you could learn such things very fast). Thus, I would take it as "second best" alternative.

Just my initial $0.02 on it...
Cheers, ER

This comment was imported from FlySpray: https://bugs.openttd.org/task/5401#comment11792

Eagle_rainbow wrote:

Concerning your second request, I have tried to implement it with the attached patch. I also attached a screenshot how it looks afterwards.
@planetmaker: please consider it on some next commit ;)

Cheers, ER
PS@all: Feedback appreciated as usual...

Attachments

• Workspace 1_013.png (94.41 KiB)
• orderlistrange-v1-against-r24852.diff (2.52 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/5401#comment11795

Eagle_rainbow wrote:

improved version of the patch (feedback by michi_cc added on math->cmath with std namespace)

Attachments

• orderlistrange-v2-against-r24852.diff (2.53 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/5401#comment11796

Pikka wrote:

FWIW I agree with you that the second option is the preferable one. :)

This comment was imported from FlySpray: https://bugs.openttd.org/task/5401#comment11797

frosch wrote:

Maybe the goto cursor could display the distance in a measurement tooltip similiar as for construction actions.

This comment was imported from FlySpray: https://bugs.openttd.org/task/5401#comment11802

planetmaker wrote:

One thing to consider: how does it work with conditional orders:
1: Goto Airfield A
2: Goto Airfield B
3: if load_percentage > 50 goto order 1
4: Goto Airfield C
5: if load_percentage > 50 goto order 1
6: Goto Airfield D
7: goto order 4

This comment was imported from FlySpray: https://bugs.openttd.org/task/5401#comment11808

Eagle_rainbow wrote:

@planetmaker: I hope this is already covered by the distance checking coding in order_gui.cpp:211 (function DrawOrderString()) resp. order_cmd.cpp:592 (function GetOrderDistance()). If not, we have a problem in any case. Showing it in a tooltip or not then should be the least problem :p (BTW: I am currently having a look how frosch's idea could be realized - to me it sounds easier than it really is :( )
But you are right in that sense that we really need to "emulate" the situation as if the order list had been extended already. I.e. in your case it makes a lot of a difference before/after which line you add a new goto order.

This then reveals the question which distance should be shown in the tooltip:
Consider that someone is editing pm's order list. Line 1 shall be selected, i.e. the user wants to add a new station (N) at the beginning of the list.
Which distance value should be shown in the tooltip now? The distance from D to N (because it's just the last station mentioned in the list, although that route will never be flown by the plane?)? Or from B to N (because it's the first station from where the plane could come back)? Why not the distance from C to N which could also occur?

This comment was imported from FlySpray: https://bugs.openttd.org/task/5401#comment11809

Eagle_rainbow wrote:

we are in trouble :( - see #5409
Trouble is smaller than I thought: It's just hard to understand in such complex cases what is happening. => the algorithm for calculating the distance for a given order seems to be correct (according to specs).

This comment was imported from FlySpray: https://bugs.openttd.org/task/5401#comment11810

andythenorth closed the ticket.

Reason for closing: Won't implement

Mass closure of patch tickets with no commentary for >5 years. Goal is to reduce patch queue as an experiment to see if it aids faster reviewing and rejection/acceptance (it may not). If this offends you and the patch is maintained and compiles with current trunk, discuss with andythenorth in irc. (andythenorth has no ability to review patches but can re-open tickets).

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