Explain 2 me why the capx that i posted in the topic that you linked to is working flawless.
Its actually quite interesting because at first glance your CAPX seems to work fine, and it took me a while to figure out why, because even if I copy/pasted yours, mine still weren't working. But looking further into it, it turns out that it have nothing to do with how you programmed it. You don't need all the regenerate obstacle map, global variables or trigger once, you could have made it straight up like this:
On mouse left click -> A.findPath
On path found -> A.movealongpath
For some strange reason it seems that the cell size of the objects is very important, much more than I thought. Because the reason yours works or appears to work, which of course it does to some degree, is because the obstacle map is linked to the cell size of the sprite. You can test this very simply by changing the Cell size of object A to be the same as B (32). When you move A it will work correctly, however when you move object B it will ignore the obstacle map that you told it to and start using object A instead, which seems illogic why it should do that, but interesting and good to know non the less.
So your example might actually have help me at least, to find a semi acceptable workaround for the path finding, because you might be able to get at least somewhat unique path finding simply by using different cell sizes to simulate different types of object, lets say a (Ship or Car). So you could give the Ship a cell size of 32 and the Cars a cell size of 31 and in theory from what I can see it should work, but whether that will give a lot of bugs later on with weird movement etc. I don't really know, but definitely worth testing out at some point in a serious game.