[One issue is that it does not have any way to take into account game specific movement metrics. For grids, you just get the number of units moved, but not the metric movement. so, if for example, you have move metric set to ONE_TWO_ONE, then the getLastPath() will not really work the way you need for your game system.
Really? That's a bug. You should fix that.
I'm not sure there's that much value in retrieving movement distance if it doesn't adhere to the movement metric.
Not sure if we are speaking the same language or not. but just to be clear. using get last path and then counting the number of elements and subtracting 1(remember, the initial cell is included also in the path) will not be the same movement if your movement metric is not ONE_ONE_ONE.
It can be easily calculated by the macro for some cases (if the path doesn't double back on itself, the larger of the difference in X and Y coordinates can be divided by the smaller of the two and the result is the number of diagonal steps taken -- I think; I haven't checked it extensively). But if the path doubles back on itself then no simple formula will work and each individual step needs to be checked.
Yea, and all of this is in MTScript code which is slow enough as it is. Sooo.... thats why the want to put it into a function that runs in the java space entirely instead of doing all that via the parser and multiple functions. It should not be that hard as there are at least several places where it's calculated, I just have pull out the parts that don't directly affect the movement cost.