Click gui for stats [Remote events?]

Sorry if the title isn’t very clear,

Me and a friend are both making a same style game, I had some issues yesterday and the GUI only adds stats on the client and not the server. But my friend is using no remote events and it adds on the server?

Why is this?

I’m not against using remote events, i will if i have to but its more secure to not too if possible.

The main thing im confused about is why does he not use remote events and it works but mine doesnt and only adds the stats on the client?

1 Like

Perhaps his game is not set to filtering enabled?

Are games not automatically set to filtering enabled?

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)

@Autterfly

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 :slight_smile:

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