I think you misinterpreted the post, this isn’t a new feature, this is the removal of previous behavior. It won’t give us more options (it’s for the better though).
Or I misinterpreted yours?
1 Like
I’m going off this: Destroy() Can Now Replicate to Clients
Which is the followup (this post)
2 Likes
I don’t see how that is of any importance. You can just cache the values. Your only argument is for the sake of convenience, which ROBLOX usually passes by
For you, it probably doesn’t have any importance, but for others it does.
They literally added no long ago table.clone, something that you can code in a matter of just 1 minute. However, they decided to add it because of how widely is used and so they can do to the feature I requested IsDestroyed and probably DisconnectAll too.
So it means no more memory leak when using Destroy() on server?
You actually can destroy a player, you just can’t do it during PlayerRemoving.
game.Players.PlayerRemoving:Connect(function(Player)
task.defer(game.Destroy, Player)
end)
This will destroy the player on the next frame and will open it up to proper garbage collection.
3 Likes
It’s not an issue, clients have network ownership over their own characters, which is performance-wise
You can change this behavior by adding your own character server-sided system
Or just don’t use startercharacterscripts at all, lmao, not reliable
1 Like
People be confusing what network ownership even is, read the highlighted parts of this article found in the Roblox API Reference:
They are just talking about Unanchored Parts or Parts Affected By Physics in general. They do not mention at all any other Instance like BindableEvents, Scripts, Humanoid, ValueBases, among others.
This means that this is indeed an issue as the player should ONLY have control over their parts only and not everything under the character. Have in mind that the issue here is that they can Destroy instances under their character no matter what they are.
Not only are you using a deprecated site, but network ownership is also responsible for the owner of the instance replication (that’s literally the reason why it’s called being the owner of a network)
Please document yourself
The new API Reference says something similar to the old one:
It literally clarifies the same exact thing, Network Ownership applies only to BaseParts that are affected by physics.
If you give a player ownership of other blocks in the game (something that literally happens automatically when they get near an unanchored part), they are not able to destroy any of its descendants as you can do with the Player’s character from the client. The player should not even have the power of deleting a Server Script or any other Instance under it.
Did you know you weren’t able to delete Accessories, Shirts, and Pants which are under the character? We can assume that the issue of replicating the destruction of Instances under the character was used back then and made Roblox keep this issue as a feature. They had to prevent accessories from being destroyed else an exploiter could just delete its clothing and end up nude in the game. Did they forget that a Server Script should be locked too as well as many other Instances?
This means that the issue with deleting instances under the character doesn’t have anything related to Network Ownership.
You can even check this reply which kinda explains it differently: Upcoming Changes to Destroy() - #39 by Hexcede
EDIT: @UltraYummyChocolate I won’t be replying anymore, you are free to think whatever you want. This is not an issue I face nowadays since a long time ago I decided to not use the Character as a container for important things.
This issue was brought up by @Serrattor. I experienced this issue back then and I had to change many things around because of it. If you haven’t suffered from this issue, then remain silent, instead of just saying it’s fine.
All models in Roblox behave the same exact way, there is no reason for the Character model to be an unsafe container where the client can literally delete whatever it pleases too.
A Humanoid is designated for each player that joins which is ok to replicate, but you should not be allowed to destroy things like ValueBases, BindableEvents, ModuleScript, Script, BindableFunction, among many others.
Script Deletion should not be intentional as the server is the one that parents those scripts under the player’s character.
1 Like
You still don’t understand, the website is talking about how roblox physics engine work in the first line
Network ownership covers some things, not all, for example, you cannot replicate attributes inside the character because they are not a part of network ownership
It’s as simple to understand as reading the name and explaining to yourself what it means
Network Ownership → Owner of a network, meaning they own replication of such because they send the data of it! (whether it’s bad or not)!
Plus, being able to change descendants of a character is supposed to be, otherwise humanoid data wouldn’t be replicated
1 Like
You can see here that it’s intentional, a model cannot be set to have network ownership but rather its children/descendants
I am also supposing script deletion is intentional, so you can remove “Health” and other Core scripts to make your own
I have almost sure that exploiters cant see Server Scripts using Dex Explorer and they cant acess its location or instance. And yes client being able to destroy character things and replicating is a big security flaw, a workaround to this is creating everything inside Player instance instead.
1 Like
Exploiters cannot see server scripts, because their code is not given to clients (although the instance itself yes)
Being able to delete a script in your character is most likely supposed to happen, because there are roblox scripts which can be overwritten by your scripts
This behaviour has been going on for ages and, you should already not be relying on the player’s character, almost never
thanks, now I won’t have to make events for that!
Try this
if not Object:FindFirstChild("Object") then
print("Is destroyed!")
end
less laggy gameplay, pretty neat thanks dude
Hi Developers!
If all of your experiences have Workspace.ReplicateInstanceDestroySetting set to Enabled or Default, you may ignore this update.
As a reminder, we are currently planning to remove the property Workspace.ReplicateInstanceDestroySetting and enable this feature for every experience on September 15, 2022.
If your experience has Workspace.ReplicateInstanceDestroySetting set to Disabled, please take the time to set Workspace.ReplicateInstanceDestroySetting to Enabled.
If you are unable to complete this by September 15, please send me a DM and we can work with you individually.
Thank you.
2 Likes
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.