This is not true. It depends on how you are using remote events and in this case I would consider the usage an attack point that’s not very well secured, and a weak one, but, the way it is designed is at its core pretty similar to what networking already is.
Saying that any usage of remote events = bypass is like saying that any usage of the network = bypass, which, is kind of true technically, but, it doesn’t really make sense to say that. It’s not about there being some kind of client authored communication, its about how that communication being handled properly and correctly.
@chessebuilderman The check actually doesn’t kick if the remote isn’t fired for 30 seconds, I think that was just a bad choice of wording. It is actually proper (though I think 30 seconds is too high) because the client is forced to advance a clock forwards (they can’t send 0, or go backwards). If they just advance it really slow, or don’t advance it at all, eventually their timer will be 30 seconds behind, and the check that was mentioned kicks the player.
Likewise, if they submit requests too fast or try to use giant dt
s for bigger thresholds, they’ll get kicked because their timer passes the server’s timer. This check gives a 1 second gap, but, this gap isn’t actually necessary at all since, well, the client’s clock should never ever be advancing faster than the server (unless you want to take into account special relativity I guess )
@CoinTheKit @0MRob I think you are missing some of the functionality in the script. I read it thoroughly, and, I can say that while I again disagree with this usage of a remote, at least a majority of the remote data is legitimately validated on the server at some point from what I could tell. That’s also including reported position not matching the replication position. The biggest concern with many of them imo is just thresholds that are too large, and, its a little bit spaghetti-ie. The anticheat at its core is robust, the execution is just not perfect.
@ScripterWaffle I did not follow 100% of the conversation so apologies if I misunderstood or missed something. While I again disagree with the usage of remotes here, the anticheat is not vulnerable to client sided spoofing from what I can tell, everything appears to be validated semi-correctly on the server, including spoofs. Again like I mentioned, biggest concern is probably thresholds being too large.
@wravager Checking stuff server side like Position, CFrame, etc can and does cause server lag, in fact this was something key brought up with the archived anticheat I wrote, which I mentioned above (GitHub - Hexcede/Hexolus-Anticheat)
@XaddyGoat I mentioned in more detail above, but, your assumption that disabling the client script would bypass this anticheat isn’t correct from my understanding, as the data is validated in a different location.