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.
I know it seems to be complicated, sorry for insist, but I worked a lot with extensive projects too
and it all comes down to having systems and methods aligned, no matter if one or more people participate in a stage. Even if a ticket was not opened by a user, any problem identified, however small, should have a ticket opened internally, and not be fixed without being inside the method. This ensures that any and all changes made to the system are correctly documented both internally and for the public …
In practical terms, as for the Output Expressive Windows bug: even though no one has formally opened a ticket (which I highly doubt), in its launch post there were hundreds of bug reported in posts, from users hoping that this would be fixed as soon as possible, since it is a very useful tool, as I already said.
Now, it is sad to know that I may be stopping using this fixed tool for a long time, without knowing that it has been fixed, simply because no one has warned me that it has been fixed.
This is not right.
That’s fair, but that could be solved by an overarching story that all tickets related to that story are linked to. It shows that the integration with developer feedback isn’t as streamlined as it could be, and it doesn’t really feel like high hanging fruit to get this more integrated. It would just take someone to log and chase these issues down and make sure the result gets back to the developer, either via release notes or by a devforum response.
I’m not saying engineers need to be fully responsible for that though. Apologies if it came across that way.
I know this is late, but maybe the second argument could only accept integers. I don’t know much about floating point numbers but I think integers don’t have that problem of not being perfectly precise.
math.round(number / 4) * 4
would be the same as
math.round(number, 4)
but this
math.round(number, 0.1)
would print an error, because 0.1 is not an integer.
Having this is not completely necessary, but it would still be useful to have.
If that is added, then the name of the function doesn’t make sense. A round
function doesn’t sound like it should be multiplying something
This would:
- Be very surprising behavior, since every other basic math function in the math library is not restricted to integers.
- Not be very useful. Most grid snaps want to support any value, not just integers, and I can’t think of many things you would want this for other than snapping.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.