Simple, you don’t.
You should always treat client as if it was compromised and add sanity checks for remotes to prevent exploiters from doing things they shouldn’t be able to.
4 Likes
That’s seems to be the general response in this thread, but a game that doesn’t trust the client at all isn’t a game, that’s more like a video if anything else. In fact, my whole purpose for making this post was actually CleverSource. He worked with us on the last project and I vaguely remember him having a method for getfenv, so I was curious if there was a specific method for this exploit.
I guess bottom line is you have to trust the client to some degree, and everything the client has control over is exploitable. An FPS game is much harder to make anti-exploit for than any other genre in my opinion, simply because half of the entire game relies on client control. I also have to balance things like performance and latency really well, so I can’t just constantly confirm with the server over every little input, because then it’s pretty unplayable.
1 Like
obviously you have to trust the client over input but you don’t have to trust it with much else
2 Likes
Its more accurately described, don’t blindly trust it. The server should always validate data.
If this requires you to dramatically rewrite your systems, then so be it.
2 Likes
To be quite frank with you roblox needs to add scriptable camera’s server side too. It literally would be so much easier to deal with recoil if camera was somehow server-side.
EDIT: I think i did find a way, though have not implemented it.
What you could do is send camera information to server, if no camera information is sent then you can kick the player as a form of payload.
What you can do is calculate the same recoil effect server-side and get the final camera destination. If it matches clients camera destination then you can just let them off or kick them. Though its only assuming player camera is not moved during these checks 
Blockquote
???
this makes absolutely no sense.
Was being sarcastic, "somehow" i thought i was being clear
Setting your script to Disabled from inside the script stops getsenv(), as it doesn’t work on scripts that aren’t loaded.
Here is an example.
script.Disabled = true
print("Hello")--code will still run!
I would recommend doing it on the first line.
Adding on to this, you should always check if the script isn’t disabled anymore, and if it isn’t kick the player.
while wait(.5) do
if not script.Disabled then
kickEvent:FireServer()
end
end
I wouldn’t recommend using a .Changed or :GetPropertyChangedSignal() event as exploiters could use getconnections() and disable the connection.
the best solution is stop using local scripts and use server scripts to handle functions and stuff
That’s not a good solution, you’ll cause latency issues and overload the server. You need to not be too paranoid about hacks, there are plenty of things that belong on the client. It’s a balancing act.