Simply put, it seemed like the more useful behavior. (x, 0, 0) is rarely a useful value but (x, x, x) often is (for sizes, max forces / torques, etc).
Let us create objects in multiple selections
2 Likes
We should be able to input stuff like 1/3 and 424+56 in number-only fields.
3 Likes
I’ve had moments when I just wanted to perform a basic math operation to a number property, but the input field only allows numbers. It’s pretty annoying, so it’d be a big relief for this to no longer be a problem.
3 Likes
Can we please, please have support for HEX color codes directly in the properties panel? This would improve the workflow of so many interface designers, we wouldn’t have to open the color panel in order to paste those in.
If this’s true, then please, Please, PLEASE, fix bug with shortcut (F10, Shift+F10) that changes graphics quality. I use it instead of slider, bc it much faster for me, and it shows incorrect value in popup, like 1 further than actual. So, when I go from 2 to 3 level, I’ll see 4 instead. If I’ll go from 4 to 3, I’ll see 1 instead, and if they go out of limit, popup won’t show at all.
It’s probably just 1 small mistake with ± 1 somewhere, and shouldn’t be very big problem to fix, but this will help me alot, because now I need open menu → settings almost every time to check actual graphics level, or set it to 1 via spamming Shift+F10 and then go to wanted one.
If you input an RGB color like 84, 1, 200 then you’ll receive 84, 255, 200. It shouldn’t be confusing RGB with Color3 decimal values.
Nice catch, I will fix this case.
Hm… Here comes problem of colors like 0, 0, 0 and 1, 1, 1… This can be interpreted like 255, 255, 255
(I noted 0 here, because of: 1, 0, 1, so they both can exist in single Color3 value)
I’m not to worried about it. There’s a pretty easy fix here of only treating the inputs as a 0-1 float if all of them are in that range. If you happen to need exactly the value (1, 0, 0) you can always enter it in the color picker so you’re not going to be blocked.
Not sure if this is that important but inputs from [-1, -255] are still by the [-1, 0] / [0, 1] scale. Was trying to get inverted color correction and inputting -255, -255, -255 just makes it -65205… Although manually setting negative numbers is a pretty rare occurrence, still thought it would apply this way too.
Yeah, that’s also a bug, I’ll fix it. Though I’m also pretty sure negative colors are not officially supported anywhere in the engine, so continue using that pattern at your peril.
I ran into a little ‘oh’ moment when I tried using this feature on UI elements. I understand my particular use-case may be a tricky scenario to solve, but I figured I might as well mention it.
I frequently create UI buttons with SizeConstraint set to RelativeYY and then the Size would be something like X, 0, 1, 0 where X > 1 to create a horizontal button that fills its vertical space while maintaining its proportions.
I.e. something like this button here, which has a lot of space on its left and right but is limited in the vertical space it can fill.
My naive assumption is to simply input the shorthand 4,1, but if you do that you end up with the following:
My expectation was that it would convert the input to {4, 0},{1, 0}. Though I also understand why the current behavior might be desirable.
I actually have a solution for this, I’m going to make typing 2.0 / 2. → scale vs 2 → offset.
1 Like
Fixes / changes slated for next week’s release:
- Handle negative color inputs and negative UDim offsets correctly.
- Treat any number with a decimal point in a UDim input as a scale.
- No error thrown when inputting a hex code with a # like
#FAB - If any of the components of a Color3 are greater than
1, treat components exactly equal to 1 as1/255intead of255. - Special case, don’t treat the specific input
255as a hex code.
4 Likes
You mean vector3?
Do you plan to add anything in regards to inputting inf and NaN (0/0) values? I want to set SurfaceGUI’s max distance to inf (legacy behavior for legacy UI) and workspace.FallenPartsDestoryHeight to NaN (as 0/0).
Maybe but that one is a little bit more contentious because there’s no APIs which officially support NaNs as an valid input value so we don’t know if we want to make the hacks involving NaN any easier.
1 Like
Explicit support for NaN as an input will only result in the egregious misinterpretation of the implicit ‘support’ it has in the sense that it’s technically a valid number value.
1 Like
How else should I not have the workspace destroy fallen parts?
1 Like