Basically a function that will allow certain changes from the client for specific objects to be allowed. For example, say I have a plane controlled by BodyVelocity, I use game.Workspace:AllowChanges(plane.Part.BodyVelocity, game.Players.Semaphorism)
It will basically allow all changes from a specific player on specific objects, so we can keep things client side without having to make ridiculous systems when using FilteringEnabled
Workspace:AllowChanges(Object object, Player player)
For this particular scenario, Body mover objects rely on physics, thus client manipulation to them actually effects the object for everyone. I use body movers in Angels Fifteen with FE on, and client changes to those objects make the planes fly around for everyone.
Also, simply allowing an object to bypass the filtering would be quite a pain. Just use Remote objects to request for changes. They are not ridiculous to use, and in fact help develop good skills as a programmer when it comes to communicating properly between server and clients. For instance, if you’re building a website, your client JavaScript code would never be able to touch server-side files. Instead, it has to make a remote call to the server to request to do things, much like using Remote roblox objects.
The recommended method is to control the BodyVelocity through a signal where the player tells a server script what it wants to happen. Otherwise the client has full access to the object and can do things you don’t want them to do, like change the maxForce or do other things that the client-sided script never tells it to do.
Clients can manipulate body mover objects just fine. If you’re building vehicles and using those objects, let the client make the changes. It works! If it didn’t work, my planes would be falling out of the sky a long time ago.
[quote] Aight, thanks for the feedback, but even then that was just an example.
Isn’t there an issue where clients can manipulate any humanoid? Or was that fixed? That might also apply to body forces. [/quote]
I think that was fixed? I forget which thread that was. But the body force thing isn’t a glitch. The reason it works is due to physics replication, which is different than just setting the position of an object (which is a direct property manipulation). Instead, the physics are manipulating the object, which is trusted. And so the properties changed on body objects do not replicate to the server or other players, but the effects those objects have on the object’s physics do replicate. I’m really happy this is the case!
I would much rather have a callback than what you are suggesting. The callback would include the player instance, the instance they are changing, the property being changed and the new value as parameters. You would then return true or false if you wished to change it.
This was what ‘filtering’ was going to be a long time ago. It was deemed too slow, and so a global yes/no check was implemented and released as a replacement.
Given the game can farm out physics calculations to clients anyway (see: Network Ownership API, and it seems likely OP would want whatever the Mover’s attached to be owned by the client that can change the Mover), a client could just lie about where something moved to anyway.
Actually, that makes me think that even without this, using Network Ownership you may be able to achieve the same results:
[ol]
[li]Server sets network owner to client[/li]
[li]Client creates a BodyMover locally[/li]
[li]Client simulates physics for the assembly, taking note of the BodyMover. Server doesn’t see the BodyMover, but it doesn’t need to.[/li]
[/ol]
Clients can manipulate body mover objects just fine. If you’re building vehicles and using those objects, let the client make the changes. It works! If it didn’t work, my planes would be falling out of the sky a long time ago.[/quote]
I disagree with this suggestion. If you want something replicated, use a RemoteFunction or RemoteEvent. If you really don’t understand how to use remote instances, then instead of asking for ways to get around FilteringEnabled, you should be asking for help with how to make your games use remotes properly.
Thats not the point of this function though, this is so we can set objects owned by certain players, basically allow them control over those objects. BodyVelocity was an example, so say for my space game, I can set properties of the forces by the client. This will reduce lag for the client controlling it, since it will be client side. I have a Remote system setup for controls, and it sucks. The latency is bad sometimes, and makes game-play annoying. However its not just body movers that I would want to allow the client to control.
That is what the Network Ownership control is for. Set the owner of the assembly to the client that you want, and those physics shall replicate to the server, and thus to other players.
I know that, however this would allow the client to actually modify the object itself.[/quote]
It can. Just instance the body object on the client, and edit it from the client. Since the client owns the physics for that assembly, it will use the body object and replicate any position changes back to the server.
