Client Difference Log
API Changes
Added Property Color3 Studio.Debugger Current Line Color
Added Property Color3 Studio.Debugger Error Line Color
Added Event StudioService.OnOpenGameSettings(string pageIdentifier) {RobloxScriptSecurity}
Changed the security of Function Players:CreateHumanoidModelFromDescription
from: {RobloxScriptSecurity}
to: {None}
Changed the security of Function Players:CreateHumanoidModelFromUserId
from: {RobloxScriptSecurity}
to: {None}
Removed Property Studio.Auto Indent
Removed Property Workspace.TemporaryLegacyPhysicsSolverOverride
Removed Event NetworkClient.ConnectionRejected
(Click here for a syntax highlighted version!)
I did not know that I would live to see the day math.round would be available in Lua. Today is a good day.
I also highly appreciate the change to WeldConstraints to help reduce floating point precision error. Anyone that works with vehicles on large maps knows the pains of this.
I believe RichText is the replacement.
So math.round is finally a thing for Lua/Luau, might just check it out and how to use it since the recap for this month was made yesterday.
Interesting changes/additions into studio with a success screen being a thing now which I personally like, and permission settings for group games with individual buttons, but what sections and settings will be an individual chosen and picked inside permission settings?
Not so great after all, I guess I have to re-write some stuff and remove this from my UI tutorial which will be hard to find with scrolling and scrolling.
UIInlineLayout was never enabled. Were you using it in production?
The permission settings page for group games now includes individual permissions. (These cannot be added now, but may have been added in the past via script or plugin.)
What does this mean? Is this related to the ability for group games to add permissions for individual users as well? I honestly don’t understand why this wasn’t (isn’t) a feature. I hope that “for now” carries the implication that we will be able to add users independent of blanket role permissions soon; and vice versa for private games to add groups as well as roles for access.
Roblox have hidden it (I’m also surprised nobody noticed it), but on sitetest1’s version of 443, it included two functions
These required an FFlag to be enabled to work properly
Players:CreateHumanoidModelFromDescription()
Players:CreateHumanoidModelFromUserId()
(found them in the object explorer lol)
These functions insert a rig based on either the description or the avatar of the associated user id.
I’m wondering if these functions have been enabled yet.
Also…
THANK YOU
Me when a thing for an app that was removed nearly 4 years ag
I actually still have the app on my iPad, but I suspect it wont work anymore :3
Thank you! It would also be nice if it were changed to accept a second argument that would round the number to the nearest multiple, like in this example:
math.round(6, 10) -- returns 10
math.round(2, 4) -- returns 4
math.round(1, 8) -- returns 0
math.round(-4, 5) --returns -5
It’s not very hard to code this yourself, but it would still be helpful to have. I might make a feature request for this, but either way this is a very nice addition.
The reason why this was not included is because it makes it tempting to try to round numbers to the nearest X decimal places, when that will not do what you expect it will for most numbers. Assuming a sane implementation of math.round(n, step):
print(string.format("%.20f", math.round(math.pi, 0.1)))
-->
3.10000000000000008882
Oops, what happened? 3.1 is not exactly representable as a floating point number, so no amount of rounding will make it “perfectly” rounded off.
I noticed that many bugs in Expressive Output Window beta were solved, but they are not listed on the bug fixes… why?
That comes down to mainly just what gets listed, there’s actually pretty much always I’d say at least 10 things not listed that you’ll interact with that are changing (and there can be very very many unlisted changes sometimes).
For a very detailed explanation on why, here you go! 
Most performance and bug related things are only explicitly listed somewhere if they are “popular” or ones that’d have a much bigger effect I’d say. Part of that is probably just because it’s very difficult to list off all of these changes and part of it is also because once something is listed people usually expect it to stick. That’s why we rarely see updates for beta features unless they are easy to call “improvements.”
Sometimes bugs can not be removed but can just change a little for example until they are noticed or reported (although there are a lot of bugs that will be known about in releases but not fixed).
This all is just a quirk of how Roblox updating works. It’s hard for Roblox to push out very quick changes to such a large platform, so instead, Roblox updates weekly, and they plan releases a week in advance (this is pretty simplified though). When you see a feature released in the middle of the week, you’ll likely notice that you never have to update and this is because the update did already exist, it just had not been enabled. (The way that actual works is called “fast flags” or “feature flags” or FFlags for short, and basically they enable and disable features, and your game will get updated FFlags when it runs)
Basically, like I said, it’s extremely difficult for Roblox to push out updates when they aren’t weekly because first of all, Roblox is such an enormous platform that their own internal developers probably work in separate environments I’d think, and, a lot of developers. Those developers all are making updates for various pieces and components of Roblox, and all of that is going through testing and stuff to make sure that no really breaking bugs get out there (sometimes stuff slips through, and this happens more frequently around the holidays because many staff are, well, on holiday and it’s hard for them to update fast flags).
Additionally, having week long periods between actual updates means that Roblox clients will actually have the chance to update. (I believe if you still have an old Roblox launcher, such as a 2012 one I have backed up, it actually is not even compatible anymore and won’t run the game at all despite the fact that they still act nearly identical, so, the launcher can change too and if people don’t have time to update, well, they might not be able to play!)
All of this is basically a more detailed explanation on why Roblox updates work the way they do. I’m not entirely sure how Roblox engine development works (I only have a basic idea) to be completely honest, so, what I have explained is for sure probably not 100% accurate for those specific things.
(Additionally, documentation for new stuff like that almost always comes a few weeks later or sometimes even longer, that’s mainly because creating documentation can take a massive amount of time, after all, someone is going in and making all of that info, example use cases, etc, etc, and that all has to get processed and verified and stuff by Roblox)
AFAIK it’s primarily based on whether an engineer working on a ticket appends a proper public-facing description to it. These release notes are automatically generated. Not so much on whether an issue is popular or not. It’s probably not an obligatory step to add an outward-facing description.
Neat to know, and it sounds like a quite smart system.
I think the “popularity” bit comes down to what stuff developers think is worth an update entry probably, so, that makes a bit of sense.
However Expressive Output Window beta was very well accepted by the community (from what I saw in its launch post) and it is really good; however, it was plenty of bugs, which made its use impossible.
And the best function of the Expressive Output Window is the ease of viewing tables. I was very excited but later disappointed with the bugs.
In practical terms, being able to view a complete table with just a print() is extremely useful and avoid wasting time and focus, when we have to create multilevel for / pairs / ipairs loops.
In summary, the Expressive Output Window is a great time saver.
Therefore, I think that a function as important as this should be notified to all users, as this would help the entire developer community.
The biggest factor is how “clean” the fix is.
If there’s “one bug ⇒ one ticket ⇒ one bit of code changed ⇒ one release note” then everything works as expected.
If the “bug” is really some more complicated extensive problem which ends up taking changes from multiple engineers over time to deal with, none of the individual changes may may have a sensible release note to add, even though in combination they will end up solving the bug as the user sees it.
True, as tnavarts describes above it is much more complicated behind the scenes.
In the past, there could be added as part of a beta. While these can’t be added anymore, some users never got removed when the beta ended. I can only assume that this has been re-added for the purpose of allowing developers to ensure their permissions are appropriately setup and to remove unwanted access.