Insight into resolution of physics collision client vs server

I have a door which opens for a player when activated.

Currently I use a simple client side script (run context client) and trigger (Touched). I plan to move the detection to server side to offer more control and security, but at the moment it is all client side only.

The door is a model containing two parts, an anchored PrimaryPart with a weld constraint to an unanchored secondary part. The model is moved with a tween to the PrimaryPart CFrame, by the client side script.

However, when I run a local test, I see that the door opens client side and allows the player through and the door remains closed on the server, where I see the player walk through the door.

I expected to see the door open client side, but for the player to run into an invisible wall - the still closed server side door.

This implies to me that the collision detection is happening client side, but that would surely allow all sorts of undesirable vulnerabilities? Can someone explain to me what I am seeing and if it is what I think (client side collision) why this is not a problematic vulnerability?

Edit: Further thoughts / finds
As the PrimaryPart of the mechanism is anchored, the whole mechanism physics is owned by the server. I get told that the part is anchored if I try to SetNetworkOwner(nil).

So I just tried a simple experiment on an anchored block using a client side script to set CanCollide = false and then I could walk through the block. In fact you can do this by just toggling the part collision in the client window. So there is no validation of player movement on the server?

1 Like

The server replicates to client, but the client does not replicate to server. So the touched event is only connected on the client, so the Tween will only run for the client.
Switch the script to serverside and the touched event will run the Tween serverside, and therefore replicate to all clients.
Both sides can also detect the physics collisions separately, setting the parts CanTouch or CanCollide properties to false will disable these. If on the client this is just for that client, on server it is the default behaviour of the part for all.

To keep the physics running smoothly, network Ownership of unanchored parts gets set to the closest player (more complicated than this in reality), this includes the player. So the server believes the client when it comes to positions orientations velocity etc.

So you see the player walk through an unopened door on server because they were allowed to do so on the client.

Yes, this does cause vulnerabilities, many posts on the DevForum are dedicated to anti-exploit techniques, but generally require you to check what the client has sent, so that it meets the requirements of your game.

I see, I had assumed player movement was validated server side. Thanks.

Unfortunately I think that is impossible as a player needs to provide input to move them.
It has some benefits in creating player specific interactions, but can be a pain to detect due to accounting for lag (eg teleporting players).

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.