I’ve got a problem where my turrets (which are rotated by Motor6D’s) are causing a ridiculous amount of ping lag (a casual 100k + ms ping). The turrets are driven from the server side, and there are a lot of them (ex: ~40 ships, each with ~6 turrets on average, each turret with ~2 gun barrels, with each turret and barrel having a Motor6D joint). Is there anything I can do to reduce the ping caused from these motor6D’s other than flat-out replacing them?
What makes you so sure the motors are the issue? Have you looked at the Micro Profiler to see if that’s for sure the case? Seems unlikely.
Ping is just how fast Data (In milliseconds) is being sent between your PC and your Internet, Are you sure you aren’t referring to Memory or Frames? And are you sure you have a Stable Connection to the Servers?
I also have strange things happen where ping is the only indicator that something is wrong.
You may have to try a process of elimination to isolate the problem. Disable scripts to see if that helps. If it does, disable things the script does one by one to see if it helps.
Or you could make an uncooylocked place for us to download and look at the issue.
I tested with and without the turrets, and they are definitely what makes the difference. I know it’s the Motor6D’s specifically because they’re the only thing I really changed since I used to use a hingeConstraint system.
They work just fine in Studio, but they lag hard in the actual client.
When I test the game without the turrets on the ships, the game works just fine with no problems, so it isn’t an issue with my own connection. When I test the games with the turrets, the ping goes up rapidly as the ships spawn in. Framerate is fine, but the lag comes entirely from server connection, with the controls being unresponsive and such.
Where is your code?
Generally if it’s causing remote lag you can try to reduce it to a lower interval or reducing the amount of data sent (Using less numbers ex using Vector3 instead of CFrame, or using more packed data Vector3int16 maybe).
The code is in a server-side module script which adjusts each motor6D’s desired angle on every heartbeat.
The code structure itself is kind of inconsequential to the problem (as far as I know), since I believe the main problem is something along the lines of motor6D replication from the server to the client. (For reference, I had almost the exact same code structure back when I used hingeConstraints instead of motor6D’s, and that worked fine aside from physics lag.)
I don’t think it’ll help much to show that particular code, but I can if you still want me to.
There are a couple things I can do to make it a bit more efficient (in terms of reducing the amount of times it changes the motor6D’s desired angles), but probably not on the scale of removing the 100k ping they’re causing.
Is it possible that I need to update the motor6D’s on the client-side instead?
That is possible, for an idea perhaps you can take a look at this where Instance.new on the server created lag spikes as it still needed to transfer server to client.
Possibly.
Any chance you had this jitter issue with Motor6D? Or is it just ping related.
I’ll check those posts and see what I can find, thanks! (I remember briefly looking at the second one and considering it, and it may be the way to go.)
On another note: I did some more testing, and found that simply the mere presence of the motor6D’s causes the ping lag—not the constantly changing their desired angles. I tried out what would happen if each ship only had two turrets (as opposed to anywhere from 2 to 12 turrets), and it still skyrocketed to a similar amount of lag.
If the case is that I can’t have the motor6D’s exist on the server-side, then that may bring a whole new slew of problems for me. (Specifically, there’s several other scripts which check the turrets’ motors for their current angles, connections, and such.)
Also, it’s just simply ping-related as far as I can tell, though I’ve had separate jitter issues with Motor6D’s overshooting their targets in the past (not at all in relation to ping, either) as well.
All right! I’ve (mostly) solved all my woes!
As it turns out, the 100k ping was being caused by a little detail I overlooked in another part of my code:
game:GetService("RunService").Heartbeat:connect(function()
for index, turret in pairs(turrets) do
-- ...(other stuff)...
-- THIS GUY RIGHT HERE.
game.ReplicatedStorage.RemoteEvents.GunTurnEvent:FireAllClients(index, turret)
-- ...(other stuff)...
end
end
It’s somewhat odd, because I also had that in my old code (which worked fine), but I think I had a couple other cases around it to limit its use. In any case, that explains a LOT!
Fortunately, all it does is send an update message to a client-side turret-turner which I’m not using at the moment, so I can omit it (until I possibly need it again in the future).
There were a few other performance issues that I had to deal with, particularly with the motor6D’s desiredAngles also being updated within that same heartbeat loop from above, which I mitigated by re-adding those aforementioned cases which make it only update a turret’s desired angle if its target point has changed or if the motor6D’s current angle has reached within 10 degrees or so of the desired angle.
Now, I still have the issue of the motor6D replication being choppy (and slightly jittery), and I’m still wondering how to go about fixing that, but I’m not sure if that’s within the scope of this thread.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.