Upcoming Changes to Destroy()

Updates Announcements
,
#45

You can check if the parent is nil

#46

THANK YOU!
if all goes to plan… the lag problem may be solved

#47

Player’s also do not get properly destroyed on leave which is extremely bizarre and basically means every game using .PlayerAdded is leaking memory.

That can’t be true right? Keeping players in memory after they leave would cause memory leaks whether the game uses PlayerAdded or not. I rely on garbage collection to automatically remove player data stored in a hashmap where the key is the player instance. I’ve never had issues with this, indicating the player is removed (at least at a high level I guess).

If having events bound to player instances causes issues with removing them I might have to start disconnecting all player events when they leave, which should already be handled by the engine. I’ll investigate it tomorrow and let you know what I find.

1 Like
#48

Sadly yeah, neither the Player nor its character gets destroyed.

When a player dies and you have connections made into any of the descendants of the character is better to disconnect all of it once it parents to nil or just destroy it manually (have in mind that you gotta check if the Humanoid is dead first as the character is parented to nil when CharacterAdded triggers). The same applies to the Player instance, they don’t get destroyed and you have no permission to destroy it either.

I would appreciate it if Roblox had a function like DisconnectAll for a player at least, cuz else you will have to save all connections made into a table and iterate through it when they leave.

#49

You gotta read all first:

When you create a new instance, it will be parented to nil and this doesn’t mean is destroyed for example.

1 Like
#51

if instance then ¯_(ツ)_/¯

1 Like
#52

Well I guess you could use attributes, but I get your point and it actually makes sense lol

#53

I have not been having issues and I have it set to Default, but curious to know what this change would break.

#54

This shouldn’t break anything; it just calls Destroy on an Instance on the client when it’s Destroyed on the server. Previously, it would just set its parent to nil

2 Likes
#55

This post screams “inexperienced scripter”

If anything, knowing about the ins and outs of the engine would make somebody a MORE experienced scripter

3 Likes
#56

Can you explain this setting more?

1 Like
#57

When you call Destroy on an Instance on the server, it will also call Destroy on the Instance on client now instead of just setting its Parent to nil. The setting was just around for anyone who relied on the old behavior of Destroy not replicating

#59

Why does it now replicate? It worked normally before

#60

It works the exact same as before, except it properly locks the parent to nil instead of just setting it nil.

If anything, the update adds more consistency, since if you destroy something on the server, you’d expect for it to be destroyed on the client as well

2 Likes
#61

Well, I would rely on it in certain circumstances, but not really.

#62

Network Ownership. Clients must have network ownership over their character, including the instances inside their character. Now, I see your point with non-physics instances such as values. Still, ROBLOX has already made better alternatives for each of those things: The attributes I talked about earlier, and tables created on the server for folders/configs.

Using Folders/Configs to store player data is, IMO, a bad practice because it adds unnecessary instances and and possible event connections when you could use the better alternatives stated above.

#63

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

#64

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

#65

I didn’t even know about that function! Hopefully it helps with lag when unloading maps for low power devices in my game!

#66

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…

1 Like