Descriptive Problem Summary:

When using a scaled up atom in the screen, the visual bounds for mouse picking appear to be inaccurate.

A test demo has been attached. It generates 100 randomly sized boxes in the client's screen. When one is hovered, its alpha value is increased to 255. Check the message log for bug messages showing when the mouse is outside of the object's bounds according to where I've calculated the extents should be.

I am pretty certain my math is correct.

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

In addition, there's an interesting oversight in how MouseDrag(), MouseMove(), etc. are called that's been exposed by the 500 series features. When moving a mouse over a scaled up sprite, MouseDrag()/MouseMove() are called less frequently than they would be with a larger sprite.

I believe that this is because the client is determining when it should send that information by using the calculated icon-x and icon-y values of the object under the mouse to check whether or not it should send those hooks.

This can cause some interesting problems when using a small-ish icon that's been scaled up to function as a catch-all for the client's mouse movement.

I would recommend instead that the client uses the screen-loc instead of icon-x to calculate when to send these calls, as that calculated value is no longer necessarily accurate enough thanks to the inclusion of matrices in the language.