This was tested with MT out of the box, tried both DPC of 1 and 5, same results.Lee wrote:@Jamz you might just have to revert to original source, I'm afraid. The issue reported by wolph looks familiar but it's not supposed to behave that way. What the logic does is generate a path from point a to point b for unsnapped movement that is similar to snapped movement .
As I suspected previously, there's a missing element somewhere in the patch I submitted. The FoW fix was coupled with the path compute fix as they shared common classes. I don't have the time right now to separate the 2, but if you want to tackle it, best of luck They were the 2 of the more trickier ones I had to fix
@wolph Out of curiosity, what was your distance per cell set to? Were there any other changes?
Note that this issue is in b90 NOT in build 89, so its indeed the patch.
Which brings me to another thing... apparently its a trade off, either have 'bugged' FoW (very slow) OR 'bugged' 'getLastPath() (unsnapped only). Correct?
If thats the case, then I'd rather have a bugged getLastPath then a bugged FoW as I use the latter considerably more often. (obviously I prefer both fixed, but if it boils down to a choice, my bets on FoW fix.).