Selection Hint and LookAt target privacy #4452
Conversation
|
/claim 4447 |
|
👀 We've notified the reward creators here. |
|
Thanks, @FelixWolf. Could you include some media (screenshots, video) in your PR? Would help us get an idea of what the preferences panel looks like without waiting for the test build / running the viewer! |
Of course! It'll be here shortly: https://youtu.be/rn6GL3CXXRQ |
| <key>EnableSelectionHints</key> | ||
| <map> | ||
| <key>Comment</key> | ||
| <string>Whether or not to send editing hints to animate the arm when editing an object.</string> |
There was a problem hiding this comment.
This probably needs to be a bit more clear about what 'editing hints' is.
There was a problem hiding this comment.
Would "Whether or not to send a particle beam and animate the arm when selecting a object" be more explanatory? Trying to figure out the best way to word it without it getting to wordy.
There was a problem hiding this comment.
Suggestion: Enable sending and visualizing curent selection using 'beam' particles and arm animation?
| //------------------------------------------------------------------------ | ||
| bool LLVOAvatarSelf::needsRenderBeam() | ||
| { | ||
| static LLCachedControl<bool> enable_selection_hints(gSavedSettings, "EnableSelectionHints", true); |
There was a problem hiding this comment.
This is going not only not send the beam to server, but also not render it locally, is it intended?
Also feels like it should be only for normal selection, not for grabbing. If person is dragging a physical object around, I would argue that source should be obvious to observers via selection beam (assuming it works like that currently).
There was a problem hiding this comment.
It was intended because I felt it should maintain consistency between what the resident who has the setting disabled sees and what everyone else sees, as inconsistency would cause confusion.
However as for the other part, My understanding was to disable all selection hints, including grabbing objects. I can modify it so that it only applies to the normal selection if that is desired.
There was a problem hiding this comment.
@kylelinden @bennettgoble What's your opinion on that? Should dragged physical object still display selection beam or should it be possible to hide as well?
There was a problem hiding this comment.
It should hide that as well. So, current implementation appears to be good.
| //------------------------------------------------------------------------ | ||
| bool LLVOAvatarSelf::needsRenderBeam() | ||
| { | ||
| static LLCachedControl<bool> enable_selection_hints(gSavedSettings, "EnableSelectionHints", true); |
There was a problem hiding this comment.
It should hide that as well. So, current implementation appears to be good.
5 participants
Description
Adds the ability to disable look at targets, as well as to clamp their distance around the head.
New settings:
EnableSelectionHints- Whether or not to send editing hints to animate the arm when editing an object.EnableLookAtTarget- Whether or not to send animate the avatar head and send look at hints when moving the cursor or focusing on objectsLimitLookAtTarget- Whether or not to clamp the look at targets around the avatar head before sendingLimitLookAtTargetDistance- Distance to limit look at target toNew preferences (Translations needed):
Test cases:
EnableSelectionHintsis disabledEnableLookAtTargetis disabledLimitLookAtTargetDistance(Default 2m) whenLimitLookAtTargetis enabledEnableSelectionHintsandEnableLookAtTargetare enabled by defaultLimitLookAtTargetDistanceis disabled by defaultVideo: https://youtu.be/rn6GL3CXXRQ
Related Issues
Issue Link: #4447
Additional Notes
The setting
LimitLookAtTargetDistancewas created just in case people have issues with their avatar. In my testing, 0.25m is too short and causes avatars to go cross eyed. 2m seems to be a sweet spot because it is the default, but gives those edge cases the ability to change this if it really needs to be changed.