Deferred Engine Events: Rollout Update

Updates Announcements
#1

Hey Creators,

Earlier this year we announced Deferred Engine Events, a feature which will allow us to improve the performance of the engine and therefore, your experiences. Our original goal for 2023 was to change the default (which is to say, the behavior of places with SignalBehavior set to Default) from immediate mode to deferred mode. We have decided to take a slightly more incremental approach and today we’ll be sharing what this means for you.

Background

Here’s a quick reminder of what we announced in the original post:

  • Rather than resuming event handlers immediately we queue them up and resume them all at once.

  • This improves performance as code that would usually trigger an event can now complete without needing to run arbitrary event handlers which may themselves trigger further events.

  • This improves security as scripts will only run at specific points in the frame. Doing this eliminates an entire set of vulnerabilities that we would otherwise need to patch on a case-by-case basis.

  • This will allow us to make additional optimizations in the future.

As part of that announcement we shared our long-term plan for the feature and what we were hoping to achieve before the end of the year. Our original goal for 2023 was to change the default (which is to say, the behavior of places with SignalBehavior set to Default) from immediate mode to deferred mode. We have decided to take a slightly more incremental approach and today we’ll be sharing what this means for you.

Updates

Firstly, this afternoon we will be enabling deferred events by default in our template places. This means that when you create a new place it will have deferred events enabled by default. While we encourage you to leave this setting on, we know that some of you may use libraries that are not compatible with deferred events. If this is you, you will still be able to opt-out by changing the SignalBehavior property to Immediate.

Secondly, we are pushing back the date that we change the default SignalBehavior to Deferred until February 2024. We are still actively monitoring the impact this will have on experiences to ensure this transition results in minimal disruption. We will share more details in the new year but as a reminder before then, if your experience is not compatible with deferred events you can opt-out by changing the SignalBehavior setting to Immediate. Even after we change the default, you will still be able to opt-out by setting SignalBehavior to Immediate.

Finally, we have been quietly making some improvements behind the scenes:

  1. Based on your feedback we have changed the behavior of Disconnect when deferred events are enabled. Previously, if an event fired multiple times before Disconnect was called the event handler would run for each of those invocations, even after Disconnect was called. Now, all pending invocations will be dropped - the same behavior that exists in immediate mode.

  2. We have also made some optimizations to our signal implementation which may slightly improve the performance of your experiences.

Thank You

As mentioned in our previous announcement, one-day we would like all experiences to run with deferred events enabled however we know this is going to take time. We will continue to support immediate mode for the foreseeable future and you can continue to expect it to be years until we are ready to completely switch over to deferred mode. In the meantime we will keep you updated and remain flexible with our plans as we continue this transition.

If you have any comments, concerns, or suggestions then feel free to reach out to me directly over message or on this thread and we can discuss.

Thanks!

143 Likes
Leaderstats Tutorial For Noobs
How to make a synchronized moving elevator platform using CFrame
GetInstanceAddedSignal can cause all Connects to occur twice if associated Objects parent is nil and SignalBehaviour is Immediate
Issue with GetPropertyChangedSignal not firing
Perpendicular: Parallel LUAU made easy!
How do events/signals work under the hood?
TextLabel does not update
Serious & Expensive Bug regarding Gamepasses
How do you tie the camera back to the player?
Parallel Scheduler - Parallel lua made easy and performant
#2

This topic was automatically opened after 9 minutes.

#3

Oh this sounds neat!
Just one tiny question.

Has the issue of clean up scripts been addressed already?

With the updated event system there used to be an issue where if you had any scripts that needed to execute clean-up code or any other logic upon object destruction, this would no longer be possible with the new system.

Does this already have a solution in place?

13 Likes
#4

This is neat, I’ll definitely try it out!

9 Likes
#5

It doesn’t matter how long you wait to make a breaking change, it still breaks all of my games that depend upon the behavior unless I go through and meticulously audit each one. It also breaks games that I like to play whose developers aren’t around to maintain them anymore. Something seriously needs to be done about this because the problem is only going to compound in the coming years.

Is making it on by default not sufficient? Does it have to be force enabled on all games like this?

21 Likes
#6

I 100% read all that and it sounds good

6 Likes
#7

I believe I asked this when this was announced, but what is the performance gain from enabling deferred engine events due to how signals are handed? Or have those performance buffs not been enabled until all of Roblox is on deferred events?

11 Likes
#8

There are lots of changes that technically could remain settings with enough work, unfortunately this is not one of them. Many of the long term benefits driving the change in the first place cannot manifest until it is forced.

For example, architecturally as long as it isn’t forced all internal engine code still has to be written in a way that assumes script logic could immediately be jumping in and shuffling around the contents of the DataModel any time a property is changed. We can only skip dealing with that complication once we know that no place is using immediate mode events.

23 Likes
#9

What do we need to change in our code so this new update doesn’t break out scripts?, from what I understood events do not execute in order meaning they are asynchronous right?, so what would we need to change to use this update.

11 Likes
#10

So deferred events are great only for the code who might trigger events. However, if you are doing many tasks, all these events get spammed the next frame, right?

I say “spammed” because when I tried it to know how long it takes for my code to execute, it froze Studio the next frame lol.

Anyways, when I enable this feature in my game, I don’t see any problems and everything works like it should, but what I am afraid of is if there is anything in my code base that could be in danger for using this feature. Though I don’t remember myself relying on the behavior of using events to complete stuff, I still feel that when you change a property it’s respective event should automatically trigger and not wait until the next frame or what you call the next resumption cycle.

I know my point of view doesn’t show much of an issue with the feature, but there is something, something that makes me feel uncomfortable when enabling this feature. I prefer to not even interact with it…

9 Likes
#11

I do understand that, but it’s very annoying that these breaking changes are becoming more and more frequent with no end in sight. It’s seeming pretty likely that in 10 years nothing I’ve ever made on this platform will still work unless I stick around to maintain it indefinitely.

image

Pretty much every “default” is this panel is a potential breaking change, and I just don’t have the time and patience to go through and audit all of my projects for each of these changes.

16 Likes
#12

I generally dont mind the idea of deferred events since event firing is a big overhead in script performance.

The issue as Chipio mentioned is that it’s a breaking change (cough AncestryChanged).

Also, what happens if deferred events is on in a place and a plugin relies on immediate event resumption for whatever reason.

9 Likes
#13

You should keep in mind that the majority of these affect <10%, sometimes even <1% of experiences in the first place, and developers generally have a good idea whether they’re in that affected percent with a few minutes of reading the relevant announcement post.

Though this is obviously one which affects a larger percentage of places, hence the very long timeline for migration.

Also, some of the three phase rollouts are almost 3 years old, the reason there’s so many is exactly because we make sure to give people plenty of time to adapt, the introduction of new three-phase rollouts for breaking changes is quite rare, they’re about one every 6 months.

19 Likes
#14

I remember when deferred was first announced and I was very squeamish about using it, now I’m an ardent supporter of it and realise that a lot of my initial fears about deferred were pretty unfounded. It’s crazy how many bugs I’ve avoided simply by switching to deferred and putting defensive architecturing first and foremost in mind when working on my experiences.

It is unfortunate that a host of older experiences are going to break due to the nature of Roblox’s client and that older experiences can’t just run older versions of Roblox like a Unity game or so, but I believe that deferred is the future of the platform and the health of developer code, and is significantly worth adopting early. In the majority of cases, no extra work is required to make code compliant with deferred. Even if immediate continues to be supported, deferred is too good to pass up.

Enabling deferred in default places is a great start, since I’ve been developing with deferred in mind for a while now. There’s still work to be done on some of my existing experiences but I’m happy with how deferred has been treating me so far. Performance is important for my main project and we do a lot of number crunching and heavy computations to make everything come together.

13 Likes
#15

Although I’m happy that Roblox is making an effort to improve development, breaking changes are breaking changes. It wouldn’t be harmful to just leave existing places as is and use this new behavior on new games.

7 Likes
#16

Oh wow, I thought this was already on by default, so I enabled it and it broke my game, and to be completely honest, I don’t know how to fix it.

7 Likes
#17

Forcing deferred events WILL destroy all my games, and probably all popular games to.

It seems reliable on paper, but it is not working out that way. It feels much more random and unpredictable with deferred events. I can’t imagine having to rewrite thousands of lines just for a small performance boost.

8 Likes
#18

What exactly is breaking for you? Do you have race conditions or timing windows that depend on immediate dispatching? I can try to suggest some better approaches. In general it’s a really bad practice to rely on time windows and immediate dispatching.

This goes for everyone who has a problem with this. You need to rethink your game’s control flow if you really depend on immediate dispatching for things to work properly.

11 Likes
#19

What are examples of things that would break?
What is safe?

EDIT: did some research: [Beta] Deferred Lua Event Handling

6 Likes
#20

It breaks games I don’t even maintain as much. even old games that aren’t maintained anymore, I went to test it, and it suddenly break my Freddy Fazbear bin reference I put in my game, The changes should only apply to new places, Just remove the Default option, and only apply it to new places, so no older games that aren’t maintained break in the future

4 Likes