Hi, in my game game.Lighting.FogEnd = 300.
Is it possible to make sure a client isn’t changing this value or detect it when it happens? If I had a localscript that checks this, the client could just disable/delete it right?
5 Likes
This is not possible, because…
Correct. You have no control over what runs on clients’ computers.
You can still run a script that checks for this, but you have no way of knowing if the script is running. Most exploiters won’t know to disable something like that, but more experienced ones can and will, and they might tell the less experienced ones if your game gets popular.
The only way you can be sure that the client isn’t cheating is by not giving them any data about what’s happening more than 300 studs away, which isn’t a very worthwhile solution due to its complexity.
4 Likes
You could make the server periodically send a script (with a random code, random interval, and a random name so it’s harder to detect/modify for exploiters) to the client. This script would then return the value of the FogEnd back to the server + the random code.
If an exploiter would remove such a script, the server wouldn’t get a request back and can then assume the player is cheating. If the server gets a request back with modified FogEnd, you know the player tried to mess with it.
7 Likes
I just tested this out. Basically I inserted this LocalScript that would run this line of code:
game.ReplicatedStorage.RemoteEvent:FireServer("hi")
and in the client this exploiter script:
game.Players.LocalPlayer.ChildAdded:connect(function(c)
if c:IsA("LocalScript") then c:Destroy() end
end)
The server would still get the “hi” message. Could an exploiter still get around this 
What if the server gets a request back with the correct FogEnd even if the FogEnd is modified?
It’s possible to intercept any scripts with a certain source1, replace the source, and run the new script. It’s certainly more difficult, but it’s possible. You could also just delete the new script and trigger the RemoteEvent it uses with a completely different script.
1: it’s not possible to have dynamically generated sources, so it’s always possible to detect a certain script this way
Yes. Exploiters have access to more than just running Lua code. In fact, the Roblox client can’t run any new, from-source Lua code. It can only run pre-compiled Lua code from the server. Exploiters have to use programs that compile and run Lua code in a more complex way than just inserting a script.
It’s entirely possible for an exploiter to hook into the section that runs Lua code and check the source before running.
It’s also possible for them to replace the FireServer method so that it checks what script it’s being called from and doesn’t run if it’s not the exploiter calling it. Replacing FireServer was actually a common technique in the past (and possibly now) to discover what RemoteEvents a game has.
Something like that is actually a good idea if your game depends on players not being able to see past 300 studs, but it’s not foolproof. An experienced exploiter can beat any system that requires code to run on their computer. Keep this in mind.
Don’t try to make a perfect foolproof system because it can always be beaten eventually. You want to find a solution that will catch most exploiters while taking you only a small amount of time to develop. Then you can ban then remaining ones that you find break through. I can think of some fairly complex, hard-to-beat (but never impossible-to-beat) solutions, but the more complex they get, the less worthwhile they are to develop.
The only exception is situations where you ask the server before doing something or you can limit what information is sent to the client. There is extensive discussion on exploitation-prevention through sanity and validity checks on the devforums, so I suggest you look up existing discussions first.
6 Likes
Although this has already found the solution, implementing your own anticheat and certain precautionary measures you can find if a player or client is cheating. Just not in the way you described, but it is possible.
Yes. Either not allowing the RemoteEvent to run in the first place by deleting it or by making it so they can set the fog to 0, but make it so that any script that tries to read the value of FogEnd sees it at 300.
1 Like
Just have your client code in 1 or 2 scripts so disabling them would prevent them from playing or even break their game.
1 Like
Sometimes exploiters try to break the game, not to gain anything, but to ruin others’ experiences. For example, if the game relies on InvokeClient, then they can easily put the server on an infinite yield by disabling/deleting their own localscripts. Sometimes it’s better to have different scripts do different things, but other times it’s just preference.
Using InvokeClient on the server is not recommended. I never had a situation where I had to use it.
3 Likes
You could have a nil localscript that they can’t delete.
Hackers can extremely easily get scripts parented to nil, it’s provided as an API nowadays.
Correct me if I’m wrong, but I’m pretty sure a nil script’s code will run forever once parented to nil even if you try to delete it or disable it.
No, they just won’t reset if your character resets.
4 Likes
You could make a server-sided anti noclip handler. Track the player’s position and raycast between the last position to the new position. If the server does detect you going through a noncollidable object then it would kick the client.
(This method can be bypassed)
If you’re not accounting for latency you’re going to end up kicking a lot of laggy players turning corners.
1 Like
Track the head and torso positions and make sure if both go through a noncollidable object. Lag is really the only thing that is limiting this from working really.
Anyone who’s noclipping won’t have both the head and torso clipping through the wall, anyway. Lag is the only thing limiting it from working and it’s a pretty major limitation - that’s why writing anti-speed hacks, anti-teleport hacks, etc are difficult.
The only way I combat exploiting in my game by focusing on exploits that could give the exploiter a “god” stance level. A CFrame teleport out of my match rounds would allow the exploiters to win it instantly. So I made a check if they’re in the game area if not they’ll get teleported back in. Repeat it 3x and the server kicsk you.
1 Like
Well that’s an easy way for an exploiter to get someone they don’t like banned. Certain exploits allow users to manipulate other players.
Most “anti-exploit” checks can be easily false-triggered by having the exploiter mess with other players rather than themselves.
2 Likes