Alternative for .touched (Exploiters can delete touch interest)

What is a way to detect touch on the server that cannot be exploited like the current .touched event that can be deleted or seen by an exploiter? I’m developing a glass bridge type of game (i know its soo original), but exploiters can see and also delete the touch transmitter/interest and just walk on the part so I’m looking for an alternative that is the same in the performant side of things. If you have any module or something like that please reply it below. Thanks!

2 Likes

You can try

workspace:GetPartsInPart(part)

Or

Part:GetTouchingParts()

Then go through them with a for loop and see if it’s a player that touched

Note: I typed on phone so code may be inaccurate

2 Likes

Also make sure to mark as solution in case someone else has this problem (if it helped)

If you want to go to the extreme you can use this

not sure if it works best for hackers but worth a shot

1 Like

Touch interests can be removed on client but will not affect server scripts when deleted. Exploiters can always modify client scripts anyways so if you are using a client script that is a bad idea.

Just add .Touched functions to all of the parts that don’t need touch functions. (There may be a better way to do this but I’m not sure how)

Just cause an exploiter deletes something on the client side doesn’t break the server. Sounds like you have poor practices.

1 Like

I really dont know if thats the problem. The script is server-sided, when you create a ontouch event a touch interest appears on the client side. Now i dont know if its only a Studio problem or not, but when you delete it using the explorer on the client side it still appears on the server side, but in the client side it completely removes the functionality of the glass falling lol. I will provide a video or something rq.

This idea that server sided makes everything secure couldn’t be any further from the truth. An entire game can be server sided and you can still exploit the living shit out of it. This is why it’s best from a monetary perspective to use poor practices that improve performance but make your game even more exploitable. Because ultimately it is in ROBLOX’s hands to fix the exploiting problem. Not in your hands.

It wouldn’t surprise me. There’s also desynchronization exploits I’ve discovered where you can literally de-sync your character from the server side just by using client sided exploits.

ima lock in and just make periodic checks on the server and then add an anti cheat im going to go with Gamemaster712Z solution which could work with this. Thanks 4 the feedback guys!

1 Like

Don’t waste your time. The only thing you can do is sanity checks from the server side. Anti cheat is useless. Exploiters always have the upper hand… but not if playing the game is more entertaining than auto farming it. The whole objective is that an exploiter shouldn’t have more exciting things they can do than the game itself. Adding anti cheat encourages exploiters further. There is no such thing as anti cheat. It is in Roblox’s hands to stop the problem and developers adding “anti cheat” isn’t actually anti cheat it’s just coding measures that aggravate the problem further

1 Like

Your right, that’s in Roblox hands, but ill just add a low level one so all the (copy and paste exploiters) dont go crazy on it, but thats until i fully release it for now its just a prototype and I shouldnt worry about that lol. Just gonna do sanity checks and periodic checks because .touched sometimes doesnt register. The best way i could handle the exploiters thing is just reward players for recording an exploiter and just banning them off the game(with roblox’s ip ban thingy) it should reduce exploiters. But thats for the future.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.