Faster way to get Mouse Position

Help and Feedback Code Review
#1

Hi, I’m trying to find a way to get the Mouse Position faster, right now I’m sending UDIM2 positions via Remote, but I want a way to get the position quicker.

I’m also open to any way to make my coding more beautiful.

Local Script (Client Side sending data to server):


local player = game.Players.LocalPlayer
local RS = game:GetService("RunService")
local mouse = player:GetMouse()
local rem = game.ReplicatedStorage.Mouse

mouse.Move:Connect(function()
		
		local Pos = UDim2.new(0,mouse.X,0,mouse.Y)
		
		rem:FireServer(Pos)
		
	end)

Serverside (Receiving the info and tweening the GUI.):


wait(3)


--Define

local rem = game.ReplicatedStorage.Mouse
local block = game.ServerStorage.Shot


rem.OnServerEvent:Connect(function(plr,Pos)
	
	local MainGame = plr.PlayerGui.MainGame
	
	local XL = MainGame.X
	local YL = MainGame.Y
	
	XL:TweenPosition(Pos, Out, Linear, 0.1)
	YL:TweenPosition(Pos, Out, Linear, 0.1)
	
	
end)

Im sending the mouse position to the server because I’m planning to do something there.

#2

There’s no way for the server to receive the mouse position faster. Your bottleneck here is how quick it takes the request to travel over the network. What exactly do you need the mouse position on the server for? Your use case is important, that can’t be hidden away.

You should also not be doing the tween from the server. Update it from the client.

#3

Alright thanks, I was going to put a GUI that replicates on all clients. That’s why I’m tweening from server

#4

If you want other clients to update the position on their end, have the server fire back to every client except the one who fired the remote. Don’t do any tweening from the server: you should (almost) never do any interface work from the server.

Unfortunately, even though I say this, this is just addressing bad practice in the code. Your code is still ultimately bottlenecked by the time it takes for the request to travel the network. If you do it properly, then you have another bottleneck introduced:

  • How fast the server can receive the first client’s mouse position.
  • How fast other clients can receive information the server gives them.
-- Client:
RemoteEvent:FireServer(position)

RemoteEvent.OnClientEvent:Connect(function (position)
    doStuff(position)
end)

-- Server:
RemoteEvent.OnServerEvent:Connect(function (player, position)
    for _, otherPlayer in ipairs(game:GetService("Players"):GetPlayers()) do
        if not otherPlayer == player then
            RemoteEvent:FireClient(otherPlayer, position)
        end
    end
end)
1 Like
#5

I agree with @colbert2677, there isn’t much that you can do in this case to help with the tweeting of the GUI.

But for the sake of adding something to the discussion, I’ll add that it does make it easier to read code when the variables are fully spelled out and easily read.

This is probably just personal preference for me but I find it easier to write when I know what I’m tweaking with.

#6

Alright thanks for the feedback, I just do it so I can code quicker.

#7

I’ve used RemoteEvents a lot but never messed with .OnClientEvent, I’m guessing it just communicates with the client instead of the server for this type of situation (Updating everyones client instead of server)

#8

OnClientEvent is the reverse of OnServerEvent. Same thing, but the environments that are sending and receiving are flipped around. Your LocalScript connects to OnClientEvent to catch whenever the server fires a client. That’s exactly right, yes. The server just passes information back to other clients and they update positions themselves.

#9

Using remotefunction would be better instead of firingserver

#10

Those are not functionally the same. A RemoteFunction allows you to perform a round trip between the invoking client and the server or vice versa - this is a single-client action. The intent of the reply is focused around OP’s use case which is hand-replicating position data to each client instead of depending on the server to set it for other clients.

RemoteFunctions would not work or achieve the same effect for OP’s use case but you’re welcome to add in the missing explanation of why you felt RemoteFunctions would be better for this use case than RemoteEvents and how they could achieve a similar or better result.

1 Like