Recently the FFlags for Roblox’s Server Authoritative player replication have been discovered. This will make the server the “True” location for player positions, meaning that if you try to physically displace your character using the client (Movement hacks, flyhacks, etc), it will snap back to the server’s position.
This is great since it will help minimize both desynced positions and prevent exploits. But I have a concern: How will this affect custom movement scripts?
Take for example: You’re developing an Obby game, and using a script that allows you to perform a slide while running, this slide suspends your vertical velocity so you can slide over a ledge, stay in the air and THEN Jump to cross further gaps.
A very rough version of this script would look like this, as a LocalScript:
local slideSpeed = 32;
local slideAnimation: Animation? = nil; --set this to whatever your slide animation is
local isSliding = false
function exampleSlide(humanoid: Humanoid)
if isSliding then return end
isSliding = true
rootPart = humanoid.RootPart;
local slideTrack: AnimationTrack = humanoid.Animator:LoadAnimation(slideAnimation)
slideTrack:Play(0)
spawn(function()
while(slideTrack.IsPlaying) do
task.wait()
rootPart.AssemblyLinearVelocity = rootPart.CFrame.LookVector * slideSpeed
if humanoid:GetState() == Enum.HumanoidStateType.Jumping then
slideTrack:Stop()
break
end
end
isSliding = false
end)
end
But if the server has final authority on player movement, would this end up having to be moved to the server, and wouldn’t that affect the latency of the movement? How would we maintain responsiveness for this on the client while also adhering to the server having final say?
The introduction of Server Authoritative Humanoids is a great update for game security and consistency. It ensures that the server has the final say on player position, effectively nullifying most client-side movement hacks like flyhacks or speedhacks.
However, this has a direct impact on custom movement scripts, especially those that apply physics changes on the client, like your slide example.
How does this affect scripts like the slide?
Before this change, the client had more freedom to manipulate position and velocity for short gameplay effects. With server-authoritative movement:
The client can no longer permanently alter their character’s velocity or position using AssemblyLinearVelocity, CFrame, or Position.
Any attempt to do so will be overwritten by the server’s true state, causing visual snapping.
What does this mean for your slide script?
Your slide script that uses AssemblyLinearVelocity on the client may now:
Appear smooth locally but get snapped back to the server’s position shortly after.
Cause desynchronization, where other players don’t see your slide correctly.
Make the slide animation feel glitchy or off, because the physical movement is not respected.
What should you do?
To preserve both responsiveness and server authority, use a hybrid approach:
Client triggers animation and input logic:
Let the client play the animation and handle input detection instantly, keeping the game responsive.
Server performs actual movement logic:
Fire a RemoteEvent to the server when the slide begins. The server then applies movement (e.g. using Humanoid:Move(), PlatformStand, or AssemblyLinearVelocity) to make it legitimate and replicated.
Everyone sees the correct movement:
Because the server controls the movement, other players will see it properly, and the slide won’t be interrupted by position correction.
Keep in mind:
Any movement that physically manipulates the character must be reviewed.
Always validate whether the player is allowed to perform the move (e.g. not mid-air, not while stunned).
There may be a slight delay due to network latency, but it’s better than having unreliable or broken movement.
Conclusion:
Your slide system will need to be restructured so the server handles the physical movement, but you can still let the client handle input and play the animation locally for a responsive feel. Separating visual feedback from server movement logic is key when adapting custom movement to the new server-authoritative model.
The reason I use ChatGPT (or similar AI tools) to help shape answers is because I genuinely enjoy helping others, solving problems, and sharing knowledge within the development community. AI helps me explore ideas from different angles, validate technical concerns, and communicate more clearly and precisely.
Ever since AI became more integrated into workflows — even within platforms like Roblox — it’s become normal for both hobbyists and professionals to use it as a tool to enhance collaboration, learning, and productivity. That doesn’t replace our own thinking or experience, but it does help speed things up and sometimes bring up things we might overlook.
At the end of the day, it’s all about growing together as developers and building better systems by exchanging ideas. That’s something I really value.
I don’t always use it, because as everyone knows we shouldn’t rely entirely on AIs for learning.
Yeah but answering with autofilled ChatGPT prompts on a DevForum isn’t entirely helpful, as that is a response I could have gotten by asking the same thing to ChatGPT
It’s not a discussion you interacted with, and is the equivalent to (carbon dating myself here) redirecting someone to Let me Google that for you.
Since I am Portuguese, I have to put this in the translator, and sometimes it doesn’t come out right, so I have to review the entire text and put parts in the translator to “correct”, although it doesn’t completely solve my problems, I rewrite it in Portuguese and put it in the translator in English.
I even had to replace the right markers and help emojis to highlight what I was trying to explain, although the language translations are not completely perfect.
Nobody knows aside from selected developers that are under NDA in a private beta. As far as I know from research I did, you will likely replace your client script with AuroraScript which runs on both server and client. Roblox will likely handle synchronization and smoothing for you.
But for all seriousness, that sounds like AuroraScript (whose name I’m assuming is subject to change) is going to be a new RunContext for scripts, which would let it run on both the client and the server, but the server gets final say in terms of replication.
I’m going to have to do some reverse engineering and tinkering to find out
I honestly can’t wait to see the beta of Server Authoritative release for the public, and how much this will change Roblox for the better in the future.
Just hoping that it gets released pretty soon even if its half baked because i wanna see the full capabilities.
How does this affect scripts like the slide?
What does this mean for your slide script?
What should you do?
Keep in mind:
Conclusion: