[ONGOING PROCESS] Npc looking at player problem

i want my enemy to look at their target (the player)
but they are going too far, really.

what i want is for the enemy to look at their target, only on the y-axis
i use the lookconstraints using attachements and make it move instantly to look at their target

i heard from a trusted source that i should use hinges but i dont know so
i searched on the forums but there was no other issue like mine so i made one
what now??

1 Like

update: changing the cframe doesnt work since they get stuck and cant move

1 Like

Use alignorientation and set its cframe to a lookat cframe towards the player.

local sameLevel = Vector3.new(player.X, npc.Y, player.Z)
local cf = CFrame.new(npc.Position, sameLevel)

ao.CFrame = cf - cf.Position

Now the npc will always turn to the player at the same y level.

i tried to do it before (like with the option for only 1 attachement) but it has lag so i dont want to do it

good solution but not the one im looking for
you get 60% to the question, not the best but you pass

Do you only want the heat to move or the entire body?

Sounds like you just aren’t optimizing it well enough, but making do with Roblox engine is just another part of the learning experience.

It was once possible with allign orientation. But roblox changed it so now its broken

Use a script!

Direction control should really be a part of your enemy movement script. Due to the unpredictability of player movements, you must update CFrame every frame.

update: changing the cframe doesnt work since they get stuck and cant move

It depends on how do you update your CFrame. You should only change rotation component.

Use a `LocalScript’ for best effects (to avoid server-client lag).

--local script 

local playerCharacter = game.Players.LocalPlayer.Character or game.Players.LocalPlayer.CharacterAdded:Wait()
local playerRoot = playerCharacter.HumanoidRootPart

game.Players.LocalPlayer.CharacterAdded:Connect(function(newChar)
   playerCharacter = newChar
   playerRoot = playerCharacter.HumanoidRootPart
end)

-- change to a proper path, if wrong
local enemyRoot = workspace.Rook.HumanoidRootPart

--Heartbeat for CFrame update every frame
game:GetService("RunService").Heartbeat:Connect(function()
   enemyRoot.CFrame = CFrame.LookAt(enemyRoot.Position,Vector3.new(playerRoot.X,enemyRoot.Y,playerRoot.Z))
end)

Hope this helps!

misread it, but it still wouldnt work
i want the server to do all the npc works since i want the hitboxes to be accurate. it would be hard to implement this with shields and helmets and things

entire body, only the head would look up and down. im taking inspiration from decaying winter games (more specificaly decaying winter: eternal fools) if you want to see what i mean more clearly, check the game. its more obvious on ranged enemies so i guess you need to get to wave +5

how would i do that thanks

You can simulate the NPC on the client by giving the root part’s network ownership to the player it’s targeting.

Or, you can tweak the alignorientation’s responsiveness and double check if your loop/code/setup is running smooth with the script performance tab.

You aren’t going to make the perfect server sided AI. It’s either you work with replication lag on the server or doing security checks on the client against exploits.

I’d suggest using AlignOrientation:

You’ll need LookAtPosition

It’s a Vector3, set the X and Z of the player they should look at, but keep Y of the HumanoidRootPart Position of the NPC

thank you for this amazing response, i was really trying to make a “perfect ai” as you say, but thats impossible, so i guess ill have to give network owner their target (if its a player of course)
ill mark you as an answer (since i think its the best we will get from this post, really)

do you read previous replies before doing your own? 8_8io already said something similar (almost the same!) as the second post
just curious

The only issue aside from exploits with client sided NPC is syncing with the server and other clients. I’d recommend you storing all key NPC states on the server model using remote events and attributes, then firing all clients for every client who isn’t the owner to play their own animation. The benefit of something like this is that movement is 100% handled switching between clients (at least one player for the server to stay up), but also you’ll have a secure server reference to do sanity checks with positions being replicated to the server.

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