See the above bug report for an explanation of the problem.
While working with vis_contents to create user-interfaces, I have stumbled across an issue with icon-x and icon-y that has only become clear now that we can scale appearances.
There is no way to figure out exactly where the mouse is within a specific UI element in some cases without first calculating the pixel position of the lower-left corner of the UI element.
This is problematic, now that UI elements can be positioned according to LEFT,RIGHT,TOP,BOTTOM locations, as well as using percentage-based offsets.
Currently, the only accurate means of figuring out where the mouse is is via the screen-loc param. With a scaled up mouse-catcher object, icon-x and icon-y are the recommended local way to get the mouse position of the object, but the problem there is that icon-x and icon-y are rounded down to integer values. This destroys information that would help developers get the screen-size relative pixel offset of the mouse cursor of the atom as rendered.
The only way to solve this problem without backwards comparability problems is to expose a new mouse parameter vis-x and vis-y, which should give you the pixel offset from the rendered bottom-left corner of the object the mouse is currently interacting with.
Otherwise, getting this information requires parsing screen-loc, figuring out the client's screen and view size, and basically doing all the positioning math in softcode to work out exactly the bottom-left corner of the atom relative to the client's screen, and then subtracting that from the screen-loc parameter. The engine already has this information, as it uses it to calculate icon-x and icon-y. Let us use this information.
Apr 29, 12:39 am