Suphi has a video on this:
Client:
local character = --path to character here
local hrp = character:WaitForChild("HumanoidRootPart")
MyRemote:FireServer(hrp.CFrame)
Server:
MyRemote.OnServerEvent:Connect(function(player, frame)
if typeof(frame) ~= "CFrame" then return end
print(frame)
end)
But yeah, I don’t recommend using RemoteFunctions.
Actually, I think that remote functions are safe when it’s the client that make the request, but if the server make the request, exploiters and hackers can make that it won’t return and the server script will wait forever.
So if you want to use remote functions from server request, I advice to use two remote events or one, idk how you can make it with one, but yeah.
Okay, has anyone ever attempted to get the humanoidrootpart cframe from the client because of server delay/inaccuracy?
Like this you can see that when you’re moving, the projectile starts where the humanoidrootpart is on the server, but not on the client which is where you see the player actually is.
Just as long as you have server checks, I think remote event/functions are safe
Let the client tell the server where the HumanoidRootPart’s CFrame is. Just validate the data type server-side.
In the majority of cases RemoteFunctions should only be used to invoke the server. It generally isn’t advised to invoke the client with RemoteFunctions because the client could indefinitely yeild the server. If you’re thinking of invoking the client try and figure out a different approach or way to make what you’re making. Chances are there probably is a better approach that doesn’t involve invoking the client.
In cases where you have to invoke the client and have no other choice make it so the server assumes the client wont ever respond. In other words, make it so the server assumes it be yielded. Also, any data send from the client shouldn’t be trusted so make sure to validate it.
It is worth noting that using RemoteFunctions to invoke the server is considered safe because any data sent from the server shouldn’t have been tampered with. Also, the server wont yeild the client forever unless it has been specifically coded to or there is a bug caused on the developers part.
You could solve this by:
- Sending current client-sided position of character.
- Predicting future character position (simple moveDirection operation on client-sided which is then sent over remote).
Although be careful you need to set arbitrary limit of wiggle-room so that player can’t fire from any position, and you might need to check if player’s desired predicted position is inside-behind wall.
For your usecase, just sending the client-sided position should be fine because remotes are quick like that.
Do you know of any other viable solutions than invoking the client?
Just letting myself into this conversation.
Just have remoteEvent which fires request for the data to specific player and then player sends these data to server. Server then processes these various data. It is that simple.
Simpliest form of this is:
local function foo()
local someRemoteConnection
remote:FireClient(player, "Request")
local function onServerEvent(recievedPlayer, data)
if recievePlayer ~= player then
return
end
--// Call function outside for further processing, or do additional operations with these data here.
someRemoteConnection = someRemoteConnection:Disconnect()
end
someRemoteConnection = remote["OnServerEvent"]:Connect(onServerEvent)
end
Now, this approach has the possibility of implementation with server-sided yielding, meaning no data after some period will be processed just as:
task.delay(yieldTime, function()
someRemoteConnection = someRemoteConnection:Disconnect()
end)
Oh okay when I come back I will see. This looks like a good way to approach it
Does this somehow cause performance issues or anything issues like that?
This doesn’t have any inherent performance issues besides making one additional connection, which is then disconnected after yieldTime (or if player sends desired data).
Would this work with multiple players using the same remote to get their humanoidrootpsrt c frames?
Yes, because in that code I wrote you are checking for requests from specific player and if it isn’t that specific player, execution halts. You just need to verify the data player sends with typeof() and if it matches, then you are good to go!
Alright let me try it out soon
I am back home now and am able to start testing it out. I watched the video PhoenixCausesOof suggested (by Suphi) I might use his module as it seems it’s just remote functions but more secure. Could you take a look at it and see if it is viable?
I don’t have time for that, you might have to check it yourself, or just ask some of your friends.
Yeah I did looks good. Basically does what you were saying but simplifies it. Has custom yield
I don’t think using a RemoteFunction to invoke the client is the best solution in this situation. You’re basically doubling the network delay here because the server has to send a signal to the client requesting their position and then the client needs to notify the server of their position.
I’m assuming you’re trying to make a projectile system that doesn’t appear laggy? A possible solution is to have the client manage as much as possible to eliminate any network delays. The only things the server should be used for is hit detections and validations.
When a player shoots a projectile handle all the movement/effects locally and then use the server to check for hits and do any validations it needs to do. To have other players see projectiles, fire a RemoteEvent from the server to each player with the data about the projectile(start position, end position, direction) and have them create and move the projectile locally.
This thread below explains it much better than me: