This makes no sense, and has been pestering me for an entire YEAR. Modifying a GUI’s size should not also change the GUI’s position–however, what’s confusing me is how the position property itself never changes; but the AbsolutePosition property does.
To me, it appears like it has something to do with the AnchorPoint and Rotation properties working against each other. Any ideas or workarounds?
Repro: f.rbxl (20.0 KB)
Just press F5 and watch. The script only changes the size of the Frame.
Steps for Reproduction
Step 1: Create a frame that is rotated. Anchor point doesn’t matter.
Step 2: Change the size of the frame. This can be more noticeable through tweening since you can gradually see the frame move; however it does not matter if you do it through script or through properties. It also does not matter if the X or Y scale is changed.
Step 3: Observe.
Thanks! So the reason the AbsolutePosition changes here is because AbsolutePosition always refers to the position of the top-left corner of the frame. This is due to some backwards compatibility concerns (for a long time on Roblox we did not have AnchorPoint, it was hard-coded to (0,0)). So basically, you’ll always see the AbsolutePosition Change if you are changing size or rotation. We could add another property for AnchorPointAbsolutePosition or something like this if there is a good use case for this.
So the GuiObjects move when resized because of backwards compatibility concerns? That’s a bummer–i’m assuming that means that would make a implementing a patch quite a bit harder. Honestly, I’m okay with any fix as long as I can resize a frame without it shifting hundreds of pixels :0
technically they always “move” from the upper left hand corner, if your anchor point is set differently. It is really all about your frame of reference here to determine if something has moved. It might be useful for us to introduce an anchor point absolute position, but I’d like to know what sort of use case you have for this in general.