Old things eventually break, thats just how it is.
Just time, I built a custom chat for my lobby. But even fixing that in one of my simpler places, deferred events breaks the place, because there’s a very specific order of events that needs to happen to copy across player GUI.
Hi, we’re no longer actively maintaining the legacy chat system. We instead encourage you to migrate to the new TextChatService (Migrating from Legacy Chat to In-Experience Text Chat | Roblox Creator Documentation). If you need any assistance or have any questions/feedback, please let us know in this post: TextChatService is now the default for new experiences!. Thank you!
As someone who is interested in security, I am curious as to what set of vulnerabilities that this eliminates.
I managed to implement the new textchatservice and didnt take me that long once i worked out how to do system messages.
But unfortunately deferred events still breaks my experience because it holds on to events that need to happen before other events in other scripts for the gui to be copied across from replicated storage.
So fixing this is going to take a lot of effort (so will be using immediate events for now).
1 Like
Events can be disconnected in multiple ways. The most obvious way is by calling the disconnect method on a connection object. They can also be disconnected indirectly such as by destroying an instance. The desired behavior depends on how the event is being disconnected. We distinguish these two behaviors as follows:
- Hard - Disconnect from the event immediately and drop all pending events associated with the connection.
- Soft - Disconnect from the event immediately but run the associated event handler for any events that are still pending.
In the case where you explicitly call disconnect you most probably want a hard disconnect and in the case of destroy, a soft disconnect. While we considered adding two separate methods to reflect these we decided that making all disconnects a soft-disconnect would be better and if a hard disconnect is still desired it can be achieved by reading the Connected field.
That all said, we are very open to this feedback so I will re-open this discussion internally and update the thread accordingly with the outcome.
6 Likes
Oh aight! Thanks! You’re a life saver!
Hello, I’m having some issues converting over to deferred. on immediate sending inventory weight data back to client through remote event work fine but it just doesn’t update properly on deferred. It even shows the right weight from the server which is updated right before the event fires to the client with the newly updated weight. But the client still thinks the weight is of the current item being removed. I would like to adapt but currently I cannot.
Deferred engine events are now available to use in live experiences.
3 Likes
Can you make a thread with more information in #help-and-feedback:scripting-support? If you tag me in it I will take a look when I get a moment 
Hey @WallsAreForClimbing I tried switching over one of my experiences to deferred today to see how it would do, and I’m seeing that among other things a couple of things in regards to tools are breaking and was hoping you could help me understand why.
For example, a lot of my tools start with this line (script directly inside the tool):
repeat wait() until script.Parent.Parent:FindFirstChild(“Humanoid”)
With deferred on this line errors saying attempt to index nil with parent. The tool is simply cloned out of a folder and placed directly into the player’s backpack like so:
Tool:Clone().Parent = Player.Backpack
I don’t understand why deferred would cause the code to execute when the tool has no parent, as it is placed into the backpack instantly.
There’s also this line of code elsewhere used to verify the tools the player has equipped:
Backpack.ChildAdded:Connect(function(Tool)
if PlayerHasTool(Player,Tool.ItemID.Value) == false then …
This line now errors with deferred saying that ItemID is not a valid member of tool, but it is always there from the get go before the item is cloned or placed in the backpack. These are all server-side scripts so It is not a replication thing, and I would expect that any direct descendants of the tool would be immediately reachable when it is added to the player’s backpack.
Fixing these things is not too difficult by adding WaitForChild etc., but I’m not quite understanding why this change would affect such things and was hoping you could briefly explain it to me to make it easier to find other issues this may cause in the rest of my or other’s games.
7 Likes
Not OP but I think that there are a lot of cases where turning on deferred mode reveals some really shaky coding practices such as what you have there in the first issue. Even without deferred mode, yielding at the start of a script is often representative of a code smell. For your case it may take an ample amount of rearchitecturing rather than things working out of the box.
I would instead recommend defining the character when the tool is equipped. You don’t have to redefine it multiple times, only once is enough. Similarly, if you need the character to be defined in the topmost scope, you can create an initialiser function to execute on the first equip.
-- Forward declare the character variable.
local character
-- Set it when the tool is equipped; if it doesn't need to be dropped, you can
-- make sure its assigned only once with Once.
Tool.Equipped:Once(function (mouse)
character = Tool.Parent
-- This might be how you choose to initialise.
Tool.Equipped:Connect(onEquipped)
onEquipped(mouse)
end)
I can’t say anything about the second one though. I don’t want to backseat engineer or anything, so just wanted to point out a potential solution you could use for the first issue. Far be it from me to give any pretentious or misinformative answers, so I don’t have any tips to offer for the rest and would also be interested in understanding how best to fix these cases or how deferred affects the code.
3 Likes
I figured it out!
By disabling some events I was able to narrow down the event that fired the wrong data. I had to wrap the code in a task.defer() function. This ensured the event fired at the end of the frame, AFTER the inventory weight is updated in a function way above the in the stack! This allowed the new data to be sent and updated on the client’s UI properly. Whereas in immediate everything is happening at once.
1 Like
You can easily just do
script.Parent.Parent:WaitForChild("Humanoid")
as the other one is very buggy.
Plugins and the game should have the same event behavior. But, right now I’ll have to disable deferred events so I can use F3X.
1 Like
It randomly adds : or / before some messages still.
Last week it was still having issues scrolling automatically when people send multi-line messages (though that might be fixed now?
1 Like
I notice it significantly changes the behavior of game.Players.PlayerRemoving event. With deferred signaling, it is handled AFTER player parent is set to nil, not before. The same in case of instance.Destroying event.
1 Like
Hi please move any TextChatService related conversation to TextChatService is now the default for new experiences!, thank you!
1 Like
Plugins do not have settings at present that would make it easy to configure which signalling behavior they use. We are aware of this issue though and we are thinking about how best to solve it.
1 Like
This update is, believe it or not, awful. I’ve been getting so many unreproducible bugs because of this new behavior. I’m sure it’s because of this, as none of them happen for hours of testing when the behavior is set back to Immediate. Why does the behavior have to change?? For security? Performance? Consistency? Maybe for the engine, but not for my game. Immediate events make so much more sense.
I would hate for this to be the default. This should at least come with a way to debug or a way to easily visualize what is going on here.
When looking at this image (on the right):
What does that mean? Event A, B, and C? Is that a connection, or a script signal? A whole bunch of connections? How and when is the order of execution affected? What does the left image mean by ‘yields’?
The left clearly looks less preformant, but it makes much more sense. Deferred events may make sense when replicating between the client-server boundary. I may feel better if this is better explained. When I think of ‘Deferred’, I think the event is going to be fired on the next frame, maybe that’s why I’m confused.
For now, I’m switching back to Immediate until I can get an understanding of what is going on with Deferred events. I’ve been used to Immediate for 4 years.
1 Like