local connection;
connection = part.Touched:Connect(function ()
if not connection then
return
end
part:Destroy()
connection = nil
end)
Now imagine you have a second script which is also listening to ‘Touched’. Since it has a different connection it won’t be assigned to nil and the listener will still run.
Coming back to this a few months later, is there any way of making it so plugins dont have to rely on this behaviour.
I dont want wildly different implementations of my plugins because one dev has it on while another has it off.
I understand the plan is to roll this out globally, but I’d still like to be able to work around the issue currently since the SignalBehavior property cant be read by plugins.
I’ve never had any issue with events like that. Basically all of my code just worked with Deferred. What were you bumping into exactly with deferred behaviour?
Actually I kind of lied back there.
Basically all of my code didn’t break, but some stuff that was using Quenty’s Signal broke and some other 3rd party libraries.
Still though, @metatablecatmaid, your code shouldn’t be changing massively to work with both Immediate & Deferred, I would go over and say that there might be bigger structural issues behind this. I’ve never went through the issue of having to go and have huge code differences because of Deferred.
I understand this, the issue is if I have to use something that doesn’t work properly under one system, such as you mentioned, Quenty’s signal library, of course in the very unlikely chance I have to use it of course. I usually write my own stuff anyway.
I do find out some weird interactions on Deferred Event though. For some unknown reason, I get random triggers from other scripts while doing a script that has nothing to do with it.
This is nice feature, but I still will wait for some improvments before use it.
This lua code below this sentence is horrible, cus we aren’t guaranteed that event handler called once after disconnect (You can
accidentally forgot about this and have bugs).
connection = event:Connect(function ()
if not connection.Connected then
return
end
connection:Disconnect()
-- do something
end)
I notice a new SignalBehavior being added, AncestryDeferred.
This solves the Instance hierarchy problems while preserving expected behavior for games that don’t like all event fires being asynchronous.
I look forward to that becoming the new default signal behavior instead of full-on Deferred. Although it’s not quite as good as my proposed solution, Roblox never listens to me so I’ll just accept this mini-win anyway.
Not sure if anyone has reported this here yet, but Deferred events breaks the UI Editor. It’s been bugging me for the longest time and I didn’t realize that it was this all along. Here are a couple threads related to the issue. In short, selecting a UI object in Explorer and then moving the mouse over the viewport starts dragging immediately, and you’re unable to select/deselect the objects properly.
Does this mean there will be a separate queue for each of these?
Personally this one will be the biggest issue. I never used funny tricks like FastSpawn or inline resumption (which seems like a bad practice in the first place).
A big reason for me not setting SignalBehavior to Deferred is because a lot of popular plugins (e.g F3X Building Tool) rely on it being Immediate, so we cant just enable it even tho the game can run fine with the Deferred.
Perhaps something like workspace.PluginsSignalBehavior to separate the plugins from the game would make the push for Deferred a little easier.
I am planning to make a new project soon. If this update was released in it’s current state, it would flip some of my coding patterns upside down. I don’t want to spend time writing code just for it to be obsolete shortly.
Hi, we’re currently waiting for Deferred signal behavior to be live before we can release a fully-fledged project properly (which is going to arrive closer to release soon). We rely on the signal behavior as it has fixed numerous weird edge cases and we have adapted the codebase to it too – testing out the project live with Immediate signal behavior breaks most of our code!
Can you guys please try to have this new signal behavior live ASAP, or at least, provide some way for us to toggle it in live servers?
It’s been quite some time but I wanted to give you all an update on this. Given the number of concerns that were raised initially we wanted to take some time to make sure that a number of features were in place to make transitioning as smooth as possible, or offer reasonable alternatives. A number of teams are actively working on this effort but I cannot give you an ETA at the moment, just know it is on our radar.
If you have any specific, time-sensitive, concerns then feel free to reach out to me directly via my messages.