Nice productivity update,
A change that would increase the productivity of every scripter known to mankind would be being able to copy UDim2 /… values without the brackets.
For example, instead of copying the UDim2 value of {0,0}, {0,0}, it’d be copied as 0,0,0,0.
I am pretty sure everyone knows what I am talking about… Removing those annoying brackets when pasting into your code.
I cannot think of a reason why this shouldn’t be done, and if there is one, please make it a setting! 
A good QOL improvement thanks for doing. Wrong place but hey ho, add ability to right click and copy variable contents in the Watch window 
Oh! Not something that I expected, but well welcomed! Thanks!
Yeah, it’s doing this because it prioritizes treating it as a short-format hex code if the input is three hex digits, which 255 matches.
Do you think this needs a fix? If you want white you can currently type 1 or 255.0 instead of 255.
Okay, cool. I have a few.
UI Gaussian Blur
I’m sure this has been a question asked by many. But I must know, are there any plans of implementing regional blur to UI? Now of course, there are hacky ways to go about this by using a neon part or even using BlurEffect , but this does not achieve the same end goal. I know myself and others would be thrilled to have this added as it is a small effect that can greatly improve the UI visuals of games. Now of course, this does come at a cost of performance which is why I assume that it is not implemented; however, I would like to know if this is a feature going to be added, is being looked at, or just a straight up no.
Advanced Settings Options
This has been on my mind for a while lately, I also assume that this has been a thought at some point in time but I believe that it may need to be reintroduced with the new upcoming tech that is expanding the future of Roblox. Now, I understand, the goal is to allow for anyone to be able to play Roblox and this is why it is such a simpler solution that can prevent the need for more limitations on standard tech. The idea I am proposing is an Advanced Settings Options section onto the already existing settings menu. Currently, there is only an option to choose “Automatic” and “Manual” graphics options with a scale of 1-10. This is problematic in my opinion as it doesn’t go into any specifics. Now what if there were more customization that could better suit the device such as changing render distance, disabling blur effects, simple texture rendering, etc. I believe in adding this section it will eliminate the need to put harsh limitations on newly released tech, why make those with better hardware have to suffer because the new features were downscaled to suit all devices old and new? Do I think this will be added? probably not, however it would still be nice to see something similar like this that your team can think about implementing.
Part Culling
This is something that seems quite useful and it is used somewhat. Are there any plans to integrate the addition of a property under parts for developers to enable and disable part culling? There are times when an object needs to be hidden or when it needs to temporarily not exist in the space, however the only current solution is either to reparent the object, move the objects out into infinity, or delete them. An addition to this question if face culling, the ability to cull a face of an object with the enum properties.
but…
it would be nice to have automatically scaled uistrokes instead of having to code them in
Thanks for reading, I hope this can be read and recognized, ideas are fun to share. Have a great day!
If it’s intended, and many developers know (and expect) this, it may not need a fix.
It’s just different from Vector3s and other 3-digit constructors which is what threw me off.
A potential change, if needed, could be to make exceptions for 255 & 0. I expect lots more people to use those two shorthands for Color3s than any others.
Is it possible that UDim2 properties that are > 1 but have a decimal could be interpreted as scale? For example, “0, 1.05” should be interpreted as “0, 0, 1.05, 0”
I don’t know if this was already suggested, but it would be nice if there was a way for us to configure how properties interpret inputs using patterns.
For example: I want to input a shorthand Vector2 value of 4, 1, 2x4 and I expect 8, 2, 4. If I wanted to have this kind of shortcut, I would go to the studio settings and add a new shorthand value format.
Pattern: [\s]*([\d\.]+)[\s]*,[\s]*([\d\.]+)[\s]*,[\s]*([\d\.]+)[\s]*x[\s]*([\d\.]+) (X,Y,ZxS)
And for me to make this work, I will also need to give a bit of code which returns a Vector2 value. The code’s first returned argument is the deciding factor on what properties will support this format, and if the returned value has more than one possible value type then it either throw an error or becomes available to multiple value types, throwing an error if it returns a value not supported by the property.
local args = {...} -- '...' refers to pattern args. (1, 2, 3x4)
local x = tonumber(args[1])
local y = tonumber(args[2])
local z = tonumber(args[3])
assert(x and y and z, "Invalid Vector3 format.")
local v = Vector3.new(x,y,z)
local mult = tonumber(args[4])
assert(mult, "Invalid multiplier.")
return v * mult -- Always returns Vector3, so this is a Vector3-exclusive shorthand.
The pattern could be shortened to \*([\d\.]+) (*x) and use this code instead, treating self as the current value before the input. At second thought, it might be better to have a list of valid property types to toggle for a custom interpretation in the case a returned value is typed as “any” or you need to correct the interpretation’s interpreted type.
local mult = tonumber(({...})[1])
assert(mult, "Invalid multiplier.")
return self * mult
With custom interpretations, the sky’s the limit. We could really streamline things with this kind of freedom, and if there was ever a input-related problem exclusive to one person/group, that same person/group can implement the interpretation themselves!
As a UI Designer, I thank you
UDim2 property
0.5→{0.5, 0}, {0.5, 0}
You know what else will take about a day to implement, test, and never release?
… we shouldn’t have to manually assign every property like apes!
A table as input would go a long long way.
Current way we’re forced to construct:
The modern way we should be able to construct:
inb4 someone is like “hurr durr, you can just create a utility function”: That’s not the point.
That particular idea has gotten several rounds of discussion in the past. TL;DR: It doesn’t actually change the amount of code you have to write substantially and introduces additional potential for error so it hasn’t made the cut so far.
In the example for instance, sure, the current version is more characters, but it actually takes fewer keystrokes to type than the table version because the RaycastParams fields can code-complete vs the table fields cannot.
- UDim2 property
0.5→{0.5, 0}, {0.5, 0}
what if I would want to put 2 as the Scale?
- Color3 property
FFF→255, 255, 255
now this is really cool, but how about displaying color property in multiple formats such as Hex and HSV? I want this so badly
- any property, input
0→ zeroed out
apparently it is not limited to 0? you can type any non digit character and it will default to zero. expect that errors will be displayed in the output after doing so
Another idea on this from earlier in the thread which I’m considering is 2.0 → scale vs 2 → offset. For now you have to type the full value.
To single character variable enjoyers this would present itself to be a bullet proof counterargument; however the differences in character counts speak for themselves.
Character counts as per the above images (which are 95% of the time what people name vars for these datatypes):
Roblox™ way™:
Modern way:
Not to mention the improved readability. The Roblox™ way™ could never:
To code completion enjoyers (everyone) the raw character count is largely irrelevant. The modern way here would take significantly more keystrokes to type due to code completion not picking up the table fields. Not to mention it being more error prone since a misspelled field effectively gets silently discarded.
In a future where APIs can specify Luau table types for parameters / returns and code completion can pick that up we would probably revisit said modern way.
@tnavarts, before proof displaying the decreased character count: argues that the modern way doesn’t effect the amount of characters you have to write
@tnavarts, after proof displaying the decreased character count: argues that the amount of characters you have to write is now irrelevant
Alrighty then. 
HEX COLOR3 VALUES? REAL?
What I want to know is why the convertor defaults to filling all axises with the same number if I do x (x, x, x) instead of converting to x, 0, 0. Sure theres some UX reasoning behind this
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
We should be able to input stuff like 1/3 and 424+56 in number-only fields.