Character jittering when grinding

[wide jolt]

lol

[quaint valve]

there is an invisible moving part following the path and the characters CFrame is constantly being changed to match the moving part can that be the reason why? if yes what alternative way can i use to make the player follow the part

[quaint valve]

agreed

[wide jolt]

most likely u are moving it in the server

and thsi is replication physics stuff doing its thing

[quaint valve]

its all in a local script

[wide jolt]

is what ur doing simply just as the cframe of a part moves u move it in the client too?

[quaint valve]

basically the part has linearvelocity on it allowing it to move and in a renderstepped loop i am updating the character Cframe to the part's Cframe

Everything is in the local script (client) even the part is made in the local script

[wide jolt]

oh ok it could be that u have a vector force that acts as an antigravity or something as well

[alpine sun]

fortnite

[wide jolt]

which could be the cause of it

else it could be collisions

[quaint valve]

nope just forward ;-;

[quaint valve]

i asked in another server

and someone just said PhysicsService

and explained nothing

so not sure if it has something to do with it

[wide jolt]

if u dont have a vector fforce force on it then it will be constantly falling down too

[wide jolt]

uh thats just collision groups and stuff

is the part cancolide off?

[quaint valve]

i tried to turn off cancollied on the rails and it became much worse

i tried to anchor the player cause i thought maybe it cause the player keeps falling in between changing CFrames so it looks like that. but the player never left the original position 😅

[wide jolt]

is the part collide able?

[quaint valve]

nope its set to false

[wide jolt]

how does the part not fall down?

[quaint valve]

i think its cause of the linearvelocity

honestly im also confused

[wide jolt]

please send ur script that moves the part

[wide jolt]

its highly likely the parts falling down but being reset to go on top

[wide jolt]

include the part that does the parts velocity

[quaint valve]

this is what makes the part. and allows it to check for a part under it

local Part = Instance.new("Part")
Part.Position = GrindOn.Position + Vector3.new(0, 5, 0)
--Part.CFrame = GrindOn.CFrame
Part.Name = "MOVINGPart"
Part.Anchored = false
Part.CanCollide = false
Part.Size = GrindOn.Size
Part.Transparency = 0
Part.Parent = game.Workspace

        local Attachment = Instance.new("Attachment")
        Attachment.Parent = Part
        warn("Part made")

        local Rayparams = RaycastParams.new()
        Rayparams.FilterDescendantsInstances = {game.Workspace.Rails}
        Rayparams.FilterType = Enum.RaycastFilterType.Include

        local DownRay = workspace:Raycast(Part.Position, Vector3.new(0, -7, 0), Rayparams) 

        if DownRay and GrindBool.Value == false then

            local DownrayInst = DownRay.Instance

            local X, Y, Z = DownrayInst.CFrame:ToOrientation()

            warn(X,Y,Z)
            warn(DownrayInst)

            Part.CFrame = Part.CFrame * CFrame.Angles(X, Y, Z)

            GrindBool.Value = true

            GrindVelocity(Part, Attachment)

            MovePlayer(Part, humanoidpart, Attachment)

[wide jolt]

can u do this

[quaint valve]

function GrindVelocity (Part, Attachment)

GrindVelocityControl = Instance.new("LinearVelocity")
GrindVelocityControl.Name = "GrindVelocity"
GrindVelocityControl.Parent = Part
GrindVelocityControl.MaxForce = 100000
GrindVelocityControl.Attachment0 = Attachment
GrindVelocityControl.RelativeTo = Enum.ActuatorRelativeTo.Attachment0
GrindVelocityControl.Enabled = true
GrindVelocityControl.VectorVelocity = Vector3.new(0, 0, -150)

end

this moves the part

[wide jolt]

pls do this

[quaint valve]

input.InputBegan:Connect(function(Input)

    if Input.KeyCode == Enum.KeyCode.L then

        if GrindBool.Value == false then

            local Part = Instance.new("Part")
            Part.Position = GrindOn.Position + Vector3.new(0, 5, 0)
            --Part.CFrame = GrindOn.CFrame
            Part.Name = "MOVINGPart"
            Part.Anchored = false
            Part.CanCollide = false
            Part.Size = GrindOn.Size
            Part.Transparency = 0
            Part.Parent = game.Workspace

            local Attachment = Instance.new("Attachment")
            Attachment.Parent = Part
            warn("Part made")

            local Rayparams = RaycastParams.new()
            Rayparams.FilterDescendantsInstances = {game.Workspace.Rails}
            Rayparams.FilterType = Enum.RaycastFilterType.Include

            local DownRay = workspace:Raycast(Part.Position, Vector3.new(0, -7, 0), Rayparams) 

            if DownRay and GrindBool.Value == false then

                local DownrayInst = DownRay.Instance

                local X, Y, Z = DownrayInst.CFrame:ToOrientation()

                warn(X,Y,Z)
                warn(DownrayInst)

                Part.CFrame = Part.CFrame * CFrame.Angles(X, Y, Z)

                GrindBool.Value = true

                GrindVelocity(Part, Attachment)

                MovePlayer(Part, humanoidpart, Attachment)

            elseif not DownRay then    

                warn("Nothing hit")

            end

            SendRay(Part, Attachment)

        end
    end
end)

the naming is kinda trash

i was planning on making everything proper when everything works

function SendRay (Part, Attachment)

    Grind = runService.RenderStepped:Connect(function()

        GrindAutoUpdate(Part, Attachment)

    end)
end

function GrindAutoUpdate (Part, Attachment)

    local Rayparams = RaycastParams.new()
    Rayparams.FilterDescendantsInstances = {game.Workspace.Rails}
    Rayparams.FilterType = Enum.RaycastFilterType.Include

    local DownUpdate = workspace:Raycast(Part.Position, Vector3.new(0, -7, 0), Rayparams) 

    if DownUpdate and GrindBool.Value == true then

        local Rail = DownUpdate.Instance

        local RX, RY, RZ = Rail.CFrame:ToEulerAngles()

        Part.CFrame = CFrame.new(Part.CFrame.Position) * CFrame.Angles(RX, RY, RZ)

        local cFrame = Part:GetPivot()
        local offset = Rail.CFrame:PointToObjectSpace(cFrame.Position)
        Part:PivotTo(cFrame - Rail.CFrame.RightVector * offset.X)


        warn("New part found: "..Rail.Name.."Oreintation: "..math.deg(RX), math.deg(RY), math.deg(RZ))

        UpdateGrindVelocity(Part, Attachment)

        warn("Velocity")

    elseif not DownUpdate then

        GrindBool.Value = false
        GrindVelocityControl:Destroy()
        Part:Destroy(warn("Deleted"))
        Grind:Disconnect()
        PlayerMove:Disconnect()

    end
end

function GrindVelocity (Part, Attachment)

    GrindVelocityControl = Instance.new("LinearVelocity")
    GrindVelocityControl.Name = "GrindVelocity"
    GrindVelocityControl.Parent = Part
    GrindVelocityControl.MaxForce = 100000
    GrindVelocityControl.Attachment0 = Attachment
    GrindVelocityControl.RelativeTo = Enum.ActuatorRelativeTo.Attachment0
    GrindVelocityControl.Enabled = true
    GrindVelocityControl.VectorVelocity = Vector3.new(0, 0, -150)

end

function MovePlayer (Part, Root, Attachment)

    PlayerMove = runService.RenderStepped:Connect(function()

        Root.CFrame = Part.CFrame

    end)
end

[runic spindle]

if this is tested in roblox studio

then I don't think it's lag

since if you're simulating stuff in roblox studio, there's no replication issue.

[quaint valve]

yea its a problem with my script ;-;

[runic spindle]

where is the script that move character

[quaint valve]

well basically there is a moving part that follows the path. and i just change the characters CFrame to match the part

[quaint valve]

.

[runic spindle]

hmm maybe try to multiply it by delta time

[runic spindle]

perhaps it will smoothen things.

[wide jolt]

ok i get it

so basically what ur doing is moving the part and then when u hit something u cframe it up

the part is boucning

so teh character should too

see how the part interacts in game and see if the part is boucning

[quaint valve]

i truned off the line that moves the character so you can see the part

[quaint valve]

wdym

[runic spindle]

welp I also thinking of this since there's no lag in moving part

[quaint valve]

do you think using alignposition might be better than just changing the CFrame or is it the same?

[wide jolt]

just change cframe

no need for

velocity and all

just change the cframe

anchor a part and cframe it to end position

or else u can use a linear velocity with a vector force that negates gravity

but no need for that just cframe lol

[runic spindle]

it's same I think. If you use align position, you can have better control over the character in term of velocity and smoothness.

[quaint valve]

wdym by this

[wide jolt]

instead of using linear velocity just move it forward with ur own velocity ig

just do direction * speed to get velocity

so u can just get teh direction the rail is facing multiply it by ur speed

[quaint valve]

but then how will it turn the curves?

[wide jolt]

it looks to me u just raycast down

and the nge tthe oreintation of the part

and then u set that to the linear velocity

just use the same thing

[quaint valve]

but isnt that what im doing xD

[wide jolt]

yeah but dont use linear velocity simple

[quaint valve]

imma be honest with u

im stupid af

[wide jolt]

nextposition = currentposition + velocity * deltaTime

velocity = direction * speed (direction as a vector not some dot product or something)

direction = raycast.result.instance.lookvector

[quaint valve]

alr give me a few mins

[wide jolt]

deltaTime here refers to the deltaTime u get from heartbeat loop

[wide jolt]

u can simply pivot to this cframe CFrame.new(currentPosition, nextPosition)

done

no need for velocity n allat

that stupid chatgpt is stupid dont listen to it

[wide jolt]

all of this is useless tbh

[wide jolt]

just do what i told u to do

[quaint valve]

alr im doing it rn

[wide jolt]

tell me this is the curve a collection of parts?

[quaint valve]

it wasnt chatgpt it was all me ;-; i was called stupid indirectly lmaoooo

[quaint valve]

yep

[wide jolt]

yeah my solution should work for u then granted all the parts are oriented forward

[wide jolt]

oh in that case mb i thought u just ctrl c + v

[quaint valve]

np 😂

[wide jolt]

nothing wrong with using gpt but sometimes its a little wrong

[stiff ruin]

there is nothing wrong with your code

the client replicates the character at 20hz i belive

normally other clients will fill in the gaps to make it look smooth

but because other clients are not able to guess the characters next movment

the character just teleports to the next position

[cursive cypress]

20?

thats less than i wouldve thought

thats silly

[stiff ruin]

if you use things like align position or vectorforce then other clients can use that to guess the movment of the character better

but if your setting the cframe then other clients cant guess the characters next move

[quaint valve]

my bad i had something to do so i could reply

[quaint valve]

i did what you told me

the moving works

but other players cant see you moving

[quaint valve]

does that mean alignposition or weld would make it better?

[stiff ruin]

If you use align position then the other clients will continue to move the character to that position even when they get no messages telling them where to position the character

So yes it will look smoother with align position

And if you weld something then it depends on how to move that assembly

If your just using cframe again the welding will not have any benefit

[quaint valve]

oh yea

ill test out the alignposition

[wide jolt]

u are most likely anchoring the character u should be welding the character to the moving part instead

[wide jolt]

or u can use alignposition in which case u wouldnt even need an invisible part

both ways work

[wide jolt]

i think alignposition would be better since this is more of a hack

[quaint valve]

my bad i once again had something to do yesterday so i couldnt come back and reply

[quaint valve]

it works much better now

but there is one more problem i would like some help with

[wide jolt]

https://tenor.com/view/denzel-washington-ask-ask-and-receive-scripture-inspiration-gif-15161096

[quaint valve]

part of the path goes up like this

as the part moves and detects the orientation it will slightly go lower

and if the player keeps going back and forth at some point the part is too low to detect the path and will just stop

[wide jolt]

do u have a video example or something of this?

[quaint valve]

yea im trying to get it rn

[wide jolt]

ok thanks

[quaint valve]

as you see the direction of the part changes based on the way you are looking

so if you keep going back and forth past the part pointing slightly up at some point you will stop

i assume something like this is happening

i think since the ray is being sent from the middle the part would already make some distance past the part before the ray detects the new part so when it changes direction its slightly lower

is there i can make it so its always 7 studs away from the point it hits (something like the green part)

[wide jolt]

https://www.youtube.com/watch?v=uKzVmOdPKRQ&t=989s&ab_channel=SuphiKaner

depending on what ur doing this video might have the solution for u; alternatively im not sure what method u are using but if the part is anchored and u are cframing i dont see why this should be a problem since u can always ensure the part is 7 studs above the raycast result part

[wide jolt]

u could also fire 1 more ray that goes forward and not down and see if the result instance is close and then correct the position based on that

[quaint valve]

im just gonna make it so that you cant grind for too long😂

instead of fixing it im just gonna avoid it

its a "Feature" in the game

[quaint valve]

i know ive been asking a bit too much but can you help me with 1 more thing

i have another script that changes the camera lookat angle/direction

its a bit too snappy

i guess the best way to explain is if the player is facing straight and i want him to look exactly 90degrees right the camera will instantly snap to that angle/direction

is there a way fo it to smoothly change to that angle

i read somewhere that i can use lerp

but im not sure how to do it

cam.CFrame = CFrame.lookAt(head.Position, head.Position + ToCFrame) * CFrame.Angles(0, math.rad(-90), 0) * CFrame.Angles(math.rad(AngleX),0,0) * CFrame.Angles(0,0,math.rad(13)) * HeadOffset

this is the line i use to change the camera lookat

not sure how i would include lerp to make it smooth

[wide jolt]

sorry about that my brain was farting horribly, u can simply lerp from cframe 1 to cframe 2

local currentCFrame = cam.CFrame
local newCFrame = CFrame.lookAt(head.Position, head.Position + ToCFrame) * CFrame.Angles(0, math.rad(-90), 0) * CFrame.Angles(math.rad(AngleX),0,0) * CFrame.Angles(0,0,math.rad(13)) * HeadOffset

cam.CFrame = currentCFrame:Lerp(newCFrame)```

[wide jolt]

alternatively u can also use tweenservice to do the same

local tweenservice = game:GetService("TweenService")
local newCFrame = CFrame.lookAt(head.Position, head.Position + ToCFrame) * CFrame.Angles(0, math.rad(-90), 0) * CFrame.Angles(math.rad(AngleX),0,0) * CFrame.Angles(0,0,math.rad(13)) * HeadOffset

tweenservice:Create(cam, tweeninfo.new(0.1), {CFrame = newCFrame}):Play()```

[quaint valve]

lmao i wouldnt have know how anyways so you can take all the time u need xD

[wide jolt]

i havent used lerp in a while

[wide jolt]

the difference between this isnt too too much but i would suggest using lerp if u just wnat to interpolate but if u want tweening styles i suggest u use tweenservice

[quaint valve]

ive never used lerp so its all new to me

[quaint valve]

i guess as long as its not too snappy anything is fine

[wide jolt]

u could go on to write ur own custom style if u want i personally woudl never but its upto u; tweenservice really just uses lerp🤷

[wide jolt]

just lerp since u have no real need for an easing style imo

[quaint valve]

i get this error

[wide jolt]

um oops where

[quaint valve]

the camera just stops and doesnt follow the player

cam.CFrame = currentCFrame:lerp(newCFrame)

[wide jolt]

its "Lerp"

sorry

is there no alpha number by default do u have to manually set that too?

no right there has to be one

[quaint valve]

should i just add 0.5?

somewhere in there

xD

[wide jolt]

its basically by how much it does it

[quaint valve]

yep

[wide jolt]

i think by default is 1

not sure tho if its not then put 1 there

[quaint valve]

still the same

[quaint valve]

wait i almost got it

i may be a genius

reducing the alpha makes it smoother

i made the alpha 0.1 and it looks like this

instead of lerping everything

ill just lerp the Y orientation which is the horizontal movement if im not wrong

[quaint valve]

after some trash research and asking

local lookat = CFrame.lookAt(head.Position, head.Position + ToCFrame)

cam.CFrame = cam.CFrame:Lerp(cam.CFrame.Position * CFrame.Angles(lookat), 0.1)

Argument 3 missing or nil

[wide jolt]

i dont like that solution

[quaint valve]

neither do i since it doesnt work xD

[wide jolt]

looool

whats wrong tho it looks fine to me on the videos

[quaint valve]

its supposed to be first person ;-;

[wide jolt]

this looks cooler lol

can be another one of ur features

[quaint valve]

yea i also felt that xD

[quaint valve]

lmao

imma be honest i did think about that

but since fighting will be involved

it wouldnt work

[wide jolt]

whaats argument 3?

[quaint valve]

yep thats a good question

i was basically told by someone my code is cooked

nothing about it is supposed to work

this is what i was told

1. U can't use a cframe as a parameter for cframe.angles it has to be 3 numbers
   2.Also if you're keeping a cframe with cframe:Lerp the first arg has to be a cframe not a vector3