-
Notifications
You must be signed in to change notification settings - Fork 85
Selection Hint and LookAt target privacy #4452
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
c0f0619
f0cdcdc
b0541de
2165107
396a986
1679d76
241e6d1
1bfd011
a13b2fe
4c63bcf
0999287
b26eb64
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2830,6 +2830,12 @@ void LLVOAvatarSelf::setHoverOffset(const LLVector3& hover_offset, bool send_upd | |
//------------------------------------------------------------------------ | ||
bool LLVOAvatarSelf::needsRenderBeam() | ||
{ | ||
static LLCachedControl<bool> enable_selection_hints(gSavedSettings, "EnableSelectionHints", true); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It should hide that as well. So, current implementation appears to be good. |
||
if (!enable_selection_hints) | ||
{ | ||
return false; | ||
} | ||
|
||
LLTool *tool = LLToolMgr::getInstance()->getCurrentTool(); | ||
|
||
bool is_touching_or_grabbing = (tool == LLToolGrab::getInstance() && LLToolGrab::getInstance()->isEditing()); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This probably needs to be a bit more clear about what 'editing hints' is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion: Enable sending and visualizing curent selection using 'beam' particles and arm animation?