Did you test? You can’t be sure that it’ll break because it uses bindable events.
1 Like
The results with Immediate prints a, b, c, d, e.
3 Likes
This technically doesn’t achieve the same thing as the traditional fast spawn method. Since you wrap the invoke in a coroutine.resume, it eats up the stack trace, and you can no longer click the error to see the origin.
2 Likes
Then these unknown "invocation point"s are a bit less frequent than what I expected. I’d still want to hear from staff how exactly these work and how frequent they are.
2 Likes
The ChatScripts also use bindables in unorthodox ways. The main example is using them to connect to CoreScriptChatConnections or whatever the key is called.
But the whole ChatScript API needs a rewrite to conform to Roblox’s modern style rules.
2 Likes
The BindableFunction is what allows the stack trace to show up; this is why people use FastSpawn in the first place.
2 Likes
You may be right, I tested again and it works. Didn’t work first time for some reason, maybe I misclicked?
2 Likes
Will this affect parallel lua in any ways? I couldn’t understand how it works fully to be honest so it can be completely unrelated too.
2 Likes
Can we get documentation on “redundant” events? If a value changes, then changes again before the event fires, the first change won’t fire an event right? What else has this behavior?
8 Likes
From what I’m understanding it sounds like they’re trying to reduce the amount of stress of performance that can occur for every frame and scheduling across more events in a very short time in between frames for the task handler thing.
This techinically helps with performance and will help prevent servers from crashing and hold larger players better in theory, but games that handle a lot of action and expect the speed to be there are going to suffer the most which sucks. And there’s also the issue of unexpected behavior to occur especially with developers who are still used to scripting in their old habbits.
Although I think I’m probably completely wrong: there’s a lot of hard points to understand in these posts made and I think going into more detail will help us from getting spooked out about having to go through thousands and thousands of code and retesting if we’re thinking/going about this all wrong.
It’s really hard to comprehend how good this announcement is supposed to be when you mention optimization & delay in the same post.
8 Likes
I don’t know everything yet, but I’m severly against this change. Yes, there are edge cases where performance may dip with a ton of events firing, but it’s more important to keep things like this snappy. I say this because you mentioned specifically that this will instead be tied to the Scheduler.
Patterns like wait() are already discouraged because they add initial and unecessary delays to your code execution, adding more things to this sort of pattern of articial lag is only going to make things worse for tight code.
Kind of uncomfortable to know that if the scheduler is lagging / throttling (most front page games have plenty of lag on the scheduler) you’re going to see visible delay in things like property changes and a myraid of other practical uses for events like you already can with wait() patterns. This is going to impact many games.
Edit: just read that it’s toggleable lol
6 Likes
If events are hooked in via Event:Connect(), they should all process as intended in the correct order, just not at the exact moment they occured.
2 Likes
I think Roblox has severely underestimated the impact that this change will have on so many different types of code. This isn’t just a minor change that will only affect a few people, this is literally changing the execution order of all event-based code that has ever been written on the Roblox platform, and this change needs to be treated with a lot more weight.
This is bound to break/alter so many things, and it is extremely difficult to narrow down every single piece of code that will be affected in some way. Even in cases where it won’t necessarily cause errors, this will introduce so much undefined and untested behavior in many existing games.
I have spent so much time writing the logic for my existing games and making sure that it all runs exactly the way I intended it to. But with this, Roblox would just be throwing a wrench into all of that and saying “well, tough, now you need to revisit all of your code and debug it all over again.”
There needs to be a way for us to maintain backwards compatibility. Roblox cannot force such a broad change that will have so many unintended consequences, placing the burden on us to audit and fix all of our existing code that we’ve ever written on the platform.
47 Likes
I’m pretty sure you’re correct on this, I’m just not confident it is the intended impact. Granted it’s a corner case, and my projects are small enough that I should be able to get rid of my usage that is similar to this, but I worry for others.
2 Likes
but you can opt-in by changing SignalBehavior on workspace to ‘Deferred’. Eventually we plan to phase out the existing behavior and change the default behavior to deferred, but we haven’t set a date just yet as we know this change is likely to affect some of you.
That’s why this is an opt-in change, the default behavior will eventually change but if this is a big deal, you can change a property of workspace (assuming it wouldn’t already maintain ‘immediate’ for older games)
@TripTrapp84 doubt on that one, with the old way you can operate under the assmumption that it will be firing consistently fast. lua rarely slows down, the scheduler will though due to throttling and abuse, if anything it’s going to be more unpredictable with deferred lol
It seems like this is only a temporary option and that they’re planning to completely remove the existing behavior at a later point:
2 Likes
It seems like this is only a temporary option and that they’re planning to completely remove the existing behavior at a later point:
7 Likes
Setting the SignalBehavior to Deferred causes off-by-one frame errors in the core camera scripts itself! It’s hard to quantify, but I’ve created steps to reproduce an experiment that shows this is happening:
It feels really sluggish to pan the camera on mobile devices if the framerate drops below 30 FPS.
5 Likes
This right here in almost perfect wording is why I left this platform years ago & only participate in the DevForum. The amount of times that I’ve had to rewrite a game over stuff like this that changes out of nowhere and I, as a developer, am forced to deal with it is quite annoying.
Even though it’s opt-in, it’s going to replace current functionality eventually. So, regardless of when someone decides to change it, I’d still have to look back at my code and fix it.
The theory the possible positives behind this is actually really good considering that it’ll make larger servers much more manageable, prevent frame latency, etc but, it’s highly frustrating that there’s no backwards-compatibility which would’ve been nice.
9 Likes
I read one of the comments which explained something to me, I thought this delayed until renderstepped since it was #1 on their list of defered-to events, but now I see it will defer to the end of your event connected lua code almost always. I agree now, this is definitely a bad change, not having snappy code execution is worse when the alternative is code execution at the end always. It’s the same thing but removes any guarantee that what you wanted to happen has happened. Along with lag being a much bigger issue now because of the change
2 Likes
It’s kind of difficult to prioritize making sure our code is compatible with this change if don’t know when the change will occur. Can we get any sort of rough timeline of when this will be rolled out? Days, weeks, months, years?
1 Like