I unfortunately can’t say because I don’t really know the full impact of disabling box-to-player collisions in your game. If it works and doesn’t ruin anything for normal players, then it’s probably a good idea… It could also stop you from having to worry about this issue in the future, for example if players find a way to glitch onto the board without using exploits.
1 Like
I believe this will be a nice temporary fix to prevent the user experience from being ruined however another idea I had was determining if the player’s position was anywhere in the restricted area’s position. How could I grab all the vectors in an area to determine if the player’s position is in there? Sorry if its confusing I’m trying my best to word it.
I believe you can use workspace:GetPartsInPart to do the heavy-lifting for you;
-- every frame, check collisions
RunService.Heartbeat:Connect(function()
local Parts = workspace:GetPartsInPart(KickZone, nil)
-- go through all parts in region
for _, Part in Parts do
-- does the part belong to someone's character? kick them if so
local Exploiter = Players:GetPlayerFromCharacter(Part.Parent)
if Exploiter then
Exploiter:Kick("Out of bounds")
end
end
end)
2 Likes
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.
1 Like
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.
1 Like
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
1 Like
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)
Here's how they do it.
for i,v in pairs(workspace:GetDescendants()) do
if v:IsA("Part") then
v.CanCollide = false
end
end
1 Like
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
1 Like
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
1 Like
https://create.roblox.com/docs/scripting/networking/network-ownership
Please test whatever you say first!
- Run the following script in the command bar in Client View in a Studio playtest:
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
- Switch between the Server and Client views, and notice that in the Client view, a bunch of parts have turned completely white, while nothing has changed in the server view.
That’s only true if you are kicking the player via a localscript, which, according to OP, isn’t what they are doing.
1 Like
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.
1 Like
I just did a short explanation of how that can be easily abused.
1 Like
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
1 Like