Implementing Raycasting to state whether use AI Pathfinding or not

I’m currently working on a combat system for one of my projects, recreating it to be exact.
I’ve came through the obstacle of efficiency of the MoveToPlr function, which is supposed to move the mob from its position to the tagged player.
Turns out the path generating process takes time, and would be easier if used a conditioner to state whether it would be useful or not, as there is a high chance of having a clear path to the player meanwhile calculating the path.
The solution is probably raycasting, but I’ve never used it before so advice and techniques are very appreciated.
Below is the current function of MoveToPlr:

return {
function(Target)
	local Distance
	local function Start() return HumRoot.Position end
	local function Final() return Target.HumanoidRootPart.Position - (Mob.HumanoidRootPart.CFrame.LookVector * 2) end
	local WaypointIndex = 0
	local Waypoints
	local Dest
	
	--Implement Raycasting to know if I would need to use AI or not.
	
	local function FollowPath()
		Waypoints = PathFinder:FindPath(Start(), Final())
		WaypointIndex = WaypointIndex + 1
		Dest = Waypoints[WaypointIndex]
		Hum:MoveTo(Dest.Position);
		HumRoot.Rotator.CFrame = CFrame.new(Start(), Target.HumanoidRootPart.Position);
		HumRoot.Rotator.P = 2000;
	end
	
end
}
2 Likes

First, let me begin by that pathfinding auto-calculates this, there is no need to do the Ray Tracing.

I would not recommend ray tracing in here, there is a built in (mostly unknown) function of Camera that is called GetPartsObscuringTarget that you can use with a camera facing the player from the head of the AI Entity.

Edit: In the castPoints array, just use the Vector3 of the HumanoidRootPart of the target player

Hope I helped :slight_smile:

2 Likes

By that do you mean I’m better off using GetPartsObscuringTarget instead of raytracing, or using neither at all?

You are better off using GetPartsObscuringTarget, it is pretty unknown but pretty useful instead of messing with Ray Tracing.

1 Like
  • Cast a ray from the NPC’s HumanoidRootPart in the direction of the target position (Vector3 target_pos - npc_pos).

  • Use workspace.FindPartOnRayWithIgnoreList to return the part the ray hits, and the position of intersection. You can pass an ignoreDescendantsTable argument, in which you should include all other NPCs (so the ray doesn’t hit one of them, causing you to wrongly assume there is no direct path).

  • If there is a hit part, and the hit part is not a descendent of the target player’s character, the path is blocked. Otherwise, the ray hit the character, and there is a direct path, so you can use MoveTo directly to the target position without worrying about pathfinding.

I would implement additional checks for the Y-axis position of the player, because even if there is a direct ray, they could be in an unreachable position due to differences in height.

If you are already comparing the magnitude between targets, you should skip passing the ray for targets over a certain distance away (e.g. 300 studs), and head straight to pathfinding to avoid unnecessary computation.

1 Like

Doesn’t this require the mob to have a camera though?

It does, but you can add a Camera with the mob’s head as the main part of it and it will work just fine

image
Are there any additional edits for the camera needed?

This sounds incredibly over-complicated for just creating a simple ray, and having a separate camera instance for every NPC sounds ridiculous. In what way is this a better solution?

1 Like

This worked out well, thanks!

~30Chars~

This is bad advice. Not only do cameras not work with NPCs but they don’t have representations as client-side machines either. Using the camera here is not a useful OR plausible solution. Please do some research on objects before suggesting (abuse of their API).