View Issue Details

IDProjectCategoryView StatusLast Update
0005226Multi Theft Auto : San AndreasClientpublic2018-09-03 18:00
ReporterMaccer Assigned To 
Status closedResolutionsuspended 
Summary0005226: getCursorPosition() 3D Positions Return Inaccurate, But Nearby Positions - Also Negative WorldZ

From debugging, I've found that the getCursorPosition doesn't work right when coming to 3D positions. I've found that a lot of these coordinates are near-by, but are still inaccurate. WorldZ is also negative and goes who knows where.

onClientClick can be used as reference since it works properly. I've also found several oddities in the getCursorPosition code:

1.) The lua declare returns as a double.
2.) The 2D resolution vectors are being treated as longs, which I suppose they should, but are listed as .fX and .fY in Hungarian notation. There are way other inconsistencies.
3.) -

Steps To Reproduce

If it helps, I'm in windowed mode, about to test in fullscreen.

TagsNo tags attached.



2010-03-04 04:59

viewer   ~~0011115

onClientCursorMove is also affected by the incorrect worldX, Y, Z params.


2010-03-24 16:35

administrator   ~~0011255

Last edited: 2010-03-24 16:36

The difference between onClientClick and getCursorPosition/onClientCursorMove is that onClientClick performs an additional line of sight check before returning the world x,y,z (If you click on the sky all three give the same x,y,z values)

We could add a line of sight check into getCursorPosition/onClientCursorMove, but that would cause additional overhead, especially for onClientCursorMove which is always processed every frame. Or the wiki could be changed. Perhaps to include an example of how to use processLineOfSight() with getCursorPosition/onClientCursorMove


2013-12-13 20:05

manager   ~~0019769

I experienced this very recently.

Added an "Issues" section to the wiki page for getCursorPosition()

Issue History

Date Modified Username Field Change