So when you fire a RemoteEvent from a localscript and you send in arguments
event:FireServer(Mouse.Hit)
does the Mouse.Hit update itself in the server or the Hit position you sent is permanent? What I mean is like, you fire a RemoteEvent with the Mouse.Hit and in server script you got a script that creates a part and makes it follow your Mouse.Hit point. Will it update the position or stay in one place because the Mouse.Hit is a one-time variable?
It will stay in place unless you continue to fire that event when Hit changes.
The value of the property at that moment in time is sent to the server, not the reference to the property.
So how could I keep updating that position?
A while true loop would be sufficient for something like this, or a RenderStepped function.
So I would just keep on fireing the RemoteEvent from the LocalScript on a loop?
Yep!
Here’s the entire script you’ll need:
local RunService = game:GetService("RunService")
RunService.RenderStepped:Connect(function()
event:FireServer(Mouse.Hit)
end)
Alternatively, you could do this:
while true do
wait(1/60)
event:FireServer(Mouse.Hit)
end
RenderStepped is as fast as your framerate, so as long as your FPS is 60 FPS, and the server isn’t bogged down by something, you’ll get accurate results.
I do recommend, however, that you give each player a remote event to fire, as something like this with a full server might cause performance issues on the server.
No, it does not. You will have to continually update it with that event.
I wouldn’t recommend this, actually. Firstly, that’s trying to send data 60 times per second - which is way too much - especially considering it’s throttled to 20 sends/second as the server is capped at sending/receiving at 20Hz.
It depends on what you’re trying to do. I’d recommend sending data way less than that, maybe on a while loop less than 10 times per second. Then, you could use a tween to tween the positions if what you are doing is graphical. But, I don’t know what OP is trying to do, so it’s hard to know what the best course of action is.
This post above can be done by attempting a timed debounce.
local db = false
while wait() do
if db == false then
db = true
-- do what you need here
wait(0.5) -- make sure that it has a time limit until the next loop begins
db = false
end
Firing remotes in a quick succession is an overall bad idea. Especially on this occasion, as you’re giving the client way too much power with this one remote. I recommend handling this client-side, creating the part and updating it there in a loop.
If you’re trying to create a sort of placing script that when your mouse is clicked, it places a certain model / part in your mouse position, then I recommend only firing the remote when the mouse is clicked, and letting the server handle it after that.
I think this depends. For instance I wrote a bullet system that for security and proper replication, fires remote events dozens of times a second (ie “spawn a bullet with this trajectory here”) and works flawlessly. That said, I’m passing only a small amount of data per call.
That would work, but from the method shown in this post, it’s a really bad idea.
In general it is not a good idea to use RenderStepped. Heartbeat is the framerate of the game but it is one frame behind, so if you need to run a loop at 60fps it will work great, but you should use RenderStepped for camera and UI movements.
The reason why it is better to use Heartbeat is simple:
After RenderStepped runs, Roblox uses a separate thread to do other tasks, so rendering the current frame whilst simultaneously performing other tasks for the next. If you use Heartbeat, it runs just as fast as the game is running, but without holding up the rendering pipeline.
That said, it’s not a good idea to fire a remote event that sends mouse.hit to the server 60 times per second.
Also, wait(x) is limited to a minimum of 29 milliseconds, which is about 30 hertz.
So running
wait(1/60) -- Which is the equivalent of 16 milliseconds
will just cap at 30 milliseconds.
Why do you need the server to have Mouse.Hit constantly updated? What’s your use case? I feel like there’s something better that can be done here.
Hey there - so first off, there’s some inaccurate information in this thread. RemoteEvents can be fired very fast; there was even specific attention paid to them in this area in an update last year. It’s quite hard to get them to throttle (unless you were specifically trying to). When using remotes, minding your bandwidth is orders and orders of magnitude more important than than minding the rate limiter.
This being said, I agree with @colbert2677. Describe your use case!
As others have said, Mouse.Hit doesn’t update automatically; it’s static, so you’ll have to send it every frame.
I would recommend firing the remote every time the mouse’s Hit changed if you want it to stay up to date. You could do that with GetPropertyChangedSignal:
Mouse:GetPropertyChangedSignal("Hit"):Connect(function()
event:FireServer(Mouse.Hit)
end)
That will remove the need to fire it every frame, as it’ll fire whenever necessary.
It should be noted that Mouse.Hit is nothing more than a simple CFrame that indicates the position of the mouse in the 3D world. It is not some magical property and behaves exactly like how any other CFrame would if you send it to the server.
Couldnt this be simplified to a while wait(0.5) loop?
Nope, that is wrong. If you keep looping the FireServer(), you will end up causing the performance of the entire game to downfall or the game will just lag overall.