The problem is that Part1 only moves on the client. On the server it simply stays put, like it is suddenly anchored in place. Part2 is moving as it should.
What is causing Part1 to behave like it’s anchored on the server?
If you are tweening using position this sometimes may occur, try tweening the CFrame of the object. I had a similar experience in a different circumstance awhile ago. CFrame is weirdly just more reliable for making anchored and unanchored parts work together.
I wish that would work for me, but I seemingly have to tween position and orientaton seperately due to it looking very unnatural for Part2 to rotate over a long duration (I basically need 2 different tween times for position and orientation).
Is it somehow possible to set play a CFrame tween without messing with the orientation?
I believe using a CFrame without specifying rotation does not default to some value, so it should be possible to just use a CFrame position tween and a CFrame rotation tween. Just make sure it is tweening the CFrame position of the object, and not just the position directly.
I would definitely still test that though, put a block in your world at some specific rotation thats anchored, and tween it via CFrame position. If it messes with the rotation then you’ll have to think of a way around it.
To move a CFrame you should probably be multiplying it by another CFrame with the vector inside of it. Multiplying CFrame.new(nextCheckpoint.Position)*CFrame.new(0, -2, 0) is the same thing as what you have done here.
Another note with this is you can multiply by a CFrame.Angles value that you could tween separately and it should create the same affect as tweening them apart, you’re just combining their effects at the end.
The + Vector3.new could be removed and it won’t change the problem.
The problem is that changing CFrame causes the rotation of the object to change during the entire tween, and I need the rotation to only change in the first 0,5 seconds.
I think the only solution is to move away from tweening, and adjust the CFrame in a custom lerping function. It’s possible there are other ways though. I will post the function here if I figure it out.
Alright, that is unfortunate. Why not do this whole process in 2 tweens that are immediately after one another? Do the rotation in the first part that you require, and keep the movement consistent throughout that initial tween, and carry it into the second tween.
That solution should be fairly seamless as I have used this on some stuff in my game. Either way, it would be awesome if you could mark the initial post about using CFrames instead of position as a solution.
Because I need them to happen at the same time. Although I guess you could do some % cutting in the tween time (really horrific coding)? I may try this if the lerping function fails.
You can tween position and rotation at the same time with CFrames. You can also linearly interpolate position and rotation at the same time, because tweens also use linear interpolation. My suggestion came from thinking you needed to stop rotating 0.5 seconds in, and tweens don’t operate on stopping a specific quality of your system at some point in the tween. So having the first tween be 0.5 seconds with the rotation and movement, then the rest with whatever other changes you would need would emulate that need to change that characteristic. Lerping is just a more manual version of tweening so honestly probably just go with that if you need to do something with this many steps. But still note, as stated earlier, use CFrames, not just directly position and rotation arguments.
In the future, to help with problems more effectively and accurately, include videos or demographics to emulate or just record what you are trying to do so you can communicate the full problem.
Also, looking at your profile, I wanted to mention that solutions should go to the people who give you the helpful information to solve the problem, not just what you did from the information that they gave you. That is more of a footnote “incase you were wondering” type of thing. It is still a solution, but its good practice to mark the person who gave you the initial boost to get you there so to speak.
That’s all I have for you now though, best wishes going forward!
I think the simplification of the post worked well for this topic. I’m not confident in posting a video that of Part1 being stuck would have helped much.
The solution is the comment that has the solution in it. Otherwise people would have to read an entire thread when browsing.
I’m sorry if you feel unappreciated. I only post on this forum these days if something confuses me on a fundamental level (and that causes the problem to be nearly unsolvable), which is what this welding behaviour has done.
You did clear up that confusion with your first post and that has definitely helped me understand the behaviour, however I must mark the lerping function as the actual solution, because it is the thing that solves this specific topic.
It is true that your comments could directly solve someone else’s problem, but I have to go on my own experience with this problem. That being said, if a moderator tells me otherwise (or you can point to a rule), I will mark solutions differently going forward.
This fixed it for me. By lerping instead of tweening, it is possible to manipulate the CFrame more precisely. The downside being a lot more code.
--Position and rotation movement
local function lerpAngle(a,b,c)
local difference = (b - a + 180) % 360 - 180
return a + difference * c
end
local function lerpOrientation(startOrientation,endOrientation,middleOrientation)
return Vector3.new(lerpAngle(startOrientation.X,endOrientation.X,middleOrientation),lerpAngle(startOrientation.Y,endOrientation.Y,middleOrientation),lerpAngle(startOrientation.Z,endOrientation.Z,middleOrientation))
end
local directionAttatchment = nextCheckpoint:FindFirstChild("DirectionAttachment")
local rotationOffset = CFrame.Angles(0,math.rad(-90),0)
local targetCFrame = directionAttatchment.WorldCFrame * rotationOffset
local x,y,z = targetCFrame:ToOrientation()
local targetOrientation = Vector3.new(math.deg(x),math.deg(y),math.deg(z))
local startCFrame = meshOfDragon.CFrame
local startOrientation = meshOfDragon.Orientation
local endOrientation = targetOrientation
local endPosition = nextCheckpoint.Position + Vector3.new(0,-2,0)
local rotationTime = 0.5
local startTime = os.clock()
local CFrameConnection = nil
CFrameConnection = game:GetService("RunService").Heartbeat:Connect(function(dt)
local passedTime = os.clock() - startTime
local middleRotation = math.min(passedTime / rotationTime, 1)
local currentOrientation = lerpOrientation(startOrientation,endOrientation,middleRotation)
local middlePosition = math.min(passedTime / tweenTime, 1)
local currentPosition = startCFrame.Position:Lerp(endPosition,middlePosition)
meshOfDragon.CFrame = CFrame.new(currentPosition) * CFrame.fromOrientation(math.rad(currentOrientation.X),math.rad(currentOrientation.Y),math.rad(currentOrientation.Z))
if passedTime >= tweenTime then
CFrameConnection:Disconnect()
end
end)
while CFrameConnection.Connected == true do task.wait() end