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.
Studio UI Editor not deselecting properly - Bulletin Board - DevForum | Roblox
I’m unsure but is this enabled in live games?
This is not enabled in live games at the moment.
We are working to enable it in live games as soon as possible but there is no ETA just yet. I don’t think it will be too much longer though.
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.
Any update on this?
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.
Thanks!
What are your coding patterns that are causing problems with Deferred events?
I’m kind of lost on why we can’t enable it live? Like we can subject ourselves to potentially uncompatible code on Studio like we wouldn’t wanna disable it over on Studio too? I’m all in for Deferred event behaviour but letting me just test it out on Studio but not live is just annoying. It’s one of the reasons my FastSignal library has an auto-detect mode for what the game is using, because of this difference in live and non-live games (ofc also for ease of use and swapability with older signal libraries based on bindableevents but like really?)
There was / there’s much more breaking properties on Workspace that work on live games, why isn’t that the case for deferred events behaviour?
I got an IPv6 shirt, will I have to get an deferred event shirt??
You can always change the ways you go about what’s currently breaking your code. ConnectOnce is a matter of just checking if it was disconnected or not. Also I’m relatively sure that Roblox added a :Once function a while ago, though I’m not sure if it’s actually enabled. As for if you’re using a certain signal library that’s breaking with Deferred behaviour, FastSignal (mine the right one) has full support.
Predictable code usually doesn’t break because of Deferred events and when it does, it’s minor and should be easy to change. It’s not that hard to migrate to Deferred event behaviour because whatever works on Deferred mostly works on Immediate, just not the other way around.
Well, actually, none that can’t be fixed in a few minutes.
That still doesn’t fully replace Immediate’s current behaviour, e.g. if you have a connection that will disconnect itself if a certain condition is met. Yes, you can make it work, but it will unnecessarily run the connection more times than it should be ran and it triggers my OCD honestly (putting performance impact aside as I bet that it’s negligible).
Iv run into a problem that does not feel correct
I have 2 scripts
-- ScriptA
local scriptB = game.ServerStorage.ScriptB
local event = game.ServerStorage.ScriptB.BindableEvent
scriptB.Parent = game.ServerScriptService
event:Fire()
-- ScriptB
script.BindableEvent.Event:Connect(function()
print("Event")
end)
if SignalBehavior is set to Default then Event gets printed to output no problem
but if SignalBehavior is set to Deferred then Event never get printed
if you want to try it for your self here is a project
Deferred.rbxl (37.3 KB)
I have a suggestion
the problem is that this property is global meaning that it effects all events in the project
this can be a problem when creating public modules/libraries that will be used by other developers where you don’t have control over the SignalBehavior property and if you have time sensitive code this property can break your module
so my suggestion is to add a new SignalBehavior property to bindable events and functions
local bindableEvent = Instance.new("BindableEvent")
-- my suggestion
bindableEvent.SignalBehavior = Enum.SignalBehavior.Default
bindableEvent.Event:Connect(function()
print("Fired")
end)
bindableEvent:Fire()
so this will allow us to bypass the SignalBehavior property for individual events