While optimizing parts of my code for an upcoming project, I noticed that a connection was leaking memory on the client. In the code, there is a section that sets up an event handler for when the character’s root part touches another special part named “Zone” to trigger the loading of another interface. However, if a character resets, the event handler needs to be updated for the new character. Now, setting all this up is fine, but I am just wondering about one thing.
From what I understand, connections associated with an instance and its descendants are implicitly disconnected when the method Destroy is called on that instance. Yet, when testing to see if the connection associated with the event handler mentioned above would be disconnected once the character was reset, I noticed that the connection still persists even after the character has been destroyed on the server, so I suspected the issue might have something to do with how the client deals with this change. Out of curiosity, I decided to try something. In a new place, I ran Play Solo and switched into Server Mode. I executed the following code in the command bar:
This successfully destroyed the character on the server, and on the client the character was not visible anymore. The code also threw an error after 10 seconds as expected, but on Client Mode I was able to run the third line after the character had been destroyed. It seems to be the case that the character is removed rather than destroyed, so I was just curious as to why this is.
Seems like the player’s character isn’t in fact destroyed when you respawn, but rather only parented to nil. Your code however should error on the 3rd line on both sever and client, as you Destroy() the character manually, thus its parent should be locked, so I’m unsure why it doesn’t error on the client for you but does on the server.
As for the memory leak, I haven’t had this problem before when connecting events to a character’s parts, but you could always disconnect the event from the removed character’s parts on respawn. You can also try to avoid creating a new anonymous function each time you connect to an event.
That might be the case for respawning, I have not really looked into it. As for manually calling Destroy, I am also unsure as to why it only errors on the server when the server destroys the character. The issue also occurs with Test Server.
When I do the reverse (call Destroy on the client), the client errors as expected, and the server does not which from my understanding is normal since FilteringEnabled prevents certain changes from the client from replicating to the server.
I checked to see if destroying other parts on the server would have the same effect, and it did. When the server destroyed the part, it was only removed on the client. Calling Destroy directly from the client seems to display the desired behavior on the client (the instance is locked, connections are disconnected). Do you know why the client removes instances when the server is the one calling Destroy? I must be missing something.
I’d say it’s not replicating that it’s been destroyed to the client. I don’t know if that’s an intended feature or not.
If it is intentional and you need the character destroyed on both ends, you could setup a RemoteEvent to at least tell the client that the server destroyed something, and you should be able to call Destroy on that item since it was only removed.
Thank you all for your input. Would anyone happen to know if this is intentional? (Referring to how the client does not replicate Destroy but only calls Remove when the server initiates the Destroy.) And if so, why?