They are set to Filtering Enabled by default
Yeah he wouldn’t of changed it,
I’m sure ive made a click gui without remote events before, all it needs to do is access the players stats and + 1 from a local script
I’m not sure why you would want to not have filtering enabled. It’s a way to prevent exploiters (not entirely), and I’m not trying to criticize you, but why would any player want to play a game that can be easily be exploited?
Could you show some example code of your solution and what you’ve tried?
I dont want it to be non - fe, as i said i dont mind adding remote events but the game woud be 1000x better with none/minimal as exploiters cannot hack the game.
local player = game.Players.LocalPlayer
local gui = script.Parent.Parent
local active = false
script.Parent.MouseButton1Down:Connect(function()
if not active then
active = true
script.Parent.Main.Visible = false
script.Parent.Second.Visible = true
gui.Size = UDim2.new(0.058, 0, 0.118, 0)
script.Parent.Sound:Play()
player.Stats.Coins.Value = player.Stats.Coins.Value + 1 * (player.Stats.Rebirths.Value + 1)
wait(.2)
gui.Size = UDim2.new(0.062, 0, 0.127,0 )
script.Parent.Main.Visible = true
script.Parent.Second.Visible = false
active = false
end
end)
Is the script i have used, It adds on the client as i have another gui showing your coins.
But if i go onto server view its not affecting the server and my datastore doesnt work because of this, resulting in unsaved data
Do you have filtering enabled on? If so, then the client can only see the change happen on their side and not the server side. Therefore, your DataStores won’t save the updated value on the client. Moreover, you would have to use RemoteEvents to make the change for both the client and server. Also, make sure your RemoteEvent can’t be maliciously used by exploiters.
1 Like
Yes filtering enabled is on, and ill do the checks all on the server, do you have any tips for this?
But how the heck has my friend done it without remote events though?
Filtering enabled off would most likely be the answer for doing it on the client. You can run checks on the server or use a cool down to prevent the RemoteEvents from being spammed. From what I know, tick() is an efficient way to prevent RemoteEvent spams. You can check the thread here.
2 Likes
RemoteEvents on their own are not insecure. Giving too much trust to the client is what exploiters take advantage of. You’re giving the client the entire trust over its stats by setting them in this script, which is not what you should be doing.
Ideally, here you’d have a call to a RE that tells the server “hey I’m doing this,” and the server would run sanity checks to make sure you can actually do something. Just note that at no point should you be changing player stats on the client, or having a way for the client to tell the server to change stats. It should only ask the server to perform actions, and the server should apply changes if the actions make sense.
1 Like
Okay thank you,
Is another good way to pass the least amount of arguments possible, to prevent exploiters more. Also is it possible at all to make a full anti exploitable game or is this just not possible.
Thanks for this, i succesfully made it work with my click cooldown, and if the remote event is fired too fast, the server kicks the player 
1 Like
Also update guys, my friend is using Scripts for his gui not local scripts,
Would this just be an easier option to do this or is there vulnerability/problems using scripts for gui clicking?
Ideally you’d pass no arguments for this example; you send the server the event and the server checks if you should be able to go through with it. If it decides you can, then it does the calculation itself without any client input and sets the value.
It’s also possible to make a game “unexploitable” in that users won’t get anywhere whilst trying to get the server to do things for them. This is done by the often repeated not trusting the client style of code writing. But you’ll never be able to stop people from firing your remotes or messing with things locally, so you need to think as if you’re trying to break your own system.
1 Like
Yes, with this no arguements have gone through (Apart from player obviously),
With my rebirth button, should i run checks also on the client aswell to prevent (For none hackers) The lag of firing a remote event everytime they click rebirth to check on the server, when it could be done on the client first aswell.
Also yes i understand you cannot stop them firing remote events,
And just to clarify, Any info received from the client should NEVER be trusted?
Would you say this is secure??
This is the local script:
local player = game.Players.LocalPlayer
local active = false
script.Parent.MouseButton1Click:Connect(function()
if not active then
if player.Stats.Coins.Value >= (player.Stats.Rebirths.Value + 1) * 50 then
active = true
game.ReplicatedStorage.RemoteEvents.Rebirth1:FireServer()
wait(.1)
active = false
end
end
end)
And the following is the remote event detector
local repstorage = game:WaitForChild("ReplicatedStorage")
local Rebirth1 = repstorage:WaitForChild("RemoteEvents"):FindFirstChild("Rebirth1")
local timestamp = tick() -- To stop spamming of the remote event
local cooldown = .1
Rebirth1.OnServerEvent:Connect(function(plr)
if tick() - timestamp >= cooldown then
if plr.Stats.Coins.Value >= (plr.Stats.Rebirths.Value + 1) * 50 then
plr.Stats.Coins.Value = 0
plr.Stats.Rebirths.Value = plr.Stats.Rebirths.Value + 1
end
else
plr:Kick("Dont exploit.")
end
timestamp = tick()
end)
It is less about the amount of arguments and more about the power given to the client.
Depends on your definition of “exploitable”.
• If you mean that the player cannot alter the gameplay at all, then no, it would not be possible to make sure of that, as anything the client can see is computed on the client, which means it has full control on it on their side. The client can also insert instances into their world.
• If you mean that the player cannot make server-wide changes (changes that the server and/or other clients can see), that would be difficult to accomplish depending on the game. For example, if you have a normal Roblox game where players can move normally in a normal environment, then clients would still be able to exploit their local character position and speed. However, if you have a game where physics are custom-made, or simply a game with only 2D GUIs (and maybe some basic 3D environment), then you can definitely make sure that clients cannot exploit server-wide changes.
• If you mean any game with RemoteEvents, RemoteFunctions, or any way of game developer-made client-server communication, then as mentioned earlier, it really depends on the power and freedom you give the client this way of communicating with the server. You can make checks on the server to validate the requests from the client to minimize the ability to exploit in your game, or, if the power you have given the client is already minimal, like sending information about which direction the client is currently looking at, then there is not much the client can exploit there in the first place.
I mean its just a clicking game, you click a gui for stats and theres another tab/gui to rebirth to get more stats.
I run checks on both the client and server now so surely it cannot be exploited because the script does not on either client or server if you do not have the requirements
All three points in my post talk about your scenario too. You could have read them.
There are many ways to deal with exploiters but limiting your use of remote events is more of a bandaid than a cure. Although yes you could program most of your game on the server-side, you will quickly come to realize that the client-side scripts become inevitable once you start implementing functions to your GUIs.
I suggest reading into Roblox programming conventions and studying how exploiters actually take advantage of shoddily programmed remote events and develop your game keeping in mind what you’ve learned.
Hey, I just made the local scripts into scripts, so the game requires no remote events