PathfindingService generates nonsense path when one of the positions is the same as a PathfindingLink attachment

This is an issue with PathfindingLinks specifically. When a ComputeAsync call is made with one of the positions being the same as a PathfindingLink’s attachment position, and that PathfindingLink is required to access the other position, an incorrect path is made.

The path made has two waypoints only, a start and an end, represented by a single part:


When it should instead look something like this, drawn in green:

Here is the repro place. When the grey part is within the walls, the PathfindingLink is required to get to it. However, instead of using the PathfindingLink, a straight path is generated to the grey part instead, from the outside PathfindingLink attachment position. The bad paths can be detected to an extent, and the code will print every time a bad path is made.

Expected behavior

ComputeAsync should instead use the PathfindingLink to traverse to the other attachment, and then normally path to the grey part once inside the walls.

3 Likes

Thanks for the report! We’ll follow up when we have an update for you.

Hi @CreeperCompany5 , could you please share the .rbxl file with us or grant us access to the place (currently it’s private)? Based on the explanation above, have you tried reducing the cost associated with the pathfinding link? By default cost of Jumping (automatic link or custom pathfinding link) is higher than walking on the surface).

Here is the file pathrepro.rbxl (55.3 KB)
I also tried to make it public. Did not mess with costs, the only possible path is through the link in the test place.