✓ Accepted answer
I don't have any metrics for that, but it's generally a bad practice and for the sake of this answer, we're just not gonna do that. Here's what I think you could do instead:
Send updates to the server at a much lower frequency, say, 5 updates per second. This would ease the load on the network because you're not sending requests 30 or 60 times per second. Additionally, you could run a check to stop sending updates when there hasn't been any mouse movement for some period of time.
Handle those updates by interpolating (tweening) the joints when rendered on other clients. This would make the movement seem smooth enough, despite not receiving updates at every frame. Note that doing this would also make up for latency issues or network/internet lag. This is necessary, without it, other characters would look... jittery.
Make adjustments to the number of updates per second, to get that smoothing to look good enough while taking into account the performance levels. Maybe the network can handle more updates per second, maybe it can't, idk.
Oh, and another tip: your update function should ideally just send the angle of the camera tilt, instead of the joint CFrames. Sending just one value over a CFrame which has about 12 values(don't quote me on this, it's probably inaccurate, but the point is it's much smaller than a CFrame) is bound to make a difference when you're running the updates at high frequency times the number of players. Let the client handle the CFrame interpolation and offsetting of each joint based on the angle.
Normally I'd provide a code sample, but this one's a bit less simple than the other questions I've provided an answer for, so have some pseudo-ish code instead:
RunService.RenderStepped:Connect(function(delta)
local CameraTiltAngle = GetCameraTilt()
for ("each joint you care to update") do
Joint.C0 = offsetJoint()
end
end)
local updateFrequency = 1/5
spawn(function()
while true do
wait(updateFrequency)
if isPlayerMoving() then
JointUpdateRemote:FireServer(GetCameraTilt())
end
end
end)
JointUpdateRemote.OnClientEvent:Connect(function(player, angle)
local char = player.Character
if not char then return end
for ("each joint you care to update like neck, shoulders") do
spawn(function()
local targetC0 = CFrame.new("cframe of that joint offset by the angle")
local alpha = 0
local tweenConnection = RunService.RenderStepped:Connect(function(delta)
alpha = alpha + (delta * updateFrequency)
Joint.C0 = Joint.C0:lerp(targetC0, alpha)
if alpha >=1 then
Joint.C0 = targetC0
tweenConnection:Disconnect()
end
end)
end
end
end)
If you'd like to learn more, you could read this guide from EgoMoose. It suffers from the same problem, though he did mention that he's updated the blog and is just waiting for the approval of the change.
Hope that helps!
4 comments
it would only lag a lot if the waiting time between frames is unusually short
well u could make it so only when the player moves the mouse u update??
on an FPS thats gonna be like... all the time.
conventionally in FPS games, the client's update time would be much greater than the servers. this means that the client will see a much cleaner view of their gun, their arms, etc. the server, however, does not need to see such great detail, so you can send less updates