The AbsolutePosition of a GUI element measures the distance from the upper-left corner of the GUI canvas (I call it that for lack of a better word) (the space on the screen alloted for GUI that isn’t in ROBLOX’s special zone).
The coordinates returned by MouseButton1Down/Click/2/etc measures the distance from the upper-left corner of the screen, which is 36 pixels away from the origin of the GUI canvas.
How to fix: change MouseButton1Down/Click/2/etc to adjust its value to the GUI canvas origin, preferably with a general solution, that way any further changes to the GUI canvas don’t break things again.
ROBLOX: break as much stuff as possible every major update.
I want to nip this in the bud: I’ve already thought about subtracting 36 from it because hurr durr what do you take me for. This change has broken a few things and it’s kinda sloppy that it made it through.
I don’t like the terminology you used, and I was a bit confused at first because of that, so:
ScreenCanvas: Starts in upper left corner of screen
GuiCanvas: (Where GUIs start), 36 px down from the ScreenCanvas
MouseButton1 events not returning in terms of ScreenCanvas like AbsolutePosition and mouse,X/mouse.Y return. This used to happen with AbsolutePosition but ROBLOX fixed this and now AbsolutePosition is based off ScreenCanvas and not GuiCanvas. That same fix needs to be applied to the events of the mouse.
The real problem is that it’s a mixed bag: MB1Down returns in ScreenCanvas coords and AbsolutePos returns in GUICabvas coords. The expected behavior is that every gui element uses the GUICanvas as a reference and nothing uses ScreenCanvas as a reference. Unfortunately, some things were overlooked and there are some parts of the API that are still using ScreenCanvas which creates uncertainty, bugs, and work.
Reposting on this thread what I posted on the top bar thread here.
[quote] Here are some broken things:
MouseButton1Down (of class “GuiButton”) and DragStopped (of class “GuiObject”) pass the arguments (int x, int y). At the top of the screen, y is 36 (due to top bar) when it should be 0.
Your inventory (Backpack) is broken because it uses DragStopped, but it also uses DragBegin which for some reason passes a UDim2 instead of int x, int y like the rest of the functions… including it’s counterpart DragBegin which correctly returns 0 at the top of the screen. [/quote]
I would like to know what the future looks like for this. Will all x, y coordinates start from the bottom of the title bar (as they probably should)?
I’m being lazy, and I don’t want to fix my code knowing I’ll probably have to change it back in the future.
Using the mouse instance, I get seemingly random results when I continuously poll it with a while loop. By random, I mean it decides using whatever criteria it likes whether to give me coordinates based on the top of the title bar or the bottom. When I poll mouse.X and mouse.Y in a mouse.Move event, it’s consistent.
This is more easily detected in a Handles::MouseDrag event (in fact, that’s where I first noticed it), because the decision of whether to give me a bottom-of-title-bar coordinate or a top-of-title-bar coordinate is related to how recently the mouse has been moved.
Just wasted half an hour troubleshooting a seemingly flawless script because of this. Was also about to create a topic, but just barely found this one. Now I’m forced to avoid MouseButton1Down and Up just so that it doesn’t break in the future.
Please, either fix this issue, deprecate the arguments or at least point this out on the Developer Hub.