PathfindingService is erroring when ComputeAsync is being used

This game uses pathfinding in a high capacity, as seen in my previous two bug reports, however unfortunately yet again an error has arisen during the development of this game.

For complete transparency, I will provide access to code snippets related to the said bug, however if you need anything further/expanded, I will include this within a private content message to uphold the closed access state of the game alongside the preference for our codebase to not be fully in the hands of the full devforum.

Anyhow, the issue is that when computing a simple path to walkaround the vehicle (as seen in the “expected behaviour” image) it does not occur and instead throws an errorMessage of nil in the second parameter and the path status is no path of the below code:

	local pathComputed, errorMessage = pcall(function()
		self._path:ComputeAsync(self._agent.PrimaryPart.Position, (typeof(target) == "Vector3" and target) or target.Position)
	end)

image
image

I am creating the path as followed:

PathfindingService:CreatePath({
                        Costs = {}, 
			AgentRadius = 3,
			AgentCanJump = true,
})

I also attempted with the following costs:

Costs = {
 RailwayTrack = math.huge,
				Trees = math.huge,
				Grass = 10, 
				LeafyGrass = 10,
				GrassPart = 10,
				Road = 0,
				Crossing = 0,
				DiamondPlate = 0,
				Railing = math.huge
}

In both instances. No path was generated.

Expected behavior

The expectation in this instance can be seen annotated below in the image, I want the NPC to move to the rear of the fire engine. However, this is not occurring.

image

I believe the only thing potentially blocking this path could be the calculation regarding going through or around the vehicle’s MeshPart’s which have the following properties:

Thanks for the report! I filed a ticket in our internal database and we’ll follow up when we have an update for you.

Hi @M_etrics ,

We need the steps to reproduce this issue. Could you please provide the rbxl file? You can directly DM it, and it’s okay if it only contains the map (no other logic). This would help us debug the problem. From the code you shared, there doesn’t seem to be anything wrong with it.

Solution was that the destination node was too high up to be calculated so lowering it was the patch. Furthermore, @watIsInTheName identified a bug that was separate from what I observed.
"Systems seem to think under the truck is a free space sometimes. " and clarified that they are working on improving navmeshes.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.