Allow arithmetic for certain objects that currently don't allow it

UDim2 - Allow * / by UDim2 or number
UDim - Allow * / by UDim or number
Color3 - Allow + - * / by Color3 or Number
Region3 - Allow + - * / by Region3 or Number ( Same for Region3int16 )
Rect - Allow + - * / by Rect or Number

If I missed anything let me know

8 Likes

Any UDim or UDim2 operation by number doesn’t work, since scale and offset use different coordinate systems.
e.g. UDim.new(0.5,180)/2 doesn’t make sense.

absolute(UDim) = absolute(scale,offset) = scale * parent + offset
absolute(UDim/2) = absolute(scale/2,offset/2) = (scale/2) * parent + offset/2 = (scale * parent + offset)/2 = absolute(UDim)/2

I’m not sure how useful it would be but it seems algebraically sound.

Component-wise certainly makes no sense though.

True, hadn’t thought of that

Right, what I meant was that they have different units. Rather, Scale is unitless, while Offset is in pixels. If they happened to require a transformation by the same amount, then it would be by coincidence.

1 Like

Actually, just had the thought that it could be used for making a GUI half the size of another GUI, etc, so not useless.

I don’t think that’s right, as I was trying to get at above. e.g. in this gif, the top button is {0.5, 180} wide and the two below are {0.25,90}. The two put together are always the same size as the top one, regardless of the parent size:

Show

http://imgur.com/e6FZ5zj

But if they aren’t parented, it will work correctly I believe?

Either way, I don’t think allowing multiplication or division would hurt anyone

By “parent” I mean “the containing GUI object if it exists, or the screen otherwise”. I just used a GUI object so the studio window could stay the same size while I was capturing, in case resizing would mess something up.

EDIT: NEVERMIND

I think we’re arguing over the same thing.

Your gif shows the two buttons half the size of the top one as expected which shows how /2 could be useful

The Scale component is given meaning once it’s applied to a GUI object (the value being a multiple of the parent’s absolute size). On its own, Scale is still unitless.

Your example works because the Scales of both bottom frames evaluate to the same amount, since they belong to the same parent. If you move one of the bottom frames to a different parent with a different size, their combined sizes will no longer equal the size of the top frame. If any one of the frames didn’t have a parent, then there would be no meaningful way to compare them at all.

these operations can all be implemented lua side by using metatables

The metatables of roblox types are locked

no, i meant in a way something similar to this http://wiki.roblox.com/index.php?title=Pure_Lua_Vector3_and_CFrame

Multiplication by integers is surely as natural as the addition of UDims is, because it follows the laws you would expect:

local position = UDim2.new(0, 0, 0, 0)
local skip = UDim2.new(0, 0, 0.1, 20)
for i = 1, #list do
	local size = UDim2.new(0.5, 10, 0.1, 20)
	makeGUI(position, size)
	position = position + skip
end

-- should be equivalent to...

local skip = UDim2.new(0, 0, 0.1, 20)
for i = 1, #list do
	local position = (i-1) * skip
	local size = UDim2.new(0.5, 10, 0.1, 20)
	makeGUI(position, size)
end

That is totally reasonable and desirable but is currently not doable.

2 Likes