So someone sent me this on Discord today. Basically what they’re doing is teleporting these orbs that spawn in for my sledding mini game to their self and it gives you money Everytime you touch one. I thought there’s no way this client script is making this filter over to the server and actually give you the money, but it is. I have no clue how to go about fixing this, any help?
3 Likes
Is the touch script handled from the server or the client?
And FilteringEnabled is definitely on?
1 Like
Yes, it’s definitely on and the Touched script is server-side.
1 Like
Physics ownership? I may be wrong.
2 Likes
I thought that too, however when I give the server the physics ownership and you try to sled it makes it so that when you bump into one of the orbs it stops you dead in your tracks until the orb disappears instead of pushing it with the sled. Maybe I need to make the sled’s physics be controlled by the server too? This might cause a stutter in movement and a very bad experience though, right?
1 Like
How about anchoring the orbs and setting cancollide to false? Touched will still register and you don’t have to worry about physics ownership.
Or is there a specific reason why the orbs are unanchored?
2 Likes
anchoring them is really not an option if you actually see how it works. They slide down the ramp with you when they spawn in.
1 Like
As long as you want to use the physics engine, the issue of trusting players with physics ownership persists. I guess you could try to cframe lerp the orbs down the hill on the server and replicate the same behavior onto the client so both sides see it smooth.
In my opinion just have nodes at which orbs can spawn at and keep then there to be collected along the way.
4 Likes
I’ve had this issue in my game where players would teleport to spawned-in entities. I’ve found that a good solution is first to make sure there’s no obvious way to reference said objects. Let the instances keep their default names, so that models are called “Model” and parts are called “Part”. Also directly insert them into the workspace itself instead of any sort of subcategory. The idea is to make it impossible for an exploiter to recognize what is and isn’t one of your orbs unless they compare the Properties of each and every part individually.
Obviously this won’t be 100% effective, but after I did this in my game, I stopped receiving reports of players teleporting to spawned objects.
4 Likes
That method works as well, and I suggest actively changing the parts’ names (just on the client in it’s main script)
1 Like
Server-sided position check upon touch, if the client positions all orbs to themselves in an FE game they are not actually nearby on the server. (and thus magnitude can give it away) If the opposite occurs (player teleporting to orbs), add in a check for player position over-time and if a player moved too much teleport them back.
4 Likes
I don’t think you understand physics ownership. The server is the one checking, so there would not be a detected magnitude difference. Checking magnitude is bad in general since bad ping on a client can trigger a false alarm.
2 Likes
It has nothing to do with physics ownership what the distance of two parts is, that merely affects whether the client or the server calculates the physics for the part (and thus the delay between interacting with it for a particular client)
The client does the moving of the orbs to the player in the sketched scenario, in FE this means the orbs did not move on the server and thus a server-sided magnitude check will reveal that the player is not actually near an orb
This does not make much sense. You can always account for a slight delay using common sense, no one will check for a distance of exactly zero. However if the distance is 100+ within a single frame, you can safely assume things happened
3 Likes
I agree, you should try checking the position of the item on the client and having the server compare that position to the position of the item on the server, since if you’re using FE, they will not be moved serverside, and there will be a considerable difference in expected position.
1 Like
So basically .Touched will fire server-side, but the position will still be the old position? If that’s the case, I’m not sure why Roblox would allow that to happen. Haha. I’ll try to do that and see what happens.
1 Like
Keep a log of the parts velocity and position over the past 10 or so Stepped. You can use this to see if a part randomly decided to go across the map without any velocity in that dirrction.
2 Likes
The Touched event with a client-owned part is triggered by the client. The server listens for the client to trigger Touched.
Touched can trigger on the client from the part being moved on the client only, and it will fire for the server too. In other words, Touched can fire on the server when parts don’t actually touch. Clients can spoof the Touched event.
You need to check if the character is close enough to fire Touched on the server. The easiest way to do this is magnitude checks on Touched (on the server). If the client touches a money giver but is too far away to use it, then they obviously shouldn’t be given any money.
Here's an example of the client firing Touched
Place file: ClientTouched.rbxl (12.7 KB)
The two scripts in the game:
ServerScriptService.Script
workspace.Part.Touched:Connect(function(hit)
print("Touched:",hit)
end)
StarterPlayer.StarterCharacterScripts.LocalScript
while true do
wait(1)
workspace.Part.CFrame = script.Parent.HumanoidRootPart.CFrame
end
Once you fix this problem, you will also need to look out for players teleporting to money givers. You can fix this by comparing the character’s current and last position every step (on the server). If they move too far then they must have teleported, so temporarily don’t give them any money and respawn them.
4 Likes
You could always put the Sleds/Characters in one collision group, the orbs in another collision group, and the hill in the default collision group. Both the sleds and the orbs will be able to connect with the hill’s default collision group, but you could make the orbs and sleds/characters not able to connect with one another. I believe touched will still run if you set it up like this?
This means you will not need to run any physics against one another, and you don’t have to anchor them.
2 Likes
You could force control of the orbs to the server and set their collision group to a orbs group. Then you can set the collision group of the sled and player to it’s own group. Then set the two collision groups to not collide with each other. This should stop the orbs from slowing the sled down, while also making server distance check not be fooled by client teleporting orbs.
1 Like
You can save the position of the orb once it spawns in the Workspace, only if the orb isn’t scripted to move by itself then the following code is guaranteed to work.
-- In the Orb Spawning Script --
function SpawnOrb()
local NewOrbPosition
local Orb = game.ServerStorage:WaitForChild("Orb"):Clone() -- Clone the orb from where it's stored.
Orb.Parent = game.Workspace.Orbs -- "Orbs" is the folder that will hold the spawned orbs.
Orb.Position = Vector3.new(0, 10, 0) -- Just an example.
NewOrbPosition = Orb.Position
game:GetService("RunService").RenderStepped:Connect(function()
if Orb and Orb.Position ~= NewOrbPosition then
Orb.Position = NewOrbPosition
warn("Something or someone tried to move an Orb: ".. NewOrbPosition) -- This is optional, it's just to warn any game dev/admin on the server that something or someone suspiciously tried to move the Orb and it prints out the original position where the orb spawned in.
end
end)
end
1 Like