Hey, recently I started working on a new game with two others (AxisAngle and Datastore) and we (AxisAngle) have come across a problem/bug when working on our animation replication because we’re using joints to animate the characters and using the joint’s C0 which is set locally and there is only one way to transfer data and that is by using Remote Events and that means we’re using around (Players^2 * updaterate) FireServer()/FireClient() per second and that causes a tremendous amount of network/server lag. With ROBLOX currently not having any other alternative to Remote Events that are efficient and are needed to keep our key aspects working we may have to disable FilteringEnabled and we don’t want to do that at all. I am hoping that ROBLOX can either give us a nice feature or fix this problem by removing some of the network lag caused by server hundred calls to/from Remotes to give us less limitations on the FPS for animations on each client, while we try to limit our send/receive rate for the client and server.
Remotes aren’t intended to be fired that often. You should either be interpolating between less-frequent requests or if you’re using preset animations, a system such as this:
module:
local animations = {}
animations.reload = function(target)
end
return animations
Client:
local animate = require(replicatedStorage.Animate)
keypressed:
if key == “r” then
animate.reload(localPlayer)
replicatedStorage.AnimationRemote:FireServer(“reload”)
end
replicatedStorage.AnimationRemote.OnClientEvent:connect(function(target, animation)
animateanimation
end)
Server:
replicatedStorage.AnimationRemote.OnServerEvent:connect(function(invoker, animation)
for _,player in pairs(game.Players:GetPlayers()) do
if player ~= invoker then
replicatedStorage.AnimationRemote:FireClient(player, invoker, animation)
end
end
end)
That way you’re only sending #players requests per animation (hardly anything at all), and all animations play at 60 fps instead of 30 fps that you would get if you did it from the server.
I don’t think this is really a bug but rather inefficient use of network messages. So if I got this right, every client is sending, say, 30 messages a second, and you pass on these messages directly to the other clients? That means if you have 10 players, every player receives (in theory) 270 updates a second?
[size=6]HOW MANY TIMES DOES IT NEED TO BE SAID THAT IF YOUR REMOTES ARE LAGGY THEN YOU’RE DOING IT WRONG?[/size]
When a client wants to animate, instead of sending EVERY SINGLE CFRAME, store the animation data itself in somewhere like ReplicatedStorage. Then, all the client needs to do is tell the server, “hey, I animated.” The server then distributes to each other client, “hey, this guy’s animating.” The clients then animate the character locally. This system ensures that each client sees the animations as soon as possible, and all you’re sending along the network is simply that you are animating, and which animation is happening on who.
The thing between your ears should probably have keyed you in that sending thousands of CFrame interpolations is probably going to hurt a network.
Clients and servers don’t have infinite download speeds, nor do they have infinite upload speeds, nor do they even have stable or reliable connections. If I hear someone say one more time that the animations are dynamic so it has to be this way I’m gonna lose it. If you have your animations set up properly then each client will be able to accurately simulate the animation with nothing more than a single request to starting running the animation.
And if you honestly truly believe that there’s no way that dynamic animations could ever possibly work without sending a billion CFrames then you should consider just not doing that, if you want a playable game that is.
If you’re sending CFrames all the time then you’re doing it wrong.