I’ve been encountering a problem in my game where there is a small lag spike when I kick a ball. I’ve included two videos to showcase the issue. As you can see, the ball behaves normally for a split second before experiencing a small lag spike before flying off into the wild.
I’m confident that the code for the ball’s physics is well written (a simple Velocity addon on the server side) and has nothing to do with performance. I believe the issue is withing roblox’s the client-server communication and simply is just network lag (your ping to the server).
If anyone has any suggestions for a possible solution to this problem, I would greatly appreciate any help.
What’s happening is that when the ball moves far enough away from your player, the network owner switches and that causes the lag. Make the ball always owned by the server by executing ball:SetNeworkOwner(), then you won’t get the skip, but this also means that all body movers and physics have to applied by the server. Not a bad thing since it prevents client-side exploits anyway.
@YosemiteMe@ItzMeZeus_IGotHacked That is not the current issue; the solutions you raised are well-known factors that were already in place when the video was shot. It has nothing to do with the ball’s network owner or the ‘SetNetworkOwnershipAuto’ property.
Also, @YosemiteMe, if you don’t provide the function’s target, the ball:SetNetworkOwner attribute doesn’t do much. As a result, your properly coded solution would include the ‘nil’ statement, making it ball:SetNetworkOwner(nil).
Furthermore, one alternative solution to the stated problem is that the ball is on the server. You see, even if you have the ball on the server, there is a latency lag and your ping will be affected by it. As a result, the lag would be caused by the server → client time difference.
However, this is not the solution since if it were, we would see 0 latency lag within Roblox Studio, because it is simulated on your PC and your ping is always 0. That is not the case; it still does the same thing in the studio. So that’s the end of my comment; the solution isn’t anything you two proposed, nor is it anything to do with the network.
Please consider posting to this article if you have any additional suggestions about what is causing this. Thanks.
I still believe you’re experiencing Network Ownership transfer lag (even in Studio). ball:SetNetworkOwner(nil) does actually change behaviour as passing nil locks it to the Server instead of changing between Server & Clients as it sees fit which is the default auto behaviour. If you want to check if the lag spike happens at network ownership transfer you can enable “Are Owners Shown” under “File” → “Studio Settings”.
I agree with @Noob_McDev and @CasuallyCritical. The problem is involving with the network ownership of the ball. So why can’t you just give it a shot and see if this makes any difference?
@Noob_McDev@CasuallyCritical@ItzMeZeus_IGotHacked Perhaps it was not clear in my response, but when the video was taken, I had already set the network ownership of the ball to nil. Thus, that is not the issue.
SetNetworkOwner() and SetNetworkOwner(nil) are identical. Lue treats the absence of a parameter as nil. This can be proven by testing SetNetworkOwner, but also with a simple script:
function test(val)
print("You passed", val)
end
test(nil)
test()
Output:
You passed nil (x2)
To test Network Ownership, turn on Studio Settings->Physics->Are Owners Shown. This will show you network ownership in real time by putting boxes around objects. Green is client-owned, red is server owned, and white is auto.
As many have stated, this is caused by the network changing from the client to the server. Although, :SetNetworkOwner(nil) will not fix the issue.
Solutions
An easy option would be setting the Network Ownership to the player. This should smooth out the motion, but it’d make the ball vulnerable to exploits and might look choppy on other peoples clients.
Another would be to have the server constantly set an attribute in the ball to match it’s server CFrame. You could then have the client set it’s CFrame to the attribute every frame. This could look choppy, so to resolve that you could tween or lerp the CFrame to smooth it out.
The hardest, but least laggiest option would be to create a clone of the server ball on the client. Then you could code the client ball to match the server balls position and velocity. Although, this would most likely require prediction and knowledge on lag compensation.
First, please accept my apologies for the delayed response; I’ve been experiencing severe hardware issues and have been unable to respond with clear information.
Now to the good news, I’ve identified the issue. Thanks @Noob_McDev and @YosemiteMe for showing me how to debug network ownership. As I previously stated, this is mostly not related to the SetNetworkOwnership() function; you all disagreed, and as someone with the information I provided, I would as well. Although the problem is with the network and not with the assignment, the assignment works perfectly, but there is one important piece of information I forgot to give you.
When I treat my ball system, I add the ball to the character of the player. Because the player’s character’s network owner is always client based, the ball cannot be granted server access while inside the player. This issue is no longer about a broad and unspecific question, but rather about…
Is it possible to make an object’s network ownership within the player’s character server-sided?
I apologize for any inconvenience, but thanks to those individuals mentioned above, I was able to identify the true issue and incorporate this critical piece of information into the topic.
After further investigation, I discovered that the network was not the only solution to the problem. It’s also because I unweld the ball from the player right before kicking it. So I’ve now solved this topic’s problem by simply adding a small delay to smooth out the vector addition. Of course, it’s far from perfect, but it’s watchable without causing too much headache.