This post has more information about the situation:
Basically, I have to always broadcast each player’s mouse position to the server which lags the game a lot. This is necessary because the object the player is holding always has to point at the player’s mouse position and everybody else needs to be able to see it.
Current Script:
local Players = game:GetService("Players")
local RunService = game:GetService("RunService")
local player = game.Players.LocalPlayer
local mouse = player:GetMouse()
local MousePos = game.StarterPlayer.MousePos -- MousePos is a Vector3Value in StarterPlayer
RunService.RenderStepped:Connect(function()
MousePos.Value = mouse.Hit.Position
end)
MousePos.Changed:Connect(function()
game.ReplicatedStorage.RemoteEvent:FireServer(mouse.Hit.Position)
end)
I am very new to this, so any way to optimize the script is appreciated
You can use object:SetNetworkOwner(player) on the server and then just change position on the client side. This is also how roblox handles the characters of players. Note: I did not test if it works.
Roblox Vector3 uses three 64-bit numbers which is 24 bytes
(this method may result in a tiny imprecision)
we can use the buffer library to send 3 32-bit numbers which is 12 bytes (you can optimize it further like making the y axis 2 bytes instead of 4 if the map size y isnot that big etc…)
Example
local mousePos = Vector3.new(50.52, -14.234, 0.86) -- a random Vector for test
--OnClient
local bf = buffer.create(12) -- it stores three 4 bytes float which is 12 bytes
buffer.writef32(bf, 0, mousePos.X)
buffer.writef32(bf, 4, mousePos.Y)
buffer.writef32(bf, 8, mousePos.Z)
sendToServer(buf)
-- OnServer
reciveOnServer(buf)
if buffer.len(buf) ~=12 then return end -- check if the buffer size is correct
local mousePosTest = Vector3.new(
buffer.readf32(bf, 0),
buffer.readf32(bf, 4),
buffer.readf32(bf, 8)
)
print(mousePosTest) -- for testing
(you can use Vector316Int if the map size is between those bounds)
though am not sure if Roblox does optimize Vector3s when passed through the network since there are no sources
You could try to send it less often by recording a starting tick and measuring whether if the tick delta between the recorded tick and the current tick exceeds a set amount of time and reset the recorded tick into the current tick.
