One shortcoming with the current implementation of automapper is that if your travel is interrupted for some reason (unexpected RT, failed climb, engagement, script error, etc) there is no easy way to auto-resume travel. You could make an alias that sets the destination manually, but that wouldn't capture automapper mouse clicks. You could also trigger off of the MAPCLICK event to get around this, but that fires for non-navigation as well. Instead, it would be much cleaner for the Automapper to set the destination id automatically.
This also can simplify logic around navigation failures because if the "$destination" == "0" then you will not be successful in moving!
My main question with this PR is how do we feel about the global variable name? It is somewhat generic and could potentially conflict with user scripts. On the other hand, I think it would be used frequently so I don't want to choose a name that's too long.
One shortcoming with the current implementation of automapper is that if your travel is interrupted for some reason (unexpected RT, failed climb, engagement, script error, etc) there is no easy way to auto-resume travel. You could make an alias that sets the destination manually, but that wouldn't capture automapper mouse clicks. You could also trigger off of the MAPCLICK event to get around this, but that fires for non-navigation as well. Instead, it would be much cleaner for the Automapper to set the destination id automatically.
This also can simplify logic around navigation failures because if the "$destination" == "0" then you will not be successful in moving!
My main question with this PR is how do we feel about the global variable name? It is somewhat generic and could potentially conflict with user scripts. On the other hand, I think it would be used frequently so I don't want to choose a name that's too long.