Of course they can read them, they are replicated to them.
Everything that is replicated can be accessed by them.
However, to correct you: They cannot access the bytecode if required by a serverscript, since it’s not replicated to the clients.
The hacker will not have enough time to destroy both at same time without one firing, basically 1 nano second makes difference.
Here’s an example:
I have created 2 scripts inside workspace
The code for first Script:
workspace.ChildRemoved:Connect(function(part)
if part.Name == "Script2" then -- checks if second script gets destroyed
print("YES")
wait(0.01)
print("1")
wait(.1)
print("2")
wait(1)
print("3")
end
end)
Code for second Script:
wait(2)
workspace.Script2:Destroy()
-- the order here does not matter, since both scripts in your case checks for eachother.
workspace.Script1:Destroy()
If you run this, output will be just “YES” - even though it will have time just for 1 line, if you replace the print with RemoteEvent:FireServer() it should have time to fire.
To detect disabling the script, we can just use script.Parent.Script2.Changed(), also the script will notice it, since as i have mentioned - second script will still make output even after it’s deletion with the first one (also in second script - the one which deletes both scripts - it firstly deletes itself and then the first one. About the hijacking connections, i have no idea what you mean about that.
Actually about the disabling idk now, i’ll test it.
To detect disabling the script, we can just use script.Parent.Script2.Changed()
No. Your scripts won’t have time to react if an exploiter decides to get rid of your scripts.
You should do the logic on the server, NOT the client.
Anything that’s client-sided can be bypassed.
I have just tested it, it still prints “YES”, meaning it still had time to detect other script’s changing + printing it. 2 lines of code + maybe it also waited 0.002 seconds.
Script 1:
script.Parent.Script2.Changed:Connect(function()
if script.Parent.Script2.Disabled == true then -- checks if second script gets disabled
print("YES")
wait(0.01)
print("1")
wait(.1)
print("2")
wait(1)
print("3")
end
end)
Script 2
wait(2)
workspace.Script2.Disabled = true
-- the order here does not matter, since both scripts in your case checks for eachother.
workspace.Script1.Disabled = true
It won’t replicate, everything the client executes is client-sided.
Nor will they be disabled / removed, because the server-script won’t know that the client even edited it, as it doesn’t replicate.
What won’t replicate? This is just an example of a script having enough time to do something. To actually kick player, instead of printing “YES” it will Fire a remote event, which will afterwards be detected by server-sided script, which will kick player.
As much as I’d like to write something long regarding this topic, I won’t.
All you need to know can be found here.
Updated documentation link: here.
Never trust the client.
However, most exploiters have no clue on what they’re doing, in most cases a client-sided anticheat can be helpful at times, but that won’t help when the more experienced exploiters decides to play around in your game(s).
I know you all already have discussed it but to summarize:
Any sort of localscript magic you do can always be bypassed. Don’t try to put an anti-cheat on the client because it will always be removable.
If you want to make an anti cheat, do it on the server. For example, if you want to check the position of the camera, have a local script send over the info, and then handle it on the server. E.g. check if the camera movement is snappy (aimbot). But remember, they can always send false values (e.g. (0, 0, 0)) so always check that it is something valid (If the player clicks on an object that would not be possible to view if the camera was pointed towards 0, 0, 0).
can’t you just use ancestor changed or just property changed
I mean you can hook task and make it wait forever whit out even having to bypass it
same for property changed