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.
ID:2459956
Apr 29 2019, 12:28 am
|
|||||||||||||
Resolved
| |||||||||||||
May 22 2019, 12:24 pm
|
|
Lummox JR resolved issue with message:
|
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.
/mob/verb/add_planemaster() 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. |