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.
5 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
5 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.
3 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.
3 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.
Hey @WallsAreForClimbing, thanks for your patience while Iāve been out of town.
Here are some examples:
- When various unrelated scripts attempts to destroy various models (e.g. developer inserts a lava brick that destroys parts or their ancestor models, or e.g. the FallenPartsDestroyHeight), a global script hopes to read or preserve specific instances within those about to be destroyed models, but in order to grab those instances before theyāre deleted, we need to be able to listen to a working implementation of Destroying where descendant instances arenāt destroyed until after callbacks listening to Destroying complete.
- 20 special types of glue are used to connect any two models together. Each type of glue has a special effect, such as adding a particle effect, or using a rope constraint instead of a weld to connect the two object together. A createConnection function and cleanUpConnection function interface is defined for each of the glue types. In the event one of two connected objects are deleted, we want to clean up the connection instances by calling cleanUpConnection(), since while the deleted model may have all its instances cleaned up, there may be instances in the non-deleted model or instances outside both models that need to be cleaned up. However, because the connection instances that are descendants of the model being actively deleted are already deleted due to onDestroying firing too late, cleanUpConnection errors when it canāt find the instances within the deleting model and thus fails to clean up the connection instances in the non-deleted model.
There are many other cases where immediate mode signaling are very helpful beyond the Destroying method. For example, in my game, Iām trying to run some logic right before property changes are replicated from Server to Client. For example, I call PropertyChangeAlertRemoteEvent:FireClient() on the server right before setting part.BrickColor = BrickColor.new(āReally redā) and 17 other property changes on the server, and I want to be able to listen to PropertyChangeAlertRemoteEvent.OnClientEvent on the client and immediately run client logic right before the property changes stream in from server to client as part of ReplicationReceiveJobs. Unfortunately PropertyChangeAlertRemoteEvent fires too late due to deferred event signaling.
Thus I would strongly advocate for a general purpose solution for breaking out of deferred signaling when there are specific necessary use cases. Right now there are specific behaviors that are possible with the legacy immediate mode signaling that arenāt possible with deferred signaling. I would love if Roblox could preserve those behaviors, since they are powerful and enable complex state management behavior that are critical for making highly technical games like our game Adopt Me.
2 Likes
Hello!
Itās about my plugin.
If I do
workspace.SignalBehavior = Deferred
that button click event is working
If I do
workspace.SignalBehavior = Immediate
that button click event is not working
Moreover, the rest of the buttons in the plugin work, but these are the ones that are not shown in the video.
itās about this button event.
DropValueTBClone.MouseButton1Down:Connect(function()
Richtextbox.Text = BtnName
print(BtnName
end)
This happens only for the plugin.
It has been some time since deferred events have been rolled out, and now, I really hope that either, immediate signal behaviour will NEVER be phased out, or that deferred signal behaviour is strait up scrapped
I have encountered too many times issues coming from deferred events. In two of my modules
I encountered another issue, which is really annoying me, just today, here is a recreation of the issue (the issue was with UI, rather than a Part, but itās the same thing)
local Lock = false
game.Workspace.Part:GetPropertyChangedSignal("CFrame"):Connect(function()
print("CHANGED", Lock)
if Lock then return end -- Ignore the change, if it was done by the script
end)
Lock = true
game.Workspace.Part.CFrame *= CFrame.new(0,1,0)
Lock = false
What this code does is prevent the Changed event from running when the script changes the property. This is useful when listening for that change, but wanting to avoid your own script from triggering it again it.
Deferred signal behaviour has caused some of my code to strait up freeze studio (and probably live games that use it), because, with deferred signals, the property of the object is updated later on, which can cause infinite recursion (the property change causes yet another change to the property, infinity)
This kind of āLock Variableā is something I have used, not commonly, but still many times, and I am afraid of more things breaking if they switch to deferred
Iāll probably defer changing the Lock variable to false, or store the changed value of the object, and if the value of the object is the same as that value, it will return. These solutions annoy me though, Iām not a fan of them
(I did change it so I defer changing the variable to false, but I need to defer it twice for some reason? This is so scuffedā¦)
Here is another example of deferred signals breaking my code Parallel Scheduler - Parallel lua made easy and performant - #14 by Tomi1231
In this case, deferred signal behaviour seemed to defer the initialization of scripts, changing the order of events, and breaking my module. The fix was easy, but it took me some time to figure it out, and I shouldnāt have to defer the firing of my bindable eventā¦
Please PLEASE reconsider this change. It will break so many games, and I donāt want to see yet more old games that donāt work or strait up freeze
2 Likes
I wonder how many of the potential breakage people are mentioning could be due to mixing Signal behavior, or old versions of libraries that havenāt been adapted for it. I previously had designed my Signal library so that goes out of the occasion. GoodSignal is Immediate mode only, and sleitnickās fork does not adapt to it but rather just gives you an extra function to use which discourages its use IMO, and means devs have to go out of their way to test this which is hard.
It seems really weird to me that people would be relying that much on this kind of behavior from Signals tbh.
1 Like