I have a lot of issues with remote function my script aren’t as clean, I need to add some code and it complicate a lot of things, so if there were a way to communicate Client/Server more efficiently I would really like to know it,
Thanks,
Fego2015
3 Likes
How about RemoteEvents? If your script don’t need a callback (return variables etc), I would suggest you to use it because it is one way communication between client and server and more easy to use (in my opinion).
- Client to Server
--client
RemoteEvent:FireServer(something)
--server
RemoteEvent.OnClientEvent:connect(function(player, something)
...do something
end)
- Server to client
--server
RemoteEvent:FireClient(player, something) --Communicate with specific player
--OR
RemoteEvent:FireAllClients(something) --communicate with all player
--Client
RemoteEvent.OnServerEvent:connect(function(something)
...Do something
end)
5 Likes
I think quite a few of us use RemoteEvents exclusively, including for 2-way communication in place of RemoteFunctions, so as not to have to work around yielding functions. This doesn’t automatically get you cleaner code, it will sometimes mean you have a some extra state in Lua that you have to track instead of just relying on the RemoteFunction yielding to keep your code executing in a pre-determined order.
4 Likes
If you only need to communicate to all clients, you can technically use any object (BoolValue for example). This is a very limited alternative. Don’t use it if you only want to communicate with a single client!
If you are just having trouble using a RemoteFunction (optimally a RemoteEvent), you could try creating a ModuleScript to interact with it on you’re behalf:
- You can check if you are running on the client or server using the RunService.
local RunService = game:GetService("RunService")
if RunService:IsClient() then
-- Client side
elseif RunService:IsServer() then
-- Server side
end
- The ModuleScript can create as many RemoteEvents and RemoteFunctions as you need it to:
local Library = {}
-- Server side only:
function library:AddFunction(name, callback)
local Remote = Instance.new("RemoteFunction")
Remote.Name = name
Remote.OnServerInvoke = callback
Remote.Parent = script
return Remote
end
-- Client side only:
function library:CallFunction(name, ...)
script:WaitForChild(name):InvokeServer(...)
end
return Library
The benefit of a ModuleScript is that you only need to write it once. Feel free to use what I provided as a base for yours (if you go with this idea). You just need to make sure the module is in a place both the server and clients can access, and to properly test your code.
If there is a technical problem with a RemoteFunction, be sure to report it! I don’t know about Roblox (they don’t really define what a bug is to them), but I consider unexpected behavior a bug.
6 Likes
How are using remote functions unclean or complicated? I find them very clean and convenient for client to server communication or vice versa. Use remote functions for a signal for them to do something. Use a remote function when you need information. I don’t see how these ways could be unclean? If you want it to be clean, make it.
local replicatedStorage = game:GetService("ReplicatedStorage")
--REMOTES
local remoteEvent = replicatedStorage:WaitForChild("RemoteEvent")
local remoteFunction = replicatedStorage:WaitForChild("RemoteFunction")
local function doSomething()
--do stuff
end
remoteEvent.OnServerEvent:Connect(doSomething)
remoteFunction.OnServerInvoke = doSomethingI’m getting a little frightened with the replies
If you need to send something across the server/client line and you don’t care what happens on the other end, use a RemoteEvent.
If you are sending something and you want to wait for the reply, like if the client sends an action request to the server and waits to hear if it went through or not. Use a RemoteFunction.
If you need to send a mass server -> client broadcast message, and especially if its for a workspace part and you’re using StreamingEnabled, and CollectionService then MAYBE a value object changed subscription will be better.
8 Likes
Yes. For example, if you’re programming a statusbar in a GUI, instead of using a remote function to check the current status, simply subscribe the client to a property changed event for a value in replicated storage.
Then, all you have to do is modify this when you want the status to change. Of course, you should only do this when you don’t mind any client being able to modify the value, like the example I gave.
2 Likes
But can’t this be exploited du to it being client-sided ?
1 Like
Anything the client can do can be “exploited”. At the end of the day, any program that runs on a users computer can be changed to do whatever that user wants.
Sanitize and verify your user-sent data on the server. Especially so if the server needs to rely on any input from a client.
1 Like
Well, yes. It can be exploited. But that is why I said that you shouldn’t use this for something important.
But is it really that bad that an exploiter can change the text in your status bar?
Anything the client doesn’t need to see, shouldn’t be in the workspace or replicated storage.
1 Like
Yes, because something that any client can change, which replicates to all other clients, provides a channel for exploiters to send inappropriate, unfiltered text to other players, which is a good way to get your game moderated.
2 Likes
Correct me if I’m wrong, but I don’t think any changes to a property in ReplicatedStorage on the client side actually replicate to the server or any other clients.
As said by the wiki page on ReplicatedStorage:
Because of this, you could subscribe to :PropertyChangedSignals in replicated storage to observe changes made by the server, while ignoring any changes made by other clients.
Exploiters would need to access replicated storage through other means if they want to make their changes replicate to the server.
4 Likes
This is correct. It’s one-way replication in the FE world. It would be a disaster if client code could freely alter the contents of ReplicatedStorage for everyone. You could exploit all the things!
2 Likes
This is a very insteresting and clear discussion on Client-Server MMO programming. I think it should be added to the docs. Thanks all.
Stay Creative