So the problem is in fact the code, and not the loop? Since for the client looks normal because it is doing it directly on the client and there is no waiting, which explains why for the other clients it looks glitchy and for the server, and why using HeartBeat makes it glitchy for the client itself aswell
In other words, you probably want to re-code your script in a more efficient way that brings the same results, I could maybe try to help you with that if you showed me footage of the character turning and how it interactcs
Itâs properly doing it with renderstepped on the client that runs the loopâŚ
â if I change the loop to stepped, it also becomes glitchy on the client that runs the loop, which indicates that the loop itself is the issue, no?
You know that moving your character by setting the characterâs CFrame is a teleport as far as the physics engine is concerned, not smooth movement, right?
Roblox avatars normally move around using the Humanoid:MoveTo() function and setting their move direction (which is actually a velocity) and this ensures that their movement is interpolated on the server and all other clients. If you just CFrame them, the server and client will only get updates about every 3 render frames (~20 FPS), and the timing wonât be smooth, it will just update whenever each client gets and processes the replicated CFrame packet. Irregularity of travel time of the packets across the internet, and any additional delays sending, receiving, and processing the packet will all be visible in the movement of the character. In other words, the relative timing of position changes on the originating client is not preserved on the server or any other client.
The Humanoid has some built in code to handle this, which is affected by a few things like Humanoid.AutoRotate, UserGameSettings.RotateType, and Humanoid:Move()'s second parameter, the cameraRelativeMovement bool. In first person and shift lock, the character rotates with the camera because itâs using AutoRotate and setting the move direction to be the camera direction. The newer ControllerManager system has move direction and facing direction separately exposed to make this easier to control.
If you want to roll your own system for a character with no humanoid, you can achieve similar with an AlignOrientation constraint or the older BodyGyro. Both of these still only replicated changes at 20 FPS, but they are smoothly interpolated towards the current value everywhere, so the results arenât jerky.
Generally, you should not directly set the CFrame of a character model every frame, you should only do this if youâre actually trying to teleport the character or instantly snap them to a position and orientation once. This applies also to using PivotTo().
What would be your suggestion and way to implement it?
The only thing I kind of understand is the AlignOrientation. By changing the CFrame through the attatchment it is rendered differently?
Yes. If instead of setting HRP.CFrame directly you set the control attachment of an AlignOrientation, or equivalently a BodyGyro.CFrame of a BodyGyro parented to the HRP (this is an older, deprecated way but it still works), then the resulting movement of the character is interpolated on all clients. Depending on the settings of the constraint, it can be pretty snappy (e.g. with RigidityEnabled) or it can be slower and feel like itâs lagging behind input a bit, but it will be smooth.
Youâre trying to rotate the the humanoid towards the camera while they are moving in another direction, when Roblox humanoids automatically turn towards the direction of their walking.
I am testing how AlignOrientation too works btw, but yeah the glitching was caused by the autorotate bool being turned on. Now I know this property exists .
Ah, yes, IIRC the built-in Humanoid gyros are effectively infinite torque, so if you have AutoRotate on, itâs going to fight against attempts to manually orient the character in a different direction, the same way the the regular upright gyro thwarts attempts to tilt the character when in the Running state.