Hey creators!
Release 645 has officially landed and here’s the release notes.
IgnisRBX
42 Likes
Woah:
That’s big. I’ve always wondered if that was a bug, and I guess it is. When did you guys decide that this behavior should be fixed/removed?
Does this also apply to setting the parent of a script to nil?
30 Likes
I’m begging and praying that this fixes the error when playing it on a model which hasn’t been parented to workspace – because it doesn’t even work for WorldModels either! it’s incredibly painful having to parent potentially expensive humanoids into workspace just so that their animations can play, and then parent them back into their intended UI spot.
10 Likes
Lovely. Gone are the days of nuking copy-paste functionality and key input on your OS/in playtesting until restart
8 Likes
This fix worries me… this looks like something that some older games and even recent ones would rely on.
This fix should still go out, I’m just expecting some games to break in small ways because of this.
5 Likes
I don’t think it’ll be too bad, I don’t know anybody following this practice. My only concern is possible data saving in old games.
5 Likes
Thanks for the microprofiler scale PATCH, you help me a lot!
8 Likes
If Roblox implements immediate execution of destroyed scripts, how does this affect admin systems like Adonis that hide in plain sight to prevent tampering or being disabled by other scripts in the game? Will the client and server scripts halt due to the void parent in the game (considering that Roblox might assume objects in the nil parent are destroyed)?
Consider the perspective of thousands and possibly millions of games that utilizes Adonis. The majority of the Adonis loaders hides the model after it runs.
4 Likes
This might make it possible to once again attempt to make a compass tool using a HingeConstraint, so I’m looking forward to it 
3 Likes
I believe that nil instances and objects that have been destroyed are two different things.
5 Likes
If the script outputs any errors ScriptContext.Error (message : [string],stackTrace : [string],script : [Instance]) can get the script itself and call :Destroy() on it making it completely useless. This is a bad change because it will remove the ability to protect scripts, I destroy all my important scripts to keep them ParentLocked and out of sight from any admin systems or anything that could accidently stop them.
4 Likes
while it will very likely break compatibility for some games it seems to me like it’s for the same reason for a bunch of the flags under workspace (namely PlayerCharacterDestroyBehavior, ReplicateInstanceDestroySetting and MoverConstraintRootBehavior) where they sacrifice compatibility for more predictable/less surprising behaviour; somewhat surprised this isn’t a workspace flag too though
4 Likes
I really hope this feature WILL NOT prevent such scripts from running:
script:Destroy()
print('I will still print!')
Like people above I use it to protect my LocalScripts such as the client AntiCheat to make them nearly inaccessible to client. Some of my server-sided scripts as well as almost all of my LocalScripts and core game mechanisms relay on this behavior which should not be changed and could result in games mass-breaking.
5 Likes
It probably will, I think. Would be neat if it could be a property or something though for cases like these. Maybe that’ll be too clunky however.
4 Likes
I haven’t check but can parenting the script to nil stop them from seeing the script but script will still run? It just needs to parent to nil fast enough before the hacker can :destroy() it
2 Likes
It wasn’t like that before??? What the hell?
3 Likes
We recently become aware of a “bug” that allows scripts to run for longer than they’re supposed to in some situations. In response to this, we’ve introduced a fix that should resolve this however we aren’t going to enable it until we’ve gathered more data to make sure it won’t have any impact on experiences. Unfortunately, the release notes describe the fix itself and not how and when we plan to enable it, but rest assured we aren’t going to enable this unless we know it’s safe to do so.
If you have any specific concerns, feel free to reach out to me and I’ll pass them along to the team 
7 Likes
Could you refer to my reply above and also tell us if the desired behaviour after the “patch” would come to life make already destroyed script stop running if another script calls destroy on it? I would like to avoid such change as well so my client security methods will stay as hard to bypass as possible.
3 Likes
I can confirm the script you’ve posted here will still run, as I was the one who did the fix and created the patch notes. The note I wrote was definitely a lot more broad than the actual fix, which I’ll clarify to read:
Fixed an issue where scripts could not be destroyed while yielding via
task.wait()/delay()/desynchronize()with Deferred signaling enabled.
The fix is intended for cases like this script:
while true do
print('I will print forever!')
task.wait()
end
Calling Destroy() on this script won’t work, and even setting its parent to nil won’t affect it, even though it’s yielding. Also, if you use desynchronize() instead of wait() or delay(), the script execution timeout will catch it eventually.
11 Likes
That means that other scripts wont be able to stop a script that already nil’d itself?
example:
pcall(game.Destroy,script)
–Other Scripts trying to terminate our thread.
local OtherScript=function()
game:GetService(“ScriptContext”).Error:Connect(function(Message,StackTrace,RunningScript)
local Result=table.pack(pcall(function()
if RunningScript.Parent==nil then
pcall(game.Destroy,RunningScript)
end
end))
if Result[1]==false then
warn(Result[2])
end
end)
end
task.spawn(OtherScript)
–Nil script.
while task.wait(1) do
task.spawn(error,“test error.”)–Example error could be from anything.
end
2 Likes