Multi-value properties should autofill from low-input values

[overflowed]

As it currently stands, it’s slightly inconvenient to have to fully type/input values for properties that have multiple values.

It is most comparable to having to articulate full words with the absence of apostrophes/contractions.

In order to set certain properties, developers have to fully type out:
x0, x1, y0, y1 (or any other non-default UDim2/Rect value) when making UI elements
x, y, z when adjusting an object’s position, orientation, etc
r, g, b when adjusting an object’s color value

However, there is one behavior that serves as the basis for this feature request:

GuiObject.AnchorPoint is a Vector2 property that uses a single input to autofill the entire value. Using context clues, a Vector2 requires 2 values, but this property will use the single provided input as a default value for the subsequent values which are not provided.

… would result in the value autofilling to:

---

It would be great if multi-value/component properties were brought in-line with .AnchorPoint, where they use a low # of inputs to construct a proper value. This would streamline the more tedious parts of development, especially in the early stages where templates and more modular parts of the greater whole are being created.

Case for UDim2:

… would result in the value autofilling to:

additionally:

… would result in the value autofilling to:

Case for Vector3:

… would result in the value autofilling to:

[tnavarts]

Easy to implement and provides a lot of value. Great idea.

[tnavarts]

I implemented UDims as: 0.5 → {0.5, 0} and 10 → {0, 10}, with values <= 1 being interpreted as the scale part and values greater than 1 being interpreted as the offset part. Does that sound reasonable or would you pick a different value to differentiate? (2 or 3 maybe?)

[Maxwell_Edison]

Oh please please, the amount of time wasted by me writing a fully vector3 when I only need a single element is staggering.

[GamEditoPro]

I think even number higher than 1 should be interpreted as scale, because there’s a lot of situations, when I have 1 small square, and inside it I have another frame with size like (10, 0, 1, 0). Maybe, add smth like:
s3 = {3, 0},{3, 0} (s = scale)
o4 = {0, 4},{0, 4} (o = offset)?

[overflowed]

Oops I took a slight vacation from the forums.. sorry if it’s too late

I was thinking:

0, 10 → {0, 10}, {0, 10}
1, 0 → {1, 0}, {1, 0}
0.5 → {0.5, 0}, {0.5, 0}

So if a UDim2 was to be represented as a, b, c, d or {a, b}, {c, d}

b, if not provided, will default to 0
c, if not provided, will default to the value passed by a, or 0
d, if not provided, will default to the value passed by b, or 0

The best-case would be a UDim2.new(1, 0, 1, 0), where the raw input would be 1
The worst-case would be a UDim2.new(0, 0, 0, 1), where the raw input would be 0,0,0,1

The best way I could explain it is that the first 2 values that are passed serve as the basis/template/fallback for any non-provided values later on in the sequence of “real” values.. And the driving force behind me requesting the feature was that I was growing tired of typing .5,0,.5,0 (9 characters is sometimes way too much work) when inputting UDim2 values

However what I think matters more is the implementation of the feature being bigger-picture-friendly in regard to how Studio’s values behave under the hood, as well as what makes the most sense for devs

Personally I’d be happy with whatever you, the chef, choose to cook up

[tnavarts]

I did end up doing both but differentiated it:

• {0.5, 10} → {0.5, 10}, {0.5, 10} (or just {0.5, 10, works without the })
• 0.5, 10 → {0.5, 0}, {0, 10}
• 0.5, 0.6 → {0.5, 0}, {0.6, 0}
• 10, 20 → {0, 10}, {0, 20}

We did this after discussing and figuring that being able to fill in both X and Y is more valuable, because you’ll often want to say “make this full width and 10 pixels tall” or whatever, vs making something exactly square is rarer.

[overflowed]

Yeah that makes sense

Thanks a lot!