Hey there, I’m currently tweening the player’s humanoid root part on the client and there seems to be an immense delay between the client and server, as shown below:
https://gyazo.com/0bff5d44db4945f2983b119383da6ca7
I want to completely prevent this from happening, I initially thought of utilizing body movers since it replicates extremely well but I need precise timing as to when the plr would arrive at the location (This is where the time scale property in tweens comes into play)
Any help is appreciated
1 Like
That’s an unusual result due to the fact that the character model’s network ownership is set to the player. The only problem I can imagine with this is either some weird Roblox bug or just really bad latency. Have you tried testing in game? If the delay is still really bad in game then I would begin to assume it’s a Roblox problem.
Yes I have, the ping fluctuates between 50-75ms and the issue is still occurring. I presume this is an intended feature and I don’t think it is feasible to resolve it without a plunge in performance. Is there any other alternative ?
What is the order of events here? Are you simply Tweening the movement of the player on the client? Tweens I have noticed have some delay in the exact execution of when the tween can build and execute motions. There is always going to be some latency when you tween an object that the server is continuously tracking (i.e. the player) on the client and the server then realising that a huge movement just occurred in the players position. Everytime the tween updates the players position it has to send that info to the server and then replicate back to to every client so the graphics can update, this is a two way ping that will slow the whole thing down. Just like when you press forward to make your character run, these basic and continuous events will be heavily optimised by Roblox to remove latency, movements are small enough and are based on fixed animations using a server based physics system. I think they key here is to tell the server when the movement is about to happen, possibly build the tween on the server and send that to the client to be executed after the server becomes aware of what is about to happen to a continuously tracked server based object. Or just execute the Tween on the server which removes at least one branch of communication.
When you press forward and the player moves 2 studs, the client tells the server what happened and it replicates the stud change to all clients to perform the graphical effects. Only a small bit of info is being exchanged (movement of 2 studs). What you are doing is making huge changes to the player using local animation techniques (probably several stud changes in position, orientation, etc.) which is a lot more info than moved forward 2 studs, and all this info is being sent to the server while the client is already under stress performing the actual animations which is slowing down the communication.
Yeah I’m just tweening the player to a certain position
I don’t necessarily think that the latency really matters in this case as the plr is moved in the server right after the client’s tween has finished: https://gyazo.com/3507d09fcc6e187799286c8ca8bd1a9b (The 0.76s is the tween time)
I have tried this and it is extremely laggy as the server would have to send the player’s position every time it gets updated to each and every client, making the movement very choppy and glitchy
I have tried this and it is extremely laggy as the server would have to send the player’s position every time it gets updated to each and every client, making the movement very choppy and glitchy
You may have to test different code and benchmark each. Because this method at least only goes:
server->all clients.
But with the extra branch of the client telling the server the player moved (heavily influenced by the client and it’s current state,ping,etc.) and then having to broadcast this after receiving the new position from a single client.
This method goes:
client->server->all clients.
If I want to execute the tween smoothly in the server I would have to set the network ownership of the plr to the server itself which can easily facilitate other unwanted lag.
I still don’t get your point, can you please elaborate ?
Even though that would work (As in replicating the tween for OTHER PLAYERS), what I desire here is for the server to read where the player is going, the CFrame of the plr and what not.
The method you are currently using is this:
client->server->all clients
i.e. you move player on the client, client tells server of movement, server tells all clients (including yours)
I suggested doing it on the server which removes that first branch:
server->all clients
i.e. server moves player, server tells all clients (including yours).
1 Like
Even though it replicates, tweening on the server is extremely laggy (It exacerbates when the any plr has unstable ping) and I prioritize performance here since this “Tween” is used very frequently
1 Like
Old, but just fixed a similar issue. Do you anchor the HumanoidRootPart on the client before tweening? If so, try unanchoring it.
It is bad practice to tween unanchored parts, but idk about tween characters when unanchored.
Works just fine for me. Replicates fine too for the other client.
Here’s an example:
https://gyazo.com/889941294beda68d3ccb55458df78a16.mp4
1 Like