Is this remote firing too fast?

Help and Feedback Scripting Support
#1

At the moment I am trying to make the arm and neck replicate for others but still move smoothly. Whenever I fire the remote every 0.1 seconds it looks great. However when I move it to 0.5 is looks much worse.
0.1:

0.5:

So here is my final question:
Is firing it every 0.1 seconds too fast or way to much for the server to handle?
(Servers are only 8 players big.)

2 Likes
#2

I don’t believe so

I have a renderstepped thing that tracks head and arm movements and fires to the server after 1 step (i.e in half-stepped intervals (basically faster than wait(.1)) and I havent seen any issues.

#3

I don’t think it is too bad, but you should Lerp it. I recommend giving 0.5 because 0.1 for everybody on the server might clog the event. It will provide less lag, require less data transfer and isn’t too hard to do.

If you do not know what Lerp does or is, it’s linear interpolation. Any range between 0.1 and 0.9 (0 being part1 cframe and 1 being desired cframe) and it will be set to exactly to a 0.x amount difference between the two. For an in-depth explanation, click here

a small code example would be:

--imagine your OnServerEvent here, but passing a variable called newCFrame

for i = 0.1, 0.9, 0.1 do -- start at 0.1, go to 0.9, go up by 0.1 each time
ArmCFrame = ArmCFrame:lerp(newCFrame, i)
end

Hopefully that gives the jist, and it covers it well. If you move slightly, it will only lerp slightly. If the newCFrame and the old position is a huge difference, it will represent the speed of the transition while moving it smoothly.

I also recommend adding a proximity detector, cause there is no point setting arms of people that you can’t even see, and obviously we going for every bit of optimization here :mechanical_arm::sunglasses:

Hopefully no matter what you pick your game is good, and have fun developing

2 Likes
#4

You can just do it by delta time?

#5

Isn’t firing every frame really heavy on the server? I thought that it was bad to do

#6

I’ll switch the tweening to lerping and see how that works out. It was hard to find a fitting tween duration so hopefully this should work. Thanks!

EDIT:
Seems like the lerping is a bit too fast. I added a task.wait() between the joint.C0:lerp because it was instantly snapping into place. Any ideas?

game.ReplicatedStorage.Remotes.UpdateJoints.OnClientEvent:Connect(function(plr, data)
	local char = plr.Character
	local torso = char:WaitForChild("Torso")

	local neck = torso:WaitForChild("Neck")
	local rShoulder = torso:WaitForChild("Right Shoulder")
	
	local function lerpCF(joint, goal)
		task.spawn(function()
			for i = 0.1, 0.9, 0.1 do
				joint.C0 = joint.C0:lerp(goal, i)
				task.wait()
			end 
			
		end)
	end

	lerpCF(neck, data[1])

	if data[2] ~= nil then lerpCF(rShoulder, data[2]) end
end)


I’m trying to replicate something like breaking point, where the arm turns very smoothly for others.

#7

See yeah that is where my 11 PM brain messed up, you should wait as much as you are hoping to lerp, I would play with the values until you get something good. I also recommend for optimization that if someone hasn’t moved their arm that you don’t fire again.

I am 99% sure Breaking point is lerping, but possibly not as much because only one person is sending data as opposed to an entire server (which my method is built for, sorry to not be specific there.)

Firing all clients with only one person sending update info should be fine, again if you want to ease off firing too much, use the lerp.

1 Like
#8

The problem w/ making the waits longer is that the lerping will look more choppy right? Even if I lowered the time between lerps and made the for loop be more precise, it might not give the desired result.

Another question: Why not just use tweening over this?

Sorry I didn’t clarify, only one player will be sending their data at most for 10 seconds (unless they are exploiting which I can deal w/ by using some simple sanity checks)

#9

i have a game that fires a remote every render stepped to move the neck and it doesn’t seem to effect the performance, so i don’t think it would be too fast

#10

No, it isn’t, I’m firing one in a renderstepped event, no performance bug at all.

#11

10 calls a second is a negligible amount of network traffic, you’re fine.

@Evercreeper does have the right idea if you want to send it less often, but the implementation is a little different. You don’t want to have task.wait() or loops inside your event handler. You’ll get bugs where multiple handlers run and step on each other.

An alternative approach (again, not that you need it) is to

  • Change a “target CFrame” value whenever you get an event, and that’s it
  • Once per Stepped, move towards that “target CFrame” a little bit, wherever it happens to be at the moment.

You’ll always be behind the actual position with this scheme, which is why in some games they do things like predict where the object will be in the future so that it can be somewhat lined up. That seems like massive overkill for what you’re doing though, and you should just accept the delay.

1 Like