they do have a DisconnectAll: All instances have it. When you :Destroy() an instance, it disconnects all connections as well, and calls Destroy on all the instances below it.
Now, if you want to disconnect all the instances without destroying it, you can just cache the connections in an array and go from there
Network Ownership is still needed in ROBLOX for physics. If you set the network owner of your character to the server, it manifests a massive input delay and a bad experience.
Also, .Destroying does replicate
I didn’t even know about that function! Hopefully it helps with lag when unloading maps for low power devices in my game!
You cannot destroy a player since you have no permission of doing so, Destroy is really different from a DisconnectAll function; even though the functionality of disconnecting everything from an Instance is included when you call Destroy. The error you get when calling Destroy on a player is ‘The Parent property of Players.PlayerName is locked’. (@Khrrxs told me that you can destroy the player the next frame after PlayerRemoving triggers, which is a good thing to know)
This is why I literally said it will be useful to have DisconnectAll as a function…
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?
I’m going off this: Destroy() Can Now Replicate to Clients
Which is the followup (this post)
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.
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
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.
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
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.
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!
