----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/534/#review1141 -----------------------------------------------------------
In a number of ways this change is a step backwards and should be rejected / revisited. 1) Ambiguity. Previously, when an agent was "out of resolution" they were reported as 0m. This has the advantage of being an improbable edge value and easy for the viewer to detect and interpret as "out of resolution". However, this new proposed change would mark a user in the "out of resolution" state as 255, which translates to much more plausible value of ~1020m altitude. Agents are much more likely to be naturally at this altitude! Because of this change, it's much harder for the viewer to correctly determine that the reported value is out of resolution, or if the detected agent is actually at ~1020m. 2) Efficiency. I am not sure how aware LL is of the tremendous inefficiency the limited z axis range causes gridwide. More than 2/3rds of ALL SL GRID USERS are now using LSL-based "radar" systems to either feed viewers correct z heights or display the correct heights directly via a HUD. Not only is the overhead associated with transmitting this information every scan interval via LSL staggering, but it means that the original 8bit z axis field is largely being largely wasted. By increasing the resolution of the z-axis field provided directly to the viewer, LL would be saving enormous amounts of overhead and bandwidth by obsoleting LSL-based systems. Continuing to ignore this is penny wise, pound foolish. - Arrehn Oberlander On Jan. 16, 2012, 5:12 a.m., Jonathan Yap wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://codereview.secondlife.com/r/534/ > ----------------------------------------------------------- > > (Updated Jan. 16, 2012, 5:12 a.m.) > > > Review request for Viewer. > > > Description > ------- > > The SL simulator has recently been fixed so that the CoarseLocationUpdate > message properly returns 255 for all altitudes above 1020 meters. > > The code for the mini-map, in drawing the agent locations for equal, above or > below needs to take this into account. It currently does not. > > LLNetMap::globalPosToView() computes a relative position: > > LLVector3d relative_pos_global = global_pos - > gAgentCamera.getCameraPositionGlobal(); > > The Z value needs to take the global camera pos, and slam anything above 1020 > to be 1020, and all our problems will be solved. > > Also, new artwork, an X, needs to be displayed for the case of avatar B and > your camera position being at or above 1020m, where the relative height > positions are unknown. > > > This addresses bug STORM-1793. > http://jira.secondlife.com/browse/STORM-1793 > > > Diffs > ----- > > doc/contributions.txt 4982ab91ef6a > indra/newview/llnetmap.cpp 4982ab91ef6a > indra/newview/llworldmapview.h 4982ab91ef6a > indra/newview/llworldmapview.cpp 4982ab91ef6a > indra/newview/skins/default/textures/map_avatar_unknown_32.tga 4982ab91ef6a > > Diff: http://codereview.secondlife.com/r/534/diff/diff > > > Testing > ------- > > See test plan in jira > > > Thanks, > > Jonathan Yap > >
_______________________________________________ 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
