I’m not well versed within the area but I can give a decent theory/explanation
check the players position every 2 seconds, (char.HumanoidRootPart.Position - part.Position).Magnitude
if its close than kick them, also if this is for exploiters it can easily be bypassed.
My suggestion is to just not put to much thought into this, think of the big games like “jailbreak” exploiters can still enter the jewerly store once its closed, same with the bank, and various other area’s, so yeah.
If they were able to delete the part would the script this work? I want to rely on positions rather than physical objects to determine as if they are somehow able to remove them it’d still work
i suggest using the thing you are using but checking if the character is alive while humanoidrootpart doesnt exist which means that they are exploiting and abusing to bypass the script though that could be fixxed too
simple script :
Note that this should be a script and not local
game.Players.PlayerAdded:Connect(function(Player)
Player.CharacterAdded:Connect(function(Character)
print("Started checks") -- Use in case script errors
Character.ChildRemoved:Connect(function(Child)
if Child.Name == "HumanoidRootPart" then
wait(0.05) -- Delay if player fell in void so it doesnt detect falsely
if Character.Humanoid.Health ~= 0 then
Player:Kick("YourKickMessageForDecetion")
end
end
end)
end)
end)
They won’t be able to delete it if it is anchored.
Regardless of that they can still delete it with a simple
local map = game.workspace
local part = map.PartHere
part:Destroy()
ZonePlus checks the position of the HumanoidRootPart which seems the most intuitive since you can’t just query Character.WorldPivot; The Character is a physics body, and the engine doesn’t change the property for performance. However due to vanilla replication, exploiters are able to delete their HumanoidRootPart to bypass the server checks.
The best way to stop this would be to just kick the player if their HumanoidRootPart gets destroyed.
local Players: Players = game:GetService("Players")
Players.PlayerAdded:Connect(function(Player: Player)
Player.CharacterAdded:Connect(function(Character: Model)
local DescendantRemoving: RBXScriptConnection = Character.DescendantRemoving:Connect(function(Descendant: Instance)
if Descendant:IsA("BasePart") and Descendant.Name == "HumanoidRootPart" then
Player:Kick()
end
end)
Player.CharacterRemoving:Once(function()
DescendantRemoving:Disconnect()
end)
end)
end)
Players.PlayerRemoving:Connect(function(Player: Player) -- Makes sure Player.CharacterAdded get's Disconnected
task.defer(game.Destroy, Player)
end)
Then again, this behavior shouldn’t be expected.
That is completely false. If they do not have network ownership of an object, they cannot change it, which is exactly why they can’t manipulate values in ReplicatedStorage, as it’s Server → Client only.
Client view, after deleting Baseplate:
Server view (with Studio Server View feature):
I highly suggest you edit your reply, it’s complete misinformation that contradicts the literal reason FilteringEnabled exists, to limit what the client can manipulate, to stop stuff like this from happening.
And, the code you sent uses a deprecated API
I want you try the same thing but with a part that kicks the player.
Delete the said part with the script on client-side and see if the player can go through it or not.
Also they can still edit the proprieties of parts. (Such as cancollide)
for i,v in pairs(workspace:GetDescendants()) do
if v:IsA("Part") then
v.CanCollide = false
end
end
The player will always be able to fake their position, entire character, humanoid, and etc. If you want to be server authorative for the players themselves, you’re going to be sacrificing latency no matter what, but the most secure option is server authorative player characters, or something similarly cloud-powered
Perhaps check a region3 on the client and server as exploiters cant delete a region3 I think but if they can then dont do this im sorry
https://create.roblox.com/docs/scripting/networking/network-ownership
Please test whatever you say first!
for i,v in pairs(workspace:GetChildren()) do
if v:IsA("BasePart") and v.Anchored then
v.Color = Color3.new(1, 1, 1)
end
end
That’s only true if you are kicking the player via a localscript, which, according to OP, isn’t what they are doing.
Instead of using workspace:GetPartsInPart, I’m having the server check every second to determine if the character’s Z position is greater than 10 (giving a bit of of a cushion) as anything greater than 8 means the player is in on the board. The map is a big box so I don’t need to worry about X or Y. So far there haven’t been any reports of players being on the board and if it does reoccur then preventing them from colliding with the objects works well. Thank you all for your input and feedback!
verify if the user can interact with the objects in server.
Use raycast or fast cast instead, much faster than region3, touched and zone plus
I am seeing too much false data in this thread, if the player doesn’t have network ownership over an instance they won’t be able to replicate changes to the server, meaning that if they get to delete the “exploit detect” part, it would still exist in the server
I know that but it still doesn’t ignore the fact that player can use that script to bypass something (like barriesr).
Take for example, there is a door locked, normal players can’t access it, they need a key of course! however an exploiter can easily use the script i posted to bypass the lock and easily go through the door. players can see the exploiter go through the door, but they can’t go through it themselves.
I am very much aware that anything a exploiter creates on their client is not replicated unless noted otherwise.
I just did a short explanation of how that can be easily abused.
I understood what you meant, I thought you were talking about replication, because I misread.
For that case just raycast from the exploiter and check if he’s inside s room he shouldn’t be yet
Yea me and @Judgy_Oreo both misunderstood, we thought you were talking about cancollide client replication haha
When a script is running in server context, it does not replicate its bytecode to clients, but it is recommended to use serverscriptservice over workspace so clients dont have an idea of how your game works server-side by looking at the name of the scripts
ModuleScripts are different, if they get replicated to the client it will provide the code to the client because it may be required from the client
i have posted a script that kicks players if they remove it
so whatever they do if they try to bypass it they get instantly kicked
(in this topic)
Humanoid removed check post