Allow UDim2 to perform math operations with Vector2

Feature Requests Engine Features
#1

Since Guis seem to interact a bit with Vector2, it would be handy if we could perform some math operations with them pixel-wise.

For instance:

UDim2.new(0,25,0,25) + Vector2.new(5,5) would return

UDim2.new(0,30,0,30)

Right now we usually have to do something like this:

local ud = UDim2.new(0,25,0,25)
local v2 = Vector2.new(5,5)
--
local result = ud + UDim2.new(0,v2.X,0,v2.Y)
7 Likes
#2

We’re upgrading Vector2 apis? Let’s also allow you to construct a Vector2 with a Vector3 and vice versa. I hate the nuance of having to switch between the two while using InputObjects.

2 Likes
#3

This assumes adding a Vector2 to a UDim2 should modify Offset as opposed to Scale, which is non-obvious.

What about UDim2:AddOffset(Vector2) and UDim2:AddScale(Vector2) methods?

7 Likes
#5

I would have to agree with this. If I asked you to add 10% to 100 what would the answer be, 110, 100.1 or perhaps even 111.1111? Methods are the solution here. You should always be explicit when converting data types.

#6

Agreed. For cases where one data type is frequently converted to another, it should be done clearly and explicitly through a constructor for the target data type, e.g.

UDim2.new(0,25,0,25) + UDim2.Vector2ToOffset(5,5)

and

Vector2.new() + Vector2.Vector3ToXY(vector3)

That would fine maybe for UDims, but when it comes to something like vectors, try Vector2.AddByVector3(), Vector2.SubtractByVector3(), Vector2.MultiplyByVector3(), etc. A constructor for a Vector2 from a Vector3 doesn’t require as many predefined API members, because you choose behavior with which operators you use.

3 Likes
#7

Maybe we could have a notation like vector3.xy as equivalent of Vector2.new(vector3.x, vector3.y) and something similar for the other way around

EDIT: might make a separate feature request for this

2 Likes
#8

Is this thread satire? Why is one method that solves multiple problems a bad thing:

ud2 + UDim2.new(0,v2.x,0,v2.y) -- Offset
ud2 - UDim2.new(0,v2.x,0,v2.y) -- Offset
ud2 + UDim2.new(v2.x,0,v2.y,0) -- Scale
ud2 - UDim2.new(v2.x,0,v2.y,0) -- Scale

v3 + Vector3.new(v2.x,v2.y,0) -- Whichever
v3 - Vector3.new(v2.x,0,v2.y) -- combination
v3 * Vector3.new(0,v2.x,v2.y) -- you
v3 / Vector3.new(v2.y,0,v2.x) -- need

What we don’t have but need is UDim2 multiplication and division.

6 Likes
#9

Because the two datatypes interact with one another with regards to guis, and it would be handy if they could just interact with one another without me having to generate a new LuaBridge to cast it over to that type. My suggestion was specific, I wasn’t asking for any of the other junk and conventions people are bringing up in this thread.

1 Like
#10

Would really appreciate this as a feature.

1 Like