Let’s say you have FilteringEnabled turned on, and you want a client to be able to replicate changes to a certain instance which we’ll call Thingy in code. With this, you can do:
local Bob = game.Players.Bob
Thingy.Owners = {Bob}
--It's Bob's lucky day!
As it’s a table, you can allow multiple players or just put game.Players in it to allow everyone.
Now, let’s say you wanna only allow certain properties to be changed.
Well, you can do this!
Thingy.Owners = {Bob = {false, "Name"}}
The false in Bob’s table is whether or not all properties are allowed or disallowed by default. As it is false, all properties aren’t allowed unless their name is put in the rest of the table. If it was true then all properties would be allowed, except the properties specified in the rest of the table.
Bob’s client can now only replicate changes to the Name.
If the client makes the part massive and unanchors it squishing the entire map, just disallow those properties. Still need them? Connect a Changed event to limit the part size serverside. As long as you do it right, nothing will go wrong.
Which is why you use it correctly by only allowing the properties the client should be changing and restricting what the property’s value can be set to, as I said above. This feature does not make the game more exploitable if it’s used correctly.
Let’s say you have a building game, and you want to be able to edit parts in your build. Simply tell the server you’re about to start editing a part, and if the player is allowed then the server does something like this:
--PartOwner is the owner of the part, a player.
EditedPart.Owners = {PartOwner = {false, "Size", "CFrame"}}
Then just add a Changed event on the client and server to restrict the size and CFrame.
(For example, keeping the part in their building area.)
This is unexploitable, and you don’t have to do any weird RemoteEvent stuff to replicate changes to the part.
I guess you can already do alot of this with SetNetworkOwner which is good and bad; if there was some sort of mask to block certain changes via Network Ownership that could be useful.
How do you mean it’s unexploitable? I can just write a script that changes all the parts’ sizes to 2048x2048x2048 and break the game. Sure you can listen to it and sanitize it, but at that point you’re doing exploit prevention and you’re writing code that should have just been written in the first place as part of a remote event.
All this feature does is make it easier to implement “SetProperty” remote events, which you should never have in the first place.
That isn’t exploit prevention at all, that’s a sanity check and loads of non-ROBLOX games do that. Nothing is wrong with sanity checks.
Using Instance.Owners provides an easier alternative to writing code to replicate properties - you can tell the filter exactly what to allow and it doesn’t bloat network usage.
Like I said, an easier way to write code that you shouldn’t be writing in the first place. “SetProperty” remotes are always bad. You should never give the client such low-level access to changing the server’s data.
I like the idea personally, there are a lot of things that would be made a lot easier if we had this. Mostly situations that involve dealing with client-server lag come to mind.
Of course, I also get where everyone else is coming from, and kinda agree with it. I personally struggle grasping why things need to be done the proper way when I haven’t experienced the reason why first hand, but learning from my past mistakes as sharksie said, it’s probably not the greatest idea to encourage bad developing habits.
And I can easily see this being used in a way that is sub-optimal 99% of the time, unfortunately. There are just too many ways letting the client send replicated data could become exploitable, and having to use .changed and the like to fix it just seems like it is defeating the purpose of this being an easier way to deal with replicating clientside changes.
That being said, if this got implemented I would most definitely use it c: