Is there anyother way to give positions to server from client?

Help and Feedback Scripting Support
#1

Hi, So i want to send a position from client to server, Because a part in the client is going to the players mouse and i send the position from the part thats on the client to the server, But because the position changes of that part, I don’t want to spam remote events unless thats the only way is there another way?

#2

If this will be used for placing objects (for instance a block building system), then you’d only have to send the position when the user is requesting to place said object.

On the other hand, if you want to update a part on the server based on the client, then one way to reduce data transfers would be to only send an update request to the server when the object has been moved far enough from its last position (An example would be requiring a minimum of four studs moved).
You could also look into UnreliableRemoteEvent.

1 Like
#3

So I quickly made simple dragging in 5 minutes and to avoid sending position with RemoteEvent I just Set Part’s Network Owner on Server to “Player” that drags the part and once player stops dragging set Network Owner back to “nil”:

I attached my place file with my Part Dragging script, you can take a look and ask if you don’t understand anything there.
DragTest.rbxl (52.6 KB)

Here is how it roughly works:

--Server
local Part = workspace.Part
local RemoteEvent = game.ReplicatedStorage.RemoteEvent

RemoteEvent.OnServerEvent:Connect(function(player: Player, status)
	if status == "StartDragging" then
		workspace.Part:SetNetworkOwner(player)
	elseif status == "StopDragging" then
		workspace.Part:SetNetworkOwner(nil)
	end
end)

--NOTE: I didn't test it with multiple players, make sure you have
--something to check if  part is already dragged by another player
  • Basically just do FireServer everytime player starts and stops dragging, you can also send the part to drag in parameters, but make sure it’s exploit-proof so exploiters won’t be able to control ANY Part

Another alternative is to use Roblox built-in 3D Draggers, this is basically just an Instance you Parent to the part and you can easily drag it, I never used them, but you can read more on the page I linked.

2 Likes
#4

For anchored parts or Weld and Motor6Ds, you need to use remote events. A good way is to fire an event every 100 milliseconds to every two seconds depending on the importance. Then use TweenService to ease-in the motion.

For unanchored parts or parts affected by Motor Constraints you can set the network owner of that part to the player by using BasePart:SetNetworkOwner(Player?).

1 Like
#5

beware that when a player has control of it, they might be able to destroy the part

1 Like
#6

You can spam remote events, it’s not really a big deal unless you’re sending a lot of data each call. Consider that that’s essentially what’s happening with ANY client controlled objects (physics objects etc) regardless - they’re sending position and rotation data to the server constantly while they’re moving.

You can reduce things by not sending data when the object isn’t moving for the client, or lowering the amount of sends per second and interpolating on the server. It doesn’t have to be bad for performance.

1 Like
#7

Thank you everyone this all works so idk who to give the solution mark to

#8

Positions are 12 bytes each, sending it through network will quickly overload it

1 Like
#9

If you do it VERY often then sure… but if you’re being reasonable at all then it should be fine. How frequently are you thinking it’d be done?

2 Likes
#10

Depends, pretty much lerping is best option, sending 5-10 updates per second wouldn’t be that costly, but it will benefit him a lot

2 Likes
#11

Yeah, that’d be reasonable. Roblox servers only handle RemoteEvents at 20Hz regardless, so the most would be 20 sends/second - 0.24KB/s send (some overhead too) if your stat is accurate. The server can absolutely handle a lot of players doing that, and sending that data shouldn’t be hard on the client.
Depends on the use case. For stuff like an FPS game, it’s probably more important to have an accurate server-side view of the client’s vision for validation purposes. But for visual purposes, lerping with low send amounts would be perfectly fine.

1 Like
#12

What he can also do to halve the size of a vector is using Int16s and compressing/decompressing them, which only requires multiplying by 1000 or so, it will only work if his map doesn’t exceed about 5k studs, but for most of the games

2 Likes
#13

looks like OP is newer to scripting / not at that point yet regardless - optimization in that way can come later, but it is good to know about. cool stuff!

2 Likes
#14

Not that hard, only use different type of vector and multiply, divide it each time he sends it, anyways thx for a talk, i wish i helped OP to solve his issue

1 Like