i used one RemoteEvent and one RemoteFunction for everything, so basicly exploiters will have a bad time guessing how to do stuff
Wait so if you make a boolvalue in workspace, and change it on the client, it will only change for that client? Is that what you were saying? because that doesn’t sound right to me… ill have to test it
filtering enabled or not? if yes then it wouldnt replicate
Yep. That’s the point of FilteringEnabled – changes made by the client don’t replicate to the server or other clients, so you don’t have to worry about people messing with your game. If you change anything on the server though, it replicates to all clients as normal.
oh. and that should always be enabled for security, correct?
okay this I did not know. I’ll use remote functions/events then
One more question. Could hackers also see my code on the client side?
Yep. Clients have access to everything on their local machine – no way around it. You can obfuscate your code so that if someone tries to use it, the variable names are rubbish, but that won’t do much good. Your best bet is just making sure anything security-related is done on the server so it doesn’t matter if they know how the client works.
1 Like
If an exploiter happens to run one of the RemoteEvent/Function. What do you recommend how I should go about this?
would an instance in workspace be the same on the server and clients or would it be a duplicate on the client? For example… would workspace.Part (in a server script) == workspace.Part (in a local script)?
You should set up your remote events in a way that they can be verified. For instance, instead of having a RemoteEvent “GiveMoney(amount)”, you’d have “RequestSellItem(item)”. The server would be able to verify that you had the item in your inventory and determine whether the request is legitimate or not.
Yes, all instances created by the server (which includes anything present on startup) are synced to the client. You can break this sync by deleting the object locally and then creating a new, duplicate, but otherwise they’re the same.
3 Likes
dumb question lol. just making sure, thanks
still not sure how filtering enabled works I guess
Thank you.
Clients, can change stuff in game but does not replicate what changed to the Server. Basicly if you are playing sound from local, while filtering enabled, only you can hear the sound. This prevents most of exploits from destroying your game.
Actually sounds are one of the exceptions for FilteringEnabled for legacy reasons. Roblox added a property to SoundService called RespectFilteringEnabled though which makes them behave as expected – this change was made in response to an exploit. A lot of the exceptions to FE have been patched for similar reasons.
Sorry if I’m bothering you. I really appreciate your help. Would having a “Script” in a tool which accesses a folder in “ServerStorage” be exposed to the client?
I don’t know if I should make a new thread. If I should be doing that, can someone let me know?
Yes. Any ‘Script’ anywhere would have access to serverstorage. Inside a player’s camera or inside a ‘Message’ /‘Hint’ created by the client MIGHT be two exceptions since those only exist on the client, but I know that a tool is not an exception here.
ServerStorage is only accessible from the server. I’m saying if I use a variable to get something from the ServerStorage from a Script inside a tool, would it be leaked? I’m only getting it, not changing or parenting or whatever. Just getting something from ServerStorage in a folder. Basically getting data from there and then only using it throughout the “Script” nowhere else (the script is inside a tool which is accessible from the client)
What I am doing: the players roles are in a folder in ServerStorage and the tool the players have, check to see other players roles which the Script checks in ServerStorage in a folder so exploiters don’t know but I don’t know if it leaks that data if the Script is accessible (in a tool) to the client
It’s in a ‘script’ and the values are in serverstorage, so you should be safe. Although, if you need to access client only information for use of the tool, you might have to switch this up and use a ‘LocalScript’. Instead of keeping the values in server storage, you could make a table in a server script and use a remotefunction to retrieve the value. Here’s an example
–Script inside of ‘ServerScriptService’:
local playerRoles = {}
local GetRole = Instance.new(‘RemoteFunction’)
GetRole.Name = ‘GetRole’
GetRole.OnServerInvoke = function(player)
return playerRoles[player]
end
GetRole.Parent = game.ReplicatedStorage
–Local Script inside the player’s tool:
local GetRole = game.ReplicatedStorage:WaitForChild(‘GetRole’)
local role = GetRole:InvokeServer()
This would let you access the role value in a player’s local script without the possibility of exploiters being able to change the value of the role. Although, it would be up to you to populate the ‘playerRoles’ table with the player being the key, and the role being the value. Anyways, that’s all the help I can give you. Good luck
Thank you. Although it isn’t just “client-only” data, that folder is used for every client and the server itself including multiple scripts. It is a server-wide folder