I find it very annoying that i have to manually go to workspace and change it to “Immediate” every each time i make a project in roblox studio. Its not just me some developers on devforum got confused by the “Deferred” signal because they are used to the events getting fired immediately.
Alternatively roblox should make it so you can set SignalBehavior to Immediate by default even if you create new empty baseplate.
Right now the only solution is to create template baseplate and save it as .rbxl place and duplicate it every each time you create a new project in roblox studio.
Do not use Immediate mode for new work: The engine will eventually be moving to Deferred mode, you won’t be doing yourself any favors by holding out as long as possible.
If you’re having problems with working under Deferred mode please reach out in one of the announcement threads.
Can you guys make it so SignalBehavior is read-only so i can just check workspace.SignalBehavior==Enum.SignalBehavior.Deferred instead of relying on BindableEvent.Event:Connect to check if SignalBehavior is deferred
Should I make new feature request for that or you will just tell the engine team about that?
Its hard to explain because im not native english speaker and i also dont want to show source code of my scripts but it would be very useful for my scripts and it would make the code look alot cleaner after removing BindableEvent that checks for deferred and replacing it with workspace.SignalBehavior==Enum.SignalBehavior.Deferred check
The major barrier of converting my projects to deferred lies with the behavioral problems of things like CharacterRemoved or Destroyed events. For example, the character is already removed before the CharacterRemoved event is fired. This is a huge issue with either a very bad workaround (using some sort of cache and custom signal system) or it cannot be done at all. If these problems are fixed I would be more than happy to convert to deferred signals. I am still designing my codebase around deferred events, however, I cannot actually use deferred due to the aforementioned issues.
Thanks for explaining it for me. This is one of the cases where i would probably add that SignalBehavior check so my script doesnt get broken because of Deferred signal.
Destroying not working is a bug (filed over at Instance.Destroying fires too late). CharacterRemoving etc is less obvious, out of curiosity what do you rely on the character being in the data model for during CharacterRemoving?
For whatever little my two cents matter, the way I’ve always interpreted these event names is that “Removing” means that the thing isn’t destroyed yet when the code runs, and “Removed” means that the thing was destroyed prior to the code running. I widely write code with this understanding. Does Deferred mode change these assumptions? If so, what’s the new consistent rule?
I disagree you can just also do script:FindFirstAncestor() or script:FindFirstAncestorOfClass() to eliminate script.Parent.Parent.Parent.Parent.Parent.Parent issue.
I meant that they want you to have a cleaner codebase instead of doing old roblox style where you place scripts in whatever place you want them to be, e.g workspace, inside of models (take NPCs for example)
Since having cleaner codebase where scripts are mostly located in 1 location makes it easier for devs to update their scripts if Roblox changes something drastic and they don’t want people bitch and moan when they release a engine update and it broke 99% games.
In short, they want people to have zero excuses to not fix their scripts because of engine updates.