Shorthand Properties Panel Input

Updates Announcements
#83

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
#84

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.

#85

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.

#86

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.

#87

Nice catch, I will fix this case.

#88

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)

#89

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.

#90

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.

https://gyazo.com/8215259e6310017447bd9ea3703463d2

#91

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.

#92

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.

image

My naive assumption is to simply input the shorthand 4,1, but if you do that you end up with the following:

image

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.

#93

I actually have a solution for this, I’m going to make typing 2.0 / 2. → scale vs 2 → offset.

1 Like
#94

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 as 1/255 intead of 255.
  • Special case, don’t treat the specific input 255 as a hex code.
4 Likes
#95

You mean vector3?

#96

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).

#97

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
#98

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.

@sasial

1 Like
#99

How else should I not have the workspace destroy fallen parts?

1 Like
#100

First off, I’d like to know: Why exactly do you not want fallen parts removed?

#101

Adjustments which are live now:

  • Entering hex code colors with a # sign at the start works without throwing an error.

  • Negative values now work correctly for Color3, UDim and UDim2 properties.

  • A color like 234, 1, 1 will treat the ones as 1/255 not 255.

  • Numbers like 2.0 with a decimal point will always be treated as a scale value in UDim properties.

  • The specific value 255 is not treated as a short format hex code because the developer probably intended white instead.

3 Likes
#102

Is it intented to values like 100, 127, 254 (3 diffirent inputs, not single one) in color3 property be treated like HEX color code? Because some of them turn into normal colors (0 = 0, 0, 0; 255 = 255, 255, 255)