Are cleanup scripts ever going to be fixed, or will I have to use this?
task.spawn(function()
script.Destroying:Wait()
-- Cleanup
end)
With deferred events, I made a script that changed the CanCollide property of a part in a for loop. Then, I set up two connections to print CanCollide: a normal one, and a parallel one.
CanCollide code:
wait(1)
for i = 1, 50 do
workspace.Part.CanCollide = not workspace.Part.CanCollide
print("Set CanCollide to", workspace.Part.CanCollide)
end
Normal connection:
workspace.Part:GetPropertyChangedSignal("CanCollide"):Connect(function()
print("Normal connection sees CanCollide as", workspace.Part.CanCollide)
end)
Parallel connection (script is parented to an Actor):
workspace.Part:GetPropertyChangedSignal("CanCollide"):ConnectParallel(function()
print("Parallel connection sees", workspace.Part.CanCollide)
end)
I expected at least one of the connections to see the CanCollide property change. However,
1 Like
Can anybody please advise, perhaps @colbert2677 ?, how to solve this use case with deferred signaling enabled?
I want to know the position of a primary part of a model, when it is being removing/removed from workspace. Problem: The event handler will only kick in after all the children of the model are already parented to nil, and they are no longer accessible referencing the model. Basically, how can I replace the following code that used to work with immediate signaling? Thank you.
workspace.ChildRemoved:Connect(function(model)
print(model.PrimaryPart.Position)
end)
1 Like
Try and use
local model = workspace.ChildRemoved:Wait()
print(model.PrimaryPart.Position)
I found a workaround. GetPivot() can still retrieve the modelās PrimaryPart position even after it is already parented to nil.
workspace.ChildRemoved:Connect(function(model)
print(model:GetPivot().Position)
end)
1 Like
welp time to have a week of testing deferred, modified very few lines of code to make it work surprisingly.
Is there a plan to rework any of the Destroying or Removing events to better reflect deferred signaling?
The purpose of these events was to access or listen to something right before it got destroyed or removed, but since any functions connected to these events are going to be executed at a deferred point in the current frame, when they finally get executed, the object will already have been destroyed or removed.
That would be useful for a .Removed or .Destroyed event, but not for a .Removing or .Destroying event whose purpose was to allow us to execute something before it gets destroyed/removed.
3 Likes
Blockquote You should keep in mind that the majority of these affect <10%, sometimes even <1% of experiences in the first place
Where did you get this percentage from?
Also 10% of experiences is a lot since if theres around 5.5 Million experiences that means it effects around 550,000 experiences. Thatās quite a lot. I agree with @ChipioIndustries eventually Iām gonna move on to something else, but Itās gonna be likely that my games are gonna break within a few years because of updates like these.
ps. I am not against this update, in fact Itās quite the opposite, I support it. I just have some concerns such as it being forcedā¦ unless Iām getting the wrong idea, if I am please correct me.
I think the main problem is that destroying is supposed to run BEFORE the part is destroyed
4 Likes
I donāt know if this is a bug or whether I did something wrong but after testing something the Instance.Destroying signal actually didnāt fire at all on a client-sided script.
I had to use the .Changed signal instead when an object is parented to nil and it felt weird to do it that way.
It kinda is how we used to write clean-up scripts but weird that .Destroying doesnāt fire when a object is destroyed.
1 Like
Hey, everyone, Iāve been trying to convert my game to using deferred engine events since it is becoming the new standard, but I have had some issues. Specifically, issues with setting variables in scripts, or at least seems to be a recurring issue. Let me show you an example:
As you can see, the first variable seems to set up, but on the second one, it occasionally throws errors. Both versions of the variable create this error. This is the very first thing listed in the script. It is not a local script, and the tool cannot be dropped or unequipped. This issue has only been happening with deferred events turned on, and there is no issue with immediate as the setting. Maybe Iāve just been setting up variables incorrectly all this time. Any help or suggestions to fix this would be appreciated. Thanks
@WallsAreForClimbing @tnavarts
Have the events that are connected to instance destroying been fixed? If I recall this update broke that, or so Iāve been told.
Also, even if this becomes a new standard, are we still going to have it as an optional flag? Iām much comfortable with the immediate as Iām not aware of any actual improvements that deferred does besides affecting how events are scheduled.
2 Likes
Destroying works, but if the Deferred event gets rolled out, the naming does not make sense anymore.
.Destroying ā .Destroyed
.CharacterRemoving ā .CharacterRemoved
.PlayerRemoving ā .PlayerRemoved
@WallsAreForClimbing @tnavarts What would happen to these names? Itās now misleading in that the part is already destroyed but itās being indicated as a present tense event.
Yes, itās likely weāll need to rename these events and provide additional data about the previous state.
2 Likes
If these events are renamed, will there be new methods that allow developers to take action on instances / players / characters that are about to be destroyed before they are? There are a lot of important use cases that depend on being about to intercept instances prior to the deletion. Without this, it would be making switching to deferred signaling much more difficult.
2 Likes
Would you be able to enumerate some of those cases in a bit more detail? Iām interested in where this crops up the most to understand if we need general purpose APIs or if something more specific for certain use-cases would make sense.