> On Feb. 3, 2011, 5:06 a.m., Oz Linden wrote: > > > > Kitty Barnett wrote: > Is there any reason to "fix" this in getAvatars() rather than just > "fixing" it when processing the CoarseLocationUpdate legacy region message > (and when processing the still unused cap)? > > The minimap for instance won't call getAvatars() but will rather access > the position directly so it would still be broken for nearby avatars when > >1000m. > > Additionally, if the plan is to still enable the http cap at some point > in the future then fixing the viewer's handling of that now would ideally > mean that the problem is fixed for everyone as soon as it's enabled rather > than having to wait another quarter for the next viewer release that contains > the fix.
Note that the final version of this patch that was tagged "ship it" was not what was in the merge in viewer-development, instead the first version was included. - Twisted ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/132/#review316 ----------------------------------------------------------- On Feb. 2, 2011, 3:39 p.m., Twisted Laws wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/132/ > ----------------------------------------------------------- > > (Updated Feb. 2, 2011, 3:39 p.m.) > > > Review request for Viewer. > > > Summary > ------- > > This modifies the getAvatars function in llworld to also include any avatars > that are found within the range from the LLCharactes list as well (the list > of avatars that is in the viewer object list). This should make sure that > anyone that you visually see within range shows up in the list. Note that > changing it in this function also affects > LLFloaterAvatarPicker::populateNearMe, LLLocalSpeakerMgr::updateSpeakerList, > as well as the LLPanelPeople::updateNearbyList that was originally mentioned > in the Jira. The region avatars lists only contain valid position data when > the avatars are below 1024m. The comment that mentions about retrieving > uuids is based on the function, not the current uses. No current calls in > the code are done with the avatar_ids argument NULL. Duplicates in the > returned list need to be suppressed. > > > This addresses bug VWR-17050. > http://jira.secondlife.com/browse/VWR-17050 > > > Diffs > ----- > > indra/newview/llworld.cpp ebd53632620a > > Diff: http://codereview.secondlife.com/r/132/diff > > > Testing > ------- > > Simple testing in sandboxes of this patch at 20m and 2000m heights with and > without avatars nearby. Tested with varying the NearMeRange to insure it > does not show avatars beyond the range. Testers need to understand that > RenderFarClip has an impact on the avatars that are actually in the viewer > object list, so setting NearMeRange to a great distance at high altitude > won't necessarily add avatars to the list. Basically if you can see the > avatar and its within NearMeRange, the avatar should be in the nearby avatar > list in the people panel. > > > Thanks, > > Twisted > >
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
