I have this problem with the move I am working on that includes some teleportation. While making the hitbox I found this problem where the hitbox is on the wrong CFrame when moving and looking diagonal
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local UserInputService = game:GetService("UserInputService")
local RemoteEvent = ReplicatedStorage.Events.Remote.ThunderClapRemote
local TweenService = game:GetService("TweenService")
local Player = game:GetService("Players")
local debounce = false
RemoteEvent.OnServerEvent:Connect(function(player)
if debounce == true then
return
end
debounce = true
local HumanoidRootPart = player.Character:FindFirstChild("HumanoidRootPart")
local Startpos = HumanoidRootPart.CFrame
local hitbox = Instance.new("Part")
hitbox.Parent =workspace.Map
hitbox.Color = Color3.new(1, 0, 0)
hitbox.CanCollide = false
hitbox.Transparency = 0.8
hitbox.Anchored = true
hitbox.Size = Vector3.new(12,5,50)
hitbox.CFrame = HumanoidRootPart.CFrame + Vector3.new(0,0,-30)
local function MakeCount()
for count = 1 ,5 do
local X
local countfolder = {}
local part = Instance.new("Part")
if count % 2 == 0 then
X = -6
else
X = 6
end
part.Parent = game.Workspace
part.Anchored = true
part.CanCollide = false
part.Transparency = 1
part.Size = Vector3.new(1,1,1)
part.CFrame = Startpos * CFrame.new(0 + X,0,-count * 10)
player.Character:MoveTo(part.Position)
wait(0.1)
part:Destroy()
end
end
task.spawn(MakeCount)
task.wait(MakeCount())
hitbox:Destroy()
wait(3)
debounce = false
end)
You are offsetting the hitbox from the HumanoidRootPart in world space, so this will only work if you’re facing a certain direction. Do this instead:
This code will position the hit box 30 studs in front of the player. In the HumanoidRootPart’s object space, the x-axis goes from left to right, whereas the z-axis goes forward to backward. Previously you were positioning the hitbox along the world z-axis which is independent of the player’s orientation.
That's what's causing your issue, but I have some extra code review for you:
What’s up with this?
You’re spawning MakeCount in another thread and then immediately calling MakeCount again within the original thread and for some reason passing the result of MakeCount into task.wait. MakeCount returns nil, so your code is the same thing as doing this:
task.spawn(MakeCount) -- don't need this
MakeCount()
task.wait(nil) -- don't need this
task.wait(nil) is the same as just task.wait(), which simply yields the current thread until the next frame. I don’t think you need this. Without going into detail of how the task scheduler works, you’re essentially running two instances of MakeCount at the same time. In short, one instance of MakeCount runs until it hits wait(0.1), then in the same frame the other instance of MakeCount runs until it also hits wait(0.1), then this whole process repeats four more times until both instances reach the end of their respective for loops. In this specific case, visually the effects of the script remain the same, but computationally you are running 2 times as much code. Basically, I’m saying you can just call MakeCount once (without using task.spawn or task.wait).
Also, there’s no need for MakeCount to create a new part spending extra memory just to move the character. You can do:
Thank you with all the love of my life that I ever experienced, there is nothing wrong with the tone and please keep doing this with other people. If I could I would give 3 … no 4 kisses on the cheeks. And yes I am glazing with maximum efficiency unlike my code but that is for a different time. I hope you have nice days for the rest of your life and you will be named in my next prayer.
