Hello, I have a game where I use an invisible hitbox welded to your character’s HumanoidRootPart to detect whenever you touch certain objects. It works perfectly fine, but I realized that player will be able to exploit and tp those objects onto their character and the hitbox will still fire the touched event on the server even if the object are nowhere near the character on the server because the network owner is set to the player. To fix this, I set the network owner to nil so only the server could handle the hit detections, but this caused my entire character to be controlled by the server which causes a ton of input lag which makes the game unplayable. Is there any way to bypass this? I want the hitbox to have no network owner while my character to remain normal.
While not having experienced/tried it myself, I believe that using a Motor6D to weld the hitbox to the root part could potentially work? Not definite, but very much something worthy to try if you want to continue using your hitbox.
It should work the same as any other non-constraint weld, with setting Part0/1 and C0/1.
Did you put the hitbox and weld inside the player model? If you did, I think that gives their client network ownership over it, allowing them to change it’s position and other stuff like that. If you did, I’d try putting the hitbox in the workspace, and set the hitbox as the weld’s parent, then connect a touched event for the hitbox if you haven’t already. Even though this might make it tricky to deal damage to the humanoid when the hitbox is hit, I’m PRETTY sure it will stop exploiters from moving the hitbox.
I parented the weld to the hitbox and then parented the hitbox outside of the character but nothing changed
I tried using a Motor6D instead of a Weld and nothing really changed either, do you think a WeldConstraint would behave differently? I’ve never used it before
Don’t change network ownership, just make the hitbox be created and welded by the server. The exploiter can delete it and make client changes but not server changes.
You shouldn’t rely on the client, just add a magnitude check when they are hit which will stop exploiters and laggy children.
It is created by the server and welded by the server, but if I dont set the network owner to nil then the closest player to the hitbox will become the network owner. However, when I set the network owner to nil (which is the server), the entire character also gets set to the server when it should stay controlled by the player. Im gonna try a magnitude check instead tho
Not if the hitbox is parented to the character. The character has network ownership over their parts.
Why don’t you try just making the humanoid root part larger and set CanCollide to false? They wouldn’t be able to mess with it because if you try and exploit your root part’s position, you either teleport to it or nothing happens.
All JointInstances behave the same, changing which one you use doesn’t resolve this problem. Clients are authoritative of their character physics so you need to design with that in mind. Any physics controlled by the server that’s linked to a character will cause input delays.
This is bad advice. Please do research before replying so as not to provide misinformation or anti-patterns towards a given scenario.
The HumanoidRootPart requires collisions for internal downcasting, which is what makes the player able to walk on surfaces in the first place. The engine (hacks) the HumanoidRootPart’s collisions to remain enabled every frame as well and pseudo-disabling them via CollisionGroups will send the character through the floor.
A larger HumanoidRootPart has nothing to do with positions. Exploiters would still be able to manipulate the placement of their characters or at least the physics involved to move towards a given position in the level. This would change nothing.
If your goal is exploiting countermeasures, then this, like every other case of “I need an anti-exploit”, is extremely dependent on how the game works.
My proposed solution? Detect displacement, or, how far they travel over a certain period of time. You can even do this test on the client if you absolutely need to. The point of this test would be to detect if the player has moved an excessive distance further than what would be allowed under the normal circumstances of the game. Of course, you would have to factor in edge cases e.g. freefalling, but something of this nature would be your best bet. Binding this to something like RenderStepped on the client would allow you to accommodate for lag, but you should have some threshold value tied to this as well and not be oversensitive.
One other case I see is teleportation through thin walls. If this is indeed going to be a problem for you, I recommend creating a secondary, smaller part representing the wall and doing a raycast from the player’s last recorded position to their new position. It is extremely important that this part is smaller, since if they were hugging a corner and walked around that corner, the ray would almost always clip with the wall.
Unfortunately there is no “proper way” to mitigate this issue; as mentioned, it vastly differs depending on the game and its mechanics. I hope the methods I suggested can help, but otherwise, I’m afraid the rest is in your hands.
If you need help making a script like that work, you can always continue to post on this thread with what you’ve tried and what you need help with. Most people should be able to lend a hand with that information.
But method this has a delay since it’s server sided, so they will still be able to move the hitbox. It will just be for like a millisecond, but that still leaves plenty of time for the exploiters to abuse it. They aren’t called exploiters for nothing. 