*not kicking, I meant giving me some sort of detection input
For smaller ranges, it effectively mitigates the exploit, but for higher ranges, I also want to send out a notification to myself out of the game to keep an eye on them in the future (as it’s not meant to be a public playable game, but is a group-related competitive community)
Is it recommended to send out notifications if the player has a lesser/laggier performance?
I would recommend to implement a system to notify your self, only if the player has been registered multiple times (5 is a good amount). It is definitely not wise to notify your self as soon as one does not pass the GetPartsInParts check, in order to avoid false positives in a rare case with this check.
It would not necessarily be rare per-se. It’s highly possible for a player in America to be playing on an Asian server or something, and then have 300 ping.
Doing a precise geometric check on the server will not register any of this players hits if the opponent in question is actively moving. As the server’s idea of where the opponent is and where the player’s sword is will be way off depending on the ping.
Also keep in mind that this check really doesn’t prevent very much; while it is a good practice, exploiters are still able to just teleport themselves behind you and hit you that way. And even if you had an anti-teleport, they could simply tween themselves to you.
This is a really bad game of cat and mouse, but it’d be also best if you didn’t cripple genuine players that have bad replication lag in pursuit of trying to mitigate this.
Back at this;
This is such a great solution, but I came across the fact that it still gives false positives when the person swings the tool at someone while moving/rotating fast.
I just wish Roblox would do something about this; I’ve tried your idea and I even recoded the tool with Raycasts, but none of them did their thing.
I’m frustrated; I own a competitive-based group and came across the realization that some people are using this exploit to get ahead of others.
Yup - this check does indeed have problems. In the light of Gojinhan’s response, I’ve edited my original reply to point out most of the problems with my approach in detail.
@Khanovich Could you please forward this up to engineers again? I rarely get a response in the Engine Bugs category, so I tend to mention any staff members who noticed this issue.
It’s not about the fact that “developers should focus toward better solutions such as Region3, Raycasting and Magnitude”; this issue has made me recode my tools with all 3 solutions mentioned as they’re considered “the best”, yet are unsuccessful/underperforming due to the server’s responsiveness time.
I have tried EVERYTHING (not just me, plenty of other developers have tried EVERYTHING), yet it has proven to be unsuccessful. .Touched is the way to go and is the standard for all basic tools and their basic needs. It shouldn’t just be pushed to the side cause there are other alternatives - it should be prioritized.
I own a competitive community group which has recently had a spike in number of cheaters who are using this form of exploit which technically can’t be detected cause any alternatives/solutions are not 100% precise and can result in with fake detections.
Please, give this thread more attention. It is critical and requires a fix.
This is a solved problem in multiplayer networking: predict actions on the client but validate them on the server. It looks like you only implemented the validation part and haven’t yet done the prediction part.
An example is this:
You can apply the idea above to any other networked game concept such as firing projectiles, damage/hit/kill indicators, etc.
You are fundamentally never going to solve this problem with just using Touched because physics ownership is distributed. It’s fine to ask for a fix, but that won’t solve issues related to validation because you’re still using physics. You will always need to protect against issues like this with server-side validation.
The thing is, I even tried using Raycasts, Region3 and Magnitude, but none of them seem to work except Raycasts (which are delayed and sometimes don’t detect hits on touch).
Is this patched or is it still exploitable?
Unfortunately, yes, Touched events are still client-controlled even if the BasePart is completely anchored. I’ve just completely abandoned using Touched events in favor of custom implementations and accepted the overhead of polling the SpatialQuery API because it’s clear this behavior isn’t going to change anytime soon.
Any update in regards to when a patch for this behaviour will be delivered?