ID:2459956
 
Resolved
Mouse hit detection has been substantially reworked to fix some bugs. In particular, when the mouse is over an object in vis_contents it should not treat the parent as the main icon, which it used to do, causing the icon-x/y offsets to be wrong.
BYOND Version:512
Operating System:Windows 7 Ultimate 64-bit
Web Browser:Chrome 73.0.3683.103
Applies to:Dream Seeker
Status: Resolved (512.1468)

This issue has been resolved.
Download the demo:

http://files.byondhome.com/Ter13/mousebugreport_src.zip

Mouse proc parameters show inaccurate icon-x and icon-y values when interacting with a scaled atom in the vis_contents of a parent atom with KEEP_TOGETHER set.

This does, however, bring up another issue:

This is an ideal way to handle mouse catching, scaling up an invisible object to cover a specific area for UIs. The problem with that is that icon-x and icon-y are exposed to the developer with the scaling factored out. Because of the rounding, there is no way to tell how many pixels from the bottom-left of the visual x,y of the object as rendered on screen the mouse was interacting with the object.

This makes accurate mouse interaction with scaled up objects impossible, and necessitates two new mouse params: vis-x and vis-y, which should report the number of pixels from the bottom-left of the visible area of the icon as rendered on screen the mouse is currently resting. This means that if I scale up a 32x32 icon 10x, the range of vis-x and vis-y should be between 1 and 320.

Feature request incoming.
Lummox JR resolved issue with message:
Mouse hit detection has been substantially reworked to fix some bugs. In particular, when the mouse is over an object in vis_contents it should not treat the parent as the main icon, which it used to do, causing the icon-x/y offsets to be wrong.
http://files.byondhome.com/Ter13/mousebugreport2_src.zip

This fix seems to have caused some issues with vis_contents inheriting unusual offsets when nested.

Run the demo, mouse over the blue square. Notice how the cursor appears 16px up and to the right of where it ought?

The issue does not appear to be present for children, but children of children.
There might be something more going on here, ss13 shows unreasonably high icon-y for everything with active plane master. I'll provide details when i find what exactly is causing this) Apparently it's just that. Any plane master increases icon-y.

/mob/verb/add_planemaster()
var/mob/X = new
X.screen_loc = "CENTER"
X.appearance_flags = PLANE_MASTER
usr.client.screen += X

Is enough to reproduce.
I'm looking at the mousebugreport2 project and the results look correct to me, based on how the coordinates work. vis-x/y of 1,1 is where the icon's lower left corner renders, but for the pixel_w/z offsets of the cursor to be correct, they'd have to take the difference between that and the original lower left corner into account.

Did I make a mistake on the choice of what vis-x/y means? Would it be better, do you think, for 1,1 to represent the lower left corner of the icon before its own transform?
In response to Anturke
Anturke, although the icon-y thing is a separate fix I basically just lumped it in with your report on transform affecting right-click menus.
In response to Lummox JR
Lummox JR wrote:
I'm looking at the mousebugreport2 project and the results look correct to me, based on how the coordinates work. vis-x/y of 1,1 is where the icon's lower left corner renders, but for the pixel_w/z offsets of the cursor to be correct, they'd have to take the difference between that and the original lower left corner into account.

Lum, the position of that cursor is wrong. It's 16px to the right and up of where it should be. I should not have to account for the src transform when adding the cursor to the blue square's vis_contents.