the script command "selectionPosition" will report "No point in selection (selection name)" in the .rpt file every time that it is run, even if the named selection exists in the chosen LOD, and the command returns its position.
Description
Description
Details
Details
- Severity
- Minor
- Resolution
- Open
- Reproducibility
- Always
- Operating System
- Windows 10 x64
- Category
- Scripting
Steps To Reproduce
Example selection is "", found via selectionNames.
run the following code:
_sel = (player selectionNames 1) #28;
player selectionPosition [_sel,1];
It should return a position array, but this seems to have no effect on whether it reports an error.
Check the .rpt file for the current session. There will be an entry:
"[time] No point in selection proxy:\a3\characters_f\proxies\weapon.001."
Additional Information
I discovered this issue while working on a mod that would create visible lasers using the new drawLaser command from 2.0.8. Because the lasers are positioned each frame using, in part, selectionPosition, this command is called a lot. I had observed a ~5-8 fps loss while the lasers were drawn, but assumed it was due to the drawing. However, the drop may be related to this excessive logging.
Related Objects
Related Objects
Event Timeline
Comment Actions
In case it helps, I was also encountering this issue back in 2.0.8, but I didn't get around to looking into its cause until after 2.10 dropped, so this bug is older than just this last patch.
Comment Actions
The selection does exist, it just doesn't have any points in it.
It's a selection in the model that has no vertices assigned to it, its empty, its invalid.
Thats what the error says, no points, and the error is correct, there are no points and the returned position is also 0,0,0
BUT, in your case you used a proxy.
Proxy has special case after this error is printed that will resolve the position.. uff
Comment Actions
Thats what the error says, no points, and the error is correct
Well you don't have to log everything. That's more important. When a command takes a few or even less than a microsecond you shouldn't log anything at all, because then suddenly that command takes hundreds of microseconds.
That's because you don't know how frequently something is gonna happen. It could be every frame. It could several times every frame.
Comment Actions
In my opinion, don't log anything for any command at all, and instead add a new command line arg for that, so only if someone's interested in debugging would get them in log.
Comment Actions
Late to the party, but it is really obvious that the selection doesn't exist when the return value is simply [0,0,0]. As Leopard20 said, it is really hard to justify this log spam in my opinion.