I’ve noticed that depending on some devices or under a rare scenario, scripts under actors do not start up properly or disconnect properly resulting in massive memory leaks or the script not starting at all.
My entire error analytics is filled with these messages due to this issue yet the scripts are enabled when they are under the actor.
This makes it really difficult for me to see the errors in my game as i have to look through a massive list of useless warnings which are not even valid.
This also causes a big memory leak as the scripts will remain running for some reason when destroyed.
I have tried destroying the script, its parent and even that parent both on the client and the server but anything i do does not seem to prevent this from happening.
This is preventing my game from functioning correctly as i’ve converted everything to use actors recently.
A lot of users are unable to play my game due to the entire game breaking when it fails to correctly start up the actors or disconnect it.
I hope this can get resolved as soon as possible as a lot of users are currently locked out of playing my game and have been for the past few months.
I just tried launching your game locally and I can see the same error being reported in the developer console. So the good news is that it looks like it is easy for us to repro the same issue.
Either myself or someone on my team will investigate what is happening. Thanks for reporting this issue to us.
Yesterday when I ran your experience I was able to easily repro the issue on two different PC’s. However, today when I went back and tried to repro the error again I haven’t been able to see the issue after running the experience 20+ times.
I was just wondering if any changes were recently made to your experience that might explain why I can’t repro the issue now. Also, do you still see errors being generated on the Creator dashboard?
Since I can’t currently repro the issue (even though I could easily yesterday) I would appreciate any suggestions you might have to repro the issue.
I can only seem to find the motor blocks having this issue when i look at the past 1 hour.
I did notice the same with watertanks somewhere further where it randomly spikes up.
I did seem to find a way to replicate the script not disconnecting properly though.
When you spawn the cutter block from the section: mechanical – PVP,
it destroys the script when PVP is disabled in either studio or a public server.
When it destroys the script it does not disconnect the script properly and it continues to run after the script has been destroyed.
It seems the same error popped up again but for some different blocks now.
It really seems to be somewhat random but the bumper script continueing after being destroyed is 100% replicateable every single time though.
I managed to get a repro place for the script still running after its destroyed issue.
I dont have any repro steps for the issue where it breaks yet, it still seems to be random but if this were to be solved it would clear out a lot of logs that are not related to the issue and allow me to try and get a repro place for that.
Thanks @rickje139, this repro will make it easier to investigate this issue. I suspect there could be multiple problems here (although they may all be related in some way). I’ll take a look at this specific repro first.
I have some changes (to be released in an upcoming Roblox release) that should add more detail to our error messages for ConnectParallel. The current error message is confusing in some situations because it may indicate a script is not a descendent of an actor. However, in reality the script may have been a descendent of an actor at some point in time, but may no longer be a descendent because it was reparented, or it was destroyed prior the call to ConnectParallel.
For example the new error message could indicate that even though the script is not a descendent of an actor, the Luau thread is associated with an actor (which could indicate the script moved or was destroyed previously).
I realize this doesn’t directly resolve the issue you are reporting, but I hope it makes diagnosis a bit easier in the future for creators as well as for Roblox staff who may be looking at logs or dev forum posts such as this. I’ll try to follow up with another reply to discuss other improvements we have been discussing and possible advice to help your experience in the short term.
Will the issue im experiencing here get worked on though?
Its important the issue gets resolved as i’ve noticed the memory usage stacks up massively depending on how many times i respawn / how long i play because and a lot of systems breaking resulting in softlocks.
But when i checked to see where requestdata1 is in the script i couldn’t find it anywhere.
This is a remote event which is called in a single script when joining the game and for some reason the error got confused with the planescript which is very strange.
I decided to try and replace the planescript with a new version with prints to see where it hangs as i could not spawn in properly by retrying, once i did i could spawn in again without having changed anything about it.
However though my output was filled with this when i spawned in:
It seemed all block scripts which were destroyed from the time the planescript failed to launch properly still wanted to start working.
I could not replicate the issue anymore so i decided to launch a new test server and somehow was able to get the issue to happen once again.
I will be doing some more investigating on this but i thought this information might be very helpful to you.
– Edit:
I was only able to replicate this issue 4 times in a row and then it stopped happening to me sadly.
i was really close to confirming where the issue was caused.
I’ve noticed the plane module was required by the starterscript but the script was not actually running as it was not printing anything.
It seems like the modulescript outside of the actor started but did not actually run the returned function for some reason.
Does your PlaneScript contain any calls to wait or possibly task.wait?
I don’t know if this is what is happening in your scenario, but in some of my tests I am able to keep a script thread running after the script is destroyed if it keeps waiting repeatedly. Essentially when a script thread “waits” it gets put in a queue to be executed later. However, that thread won’t be terminated once it is queued. So a script thread that waits over and over again can keep itself alive. Additionally, since the thread’s script has been destroyed, it is no longer parented to an Actor and any calls to ConnectParallel will issue the error about not being for a script rooted under and Actor.
Another case where I have seen something similar happen is if a script connects a function from a different script to a signal. i.e. if you passed a function via a global variable or via a remote event to a different script which then connected the function to a signal. This seems like an uncommon operation, but it can also create a situation where the callback can still be called after the script it belongs to has been destroyed.
