They probably used spawn() or coroutine.wrap() or such to prevent the yield from affecting the main thread, though exploiters can just hook that as well. As I said, you can’t really prevent that.
Well thanks v3rmillion hackerman so my best bet is to just use a coroutine that is wrapped around the code inside the remote event listener?
May I ask if you’re trying to use RemoteFunctions?
RemoteEvents spawn their own coroutines meaning they shouldn’t yield unless a coroutine uses :wait() on the event instead of :connect/:fire
in the case somewhere in your code you are waiting for a remote event signal on the server end its possible the exploiter is able to yield it unless that event connection is wrapped around a separate coroutine then you should be fine.
Well i have 3 at the moment but it doesn’t just affect remotefunctions.
How would yielding the remote call do anything? Are you making a client-side anticheat?
Okay so to check if an event is disconnected in my client sided anti exploit should i use remote functions so they can’t yield it?
I already have a client and serversided anticheat i just don’t want it to be yielded if i fire a kick remote and cause issues and yes i know i shouldn’t write an anticheat locally but i think i’ve secured it the best i can on the client and managed to make it difficult to remove and i’ve made sure not to trust the client
An exploiter can yield anything that’s being done on the client
Yeah i know which is why i want to prevent remote hooking so i can easily prevent yielding. All i have on my clientsided anticheat is events which im making sure can’t be disconnected. I want to prevent remote hooking so i can check client event connections on the server without it yielding.
Oh you’re talking about client sided anti-exploit, yeah well that’s not happening. I thought you were talking about exploiters yielding the server.
You can’t really do that, there would always be a bypass to any anti-hooking you try to do
No not really im talking about remote event hooking so i can help my client sided exploit.
Well clearly its possible and you can make it difficult to bypass since strucid has done that.
I recommend not worrying about anti cheat on the client, exploiters (good ones) will rather take advantage of the anti cheat on the client in some case scenarios without you even realizing it, the thing about validating a client’s actions is you can never trust the client thats why you have to validate everything passed through on the server end (in the sense you are trying to prevent exploiters of course)
The only good (good as in a probable use not that its a good use overall) use of RemoteFunctions (prefer to never use them to be honest) is when you invokeserver to return data read-only
RemoteFunctions should never be able to write whether its the client or server.
A few mistakes i came across when I tried anti cheat on the client is my friend tested my anti cheat for me and found that they can in some cases use the anti cheat to exploit the game depending on what the anti cheat is validating and wrapping, overall don’t pressure your self to create an anti cheat on the client if it will only make it worse in the long term
You can’t really help your client-sided exploit, you can put many roadblocks as you want but someone with some level of knowledge can bypass it without a problem.
Im not worrying too hard im worrying more about the server but It doesn’t really seem to hurt if you have an anti cheat to catch some skids until theres an anticheat bypass released on v3rmillion
I don’t care if its being bypassed in the end if its catching some people off then im fine with it
If you’re sending anticheat data from the client to the server then that’s a client-side anticheat
Yeah i know thats client sided but i’d be worrying more about the server if i knew what other exploits existed that can be checked on the server.
Not gonna tell you exactly how I did it but just try and encrypt the parameters in your remote events