Revisiting this tutorial after a long time for an important notice with regards to the bottom: specifically, where I note that you can also use other constraints for moving models and that a potential tutorial may be written up on that later (assuming I had the time to do so).
In short: it’s not happening.
I currently follow this tutorial myself for two of my group’s games and respectively each of them have had a glaring problem with regards to exploits based on network ownership. As a little recap, network ownership refers to the entity (the server or a client) responsible for handling the physics simulation of an unanchored assembly. My game uses constraints to move models, and it does not end well.
Please observe the following example, reported by one of said developers:
What’s going on here is: since we are using constraints, that means that we have to fully unanchor the doors and network ownership will get passed around to the nearest client meaning they’re in charge of physics simulation. With that in mind, an exploiter holding ownership can do something like this.
The obvious solution here would be to give ownership to the server and that would completely stop this exploit but at a very resource intensive cost, since clients can better simulate physics than the server can (or so that’s what I know). Other options include flagging suspicious movements on the server’s end, logging the network owner via GetNetworkOwner, kicking them and then rubberbanding the door or just making the doors client-side only. Anything where an exploiter can’t influence how doors look to others without the server’s intervention at some step of the way.
As such, due to the above concerns, I feel it’s not appropriate to write a constraints tutorial that doesn’t address exploitation and I don’t have the time to do that. Apologies. At least you’ll have this information on hand though and possibly be prepared to take measures, regardless of what you choose.
I’ll be removing the “Constraints in General” section as of this post and include a reworded version that includes an exploit advisory warning with a link to this post at a later point in time.
Cheers. Stay safe all, happy developing and good luck fighting against silly exploiters. 