The color of a route change is sometimes yellow, and sometimes magenta.
This means you really have to look at which color you want to keep and which one is scrapped.
the difference strikes when you use “direct to” instead of a flightplan change.
The magenta one is always the one that is active. The yellow one is always the one beeing currently edited, and these changes need to get either approved (the yellow one becomes magenta and the old magenta disappears) or cancelled (the old magenta stays as it is, and the yellow disappears).
There is currently a faulty implementation when doing a directTo via InfoWheel->Route Info Window, we tried to be smart there by parking the existing route as yellow route so the direct to could easely be reverted to the original route, but this is causing so much confusion that we're going to undo this.
A "Nearest" module is in the pipeline, that will allow for all the directto and route-shortcut options.
the idea of being able to temporarily do a direct to (without killing the other routing) is still good and perfectly fine, it was just the execution that makes it confusing. please do not abandon the fundamental idea.
@flyvans-com
Hi Bernhard, you are right.
The idea to be able to have a temporarily direct-to active and to be able to switch back to the planned route after that is still good.
However, how it currently was implemented was too confusing. We do not want to surprise a user in flight with an atypical workflow.
The "Nearest" module in combination with a route-shortcut option that Rob mentions could possibly be a more logical workflow.
Thinking out loud; using the existing methods for editing a route or the "Nearest" function that is the pipeline; you can insert the waypoint to where you need a temporarily direct-to. Then, if you no longer need this direction, you can jump to the next leg with the shortcut function that is to be developed.
Would that work?
Cheers,
Tim
