The results are indeed strange, but expected. [43, 44] and [22, 15] (room.controller) are both unwalkable. When the path finder can't find a complete path it will return a partial path which got the closest to the target. In the case where you're searching to [43, 44] the partial path just so happens to be a subpath of the optimal path. In the reverse the path finder managed to get closer by going around the obstacle, that's just a quirk of JPS. If you set the targets to walkable in the CostMatrix, or use range: 1 on your target you'll get an optimal path in either direction, because it will find a complete path in that case. You can also examine the `ops` property on the return value from PathFinder.search and notice that it uses far fewer operations because it's not exhausting the entire room.
I think this is a pretty common mistake new users run into with PathFinder. It is mentioned in the docs (see the "Important" section) but it may be worthwhile for us to add some kind of warning when requesting an impossible path.
