Re: [opensource-dev] Review Request: STORM-1793 1) Treat all mini-map altitudes above 1020 m as the same height 2) Improve z-level accuracy
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/545/#review1166 --- Ship it! Ship It! - Oz Linden On Feb. 7, 2012, 6:28 a.m., Jonathan Yap wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/545/ --- (Updated Feb. 7, 2012, 6:28 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. The routine that returns who is nearby can be enhanced to scan the character list and use that position data. This gives an accurate z-level value, even when above 1020m. In the case where the relative Z value between you and another avatar is unknown display an X on the mini-map. This addresses bug STORM-1793. http://jira.secondlife.com/browse/STORM-1793 Diffs - doc/contributions.txt 0010858de5a1 indra/newview/llnetmap.cpp 0010858de5a1 indra/newview/llworld.cpp 0010858de5a1 indra/newview/llworldmapview.h 0010858de5a1 indra/newview/llworldmapview.cpp 0010858de5a1 Diff: http://codereview.secondlife.com/r/545/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
Re: [opensource-dev] Review Request: STORM-1793 1) Treat all mini-map altitudes above 1020 m as the same height 2) Improve z-level accuracy
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/545/ --- (Updated Feb. 7, 2012, 6:28 a.m.) Review request for Viewer. Changes --- Fix syntax error. Forgot to compile after making the last change. Dumb mistake. 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. The routine that returns who is nearby can be enhanced to scan the character list and use that position data. This gives an accurate z-level value, even when above 1020m. In the case where the relative Z value between you and another avatar is unknown display an X on the mini-map. This addresses bug STORM-1793. http://jira.secondlife.com/browse/STORM-1793 Diffs (updated) - doc/contributions.txt 0010858de5a1 indra/newview/llnetmap.cpp 0010858de5a1 indra/newview/llworld.cpp 0010858de5a1 indra/newview/llworldmapview.h 0010858de5a1 indra/newview/llworldmapview.cpp 0010858de5a1 Diff: http://codereview.secondlife.com/r/545/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
Re: [opensource-dev] Review Request: STORM-1793 1) Treat all mini-map altitudes above 1020 m as the same height 2) Improve z-level accuracy
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/545/#review1163 --- Ship it! indra/newview/llworld.cpp http://codereview.secondlife.com/r/545/#comment When wrapping conditions across lines, I find it more clear to put the operators on the left: if ( condition1 condition2 ... - Oz Linden On Feb. 3, 2012, 8:51 a.m., Jonathan Yap wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/545/ --- (Updated Feb. 3, 2012, 8:51 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. The routine that returns who is nearby can be enhanced to scan the character list and use that position data. This gives an accurate z-level value, even when above 1020m. In the case where the relative Z value between you and another avatar is unknown display an X on the mini-map. This addresses bug STORM-1793. http://jira.secondlife.com/browse/STORM-1793 Diffs - doc/contributions.txt 0010858de5a1 indra/newview/llnetmap.cpp 0010858de5a1 indra/newview/llworld.cpp 0010858de5a1 indra/newview/llworldmapview.h 0010858de5a1 indra/newview/llworldmapview.cpp 0010858de5a1 Diff: http://codereview.secondlife.com/r/545/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
Re: [opensource-dev] Review Request: STORM-1793 1) Treat all mini-map altitudes above 1020 m as the same height 2) Improve z-level accuracy
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/545/ --- (Updated Feb. 3, 2012, 6:05 a.m.) Review request for Viewer. Changes --- Fix bad assumption in getAvatars 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. The routine that returns who is nearby can be enhanced to scan the character list and use that position data. This gives an accurate z-level value, even when above 1020m. In the case where the relative Z value between you and another avatar is unknown display an X on the mini-map. This addresses bug STORM-1793. http://jira.secondlife.com/browse/STORM-1793 Diffs (updated) - doc/contributions.txt 0010858de5a1 indra/newview/llnetmap.cpp 0010858de5a1 indra/newview/llworld.cpp 0010858de5a1 indra/newview/llworldmapview.h 0010858de5a1 indra/newview/llworldmapview.cpp 0010858de5a1 Diff: http://codereview.secondlife.com/r/545/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
Re: [opensource-dev] Review Request: STORM-1793 1) Treat all mini-map altitudes above 1020 m as the same height 2) Improve z-level accuracy
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/545/ --- (Updated Feb. 3, 2012, 8:51 a.m.) Review request for Viewer. Changes --- Fixed another logic error in getAvatars. This code could be improved by changing one call into this method, so avatar_ids always has a matching positions parameter (which, erroneously, I thought it did). 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. The routine that returns who is nearby can be enhanced to scan the character list and use that position data. This gives an accurate z-level value, even when above 1020m. In the case where the relative Z value between you and another avatar is unknown display an X on the mini-map. This addresses bug STORM-1793. http://jira.secondlife.com/browse/STORM-1793 Diffs (updated) - doc/contributions.txt 0010858de5a1 indra/newview/llnetmap.cpp 0010858de5a1 indra/newview/llworld.cpp 0010858de5a1 indra/newview/llworldmapview.h 0010858de5a1 indra/newview/llworldmapview.cpp 0010858de5a1 Diff: http://codereview.secondlife.com/r/545/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
Re: [opensource-dev] Review Request: STORM-1793 1) Treat all mini-map altitudes above 1020 m as the same height 2) Improve z-level accuracy
Or you could as well make a new message, then alternate it with the current one. Eg. instead of sending CoarseLocation update every x (lets say 5 ) seconds,you send 0 - CoarseLocation 5 - CoarseLocationNew 10 - CoarseLocation 15 - CoarseLocationNew And so on. - Old clients would lose update precision. But not be broken. - New clients would use both messages and get X/Y updates at the same interval as today. For Z they could interpolate if the old message send an 'out of range'-Z value. Or just live with the lower Z update frequency. Both would still be vastly better than what we have now. - The amount of message the simulator has to send would not increase. Phase out the old message by reducing its frequency after a few month, then stop sending it at all. Whoever did not update their code by that time could be considered badly outdated. ___ 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
Re: [opensource-dev] Review Request: STORM-1793 1) Treat all mini-map altitudes above 1020 m as the same height 2) Improve z-level accuracy
Am Freitag, 27. Januar 2012, 14:40:01 schrieb Jonathan Yap: The SL simulator has recently been fixed so that the CoarseLocationUpdate message properly returns 255 for all altitudes above 1020 meters. Properly is a very ... unusual term for this kind of behavior. It still returns a wrong value, just a slightly more wrong one than before. Jonathan Yap Zi ___ 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
Re: [opensource-dev] Review Request: STORM-1793 1) Treat all mini-map altitudes above 1020 m as the same height 2) Improve z-level accuracy
A couple of questions Oz: 1. Would the client have a problem if another word was added to the message giving - duplicating the data, but allowing newer clients to choose to use the new word while older clients use the old byte? 2. Would the client have any problems if the CoarseLocationUpdate message was never sent? If not then that message could be deprecated, with a removal date set for some time in the future, while a new message that could handle much higher detail information was put in place and all newer clients were switched to it? I ask because this limitation of the message really puts a pinch in https://jira.secondlife.com/browse/VWR-27577. Ricky Cron Stardust On Fri, Jan 27, 2012 at 12:24 PM, Oz Linden (Scott Lawrence) o...@lindenlab.com wrote: On 2012-01-27 13:45 , Zi Ree wrote: Am Freitag, 27. Januar 2012, 14:40:01 schrieb Jonathan Yap: The SL simulator has recently been fixed so that the CoarseLocationUpdate message properly returns 255 for all altitudes above 1020 meters. Properly is a very ... unusual term for this kind of behavior. It still returns a wrong value, just a slightly more wrong one than before. 'wrong' is not really a relative term... The new value (255) is at least in the same direction for anyone under the maximum coarse location altitude, which removes some silly edge cases in which the reported altitude is rises until is suddenly becomes zero. In any event... this is the change that we've decided to make, and Jonathan appears to have done a good job of making the best of an admittedly awkward situation. Short of a major change to the coarse location messages (which would be completely incompatible with older viewers), I think this is the best that can be done. ___ 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 ___ 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
Re: [opensource-dev] Review Request: STORM-1793 1) Treat all mini-map altitudes above 1020 m as the same height 2) Improve z-level accuracy
Would the client have a problem if another word was added to the message giving - duplicating the data, but allowing newer clients to choose to use the new word while older clients use the old byte? Yes, because the coarseupdate packet holds many positions, it is not just 1 packet per avatar, but as many as can be packed into the coarseupdate packet as will fit. So it is not possible to alter this packets' format in any way. Doing so would break all existing viewers that expect it to have its current format. Would the client have any problems if the CoarseLocationUpdate message was never sent? Yes, with a small exception, you would not know where anyone is anymore. date set for some time in the future, while a new message that could handle much higher detail information was put in place and all newer clients were switched to it? This has been discussed several times at the server group meetings. Fixing this just to have a fully correct map display is more trouble than it is worth; having to run two packet formatters in parallel forever, having to query the viewer what packet format it wants, etc. is just not worth such a big effort. ___ 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
Re: [opensource-dev] Review Request: STORM-1793 1) Treat all mini-map altitudes above 1020 m as the same height 2) Improve z-level accuracy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/27/2012 3:37 PM, Jonathan Welch wrote: Would the client have a problem if another word was added to the message giving - duplicating the data, but allowing newer clients to choose to use the new word while older clients use the old byte? Yes, because the coarseupdate packet holds many positions, it is not just 1 packet per avatar, but as many as can be packed into the coarseupdate packet as will fit. So it is not possible to alter this packets' format in any way. Doing so would break all existing viewers that expect it to have its current format. Would the client have any problems if the CoarseLocationUpdate message was never sent? Yes, with a small exception, you would not know where anyone is anymore. date set for some time in the future, while a new message that could handle much higher detail information was put in place and all newer clients were switched to it? This has been discussed several times at the server group meetings. Fixing this just to have a fully correct map display is more trouble than it is worth; having to run two packet formatters in parallel forever, having to query the viewer what packet format it wants, etc. is just not worth such a big effort. I just wanted to add that the message containing all agents is only packed once per update, then sent in bulk to all agents. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPIzbGAAoJEIdLfPRu7qE2/lIIALVQq2mlITepS90gzriRFRPh BnFrnddJk7aD9J+SUtAw11FFqDqF+wGDX0l0Iu1oJqaPPtgjLweTXg0xNLzTOVIz /fdh1Nr711EdIoMZZFPWhpH/SP2lb7DwhZhmREONs2aAdlX1AKahaMclkbhJOFvY SGF1BAK5RrmewQFvgr96uiHJQaXwjo44DFpRWmeiCrCtCapPNu5U7Fz4iCGS7LxG kL6pSLBaDM7VcqkL3vHHALHeXgKLvLsEDqS36hwvTyNlWuqci7A1OZC6iKD2sNDz 03l7y8HnK9OWRcWhUxWoUbQM/ig33T1Ka0ZcuYESE1T9mB1ETlgKiyy3v9icmgo= =3c8S -END PGP SIGNATURE- ___ 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
Re: [opensource-dev] Review Request: STORM-1793 1) Treat all mini-map altitudes above 1020 m as the same height 2) Improve z-level accuracy
PS: I really want to be able to get rid of my lag-creating Sensor-based HUD for a pure client-side system. Hence my active commentary. The server team is not going to be making changes to the current system; they have said the cost of doing that, the additional load on the servers, etc. is not worth having more accurate z values. Much better for them to put their efforts on more important changes, etc. Now, given all that, the LL viewer is about to catch up to what the TPVs have been been doing for some time. It will use Z data for avatars near you, so if you are at 2,000m and someone is not too far away then your mini-map will show a proper height icon. The other part of that change will be to show an X if the relative height of you and someone else is not known (no more down pointing chevron for group of people standing around together at 2,000m). ___ 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
Re: [opensource-dev] Review Request: STORM-1793 1) Treat all mini-map altitudes above 1020 m as the same height 2) Improve z-level accuracy
How about reducing the vertical resolution of the packet by 4? ___ 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
Re: [opensource-dev] Review Request: STORM-1793 1) Treat all mini-map altitudes above 1020 m as the same height 2) Improve z-level accuracy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/27/2012 6:21 PM, Argent Stonecutter wrote: How about reducing the vertical resolution of the packet by 4? This was also brought up several times during the various discussions. It would break old/existing clients more than the current change, and the vertical resolution of 12m is a very significant height difference, agents could be on 2 or 3 different floors of a building and all report as being at the same level. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPI10SAAoJEIdLfPRu7qE2St8IAJOVYz59LYlbaD+w4jRNonKC qw9oP30TkNU25SUVVonm+9MF8X1jAv0a2m+laXDFReyBnVr8r55xXs7R7VEotc+k +0XThCYUxW61ildjekaUXz5fx1OefwX3Ds1kq0EOEmQ+XFq8Udkues18LNd77fTc rKRYfXr/2y64Y1x6Wj4c1DVbz559FeVPMzzDss+Va8wDFwrliPk06r/SOo/PrtWh BIhFik0icNlub8fHGZOIL/aLKTO14OSybazzuKW56pU8b56hHZV2kr3X4hXMRZxM ltRgNRjsFBnOGXPKMYS9x2r0ChNxOeTdoAFhRqdOfZA1INLi1wdfDDyD7aihPYU= =egRA -END PGP SIGNATURE- ___ 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
Re: [opensource-dev] Review Request: STORM-1793 1) Treat all mini-map altitudes above 1020 m as the same height 2) Improve z-level accuracy
Am Saturday 28 January 2012 00:37:44 schrieb Jonathan Welch: Yes, because the coarseupdate packet holds many positions, it is not just 1 packet per avatar, but as many as can be packed into the coarseupdate packet as will fit. So it is not possible to alter this packets' format in any way. Doing so would break all existing viewers that expect it to have its current format. Old viewers have all sorts of issues if their code isn't maintained anymore, most of them are way more important. Imagine the Z- byte transformation was made non-linear: that would still give better results than we have right now, be a small change to new viewers, have low impact on old viewers, and generate no extra network load. Example: (1*1 + 2*2 + 4*4 + 8*8 + 16*16 + 32*32 + 64*64 + 128*128)m = 21845m range. Armin ___ 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
