[opensource-dev] Review Request: STORM-1793 1) Treat all mini-map altitudes above 1020 m as the same height 2) Improve z-level accuracy

Ricky kf6kjg at gmail.com
Fri Jan 27 16:14:13 PST 2012


It just means that having a proper clientside radar system is now truly
stuck.

And I did mean a finite time period for the deprecation: I agree that such
things are unmaintainable in the long term.  However the current state of
affairs isn't viable for long either, so a plan has to be readied.

Kadah's note also shows that it is something that is not able to change
per-viewer, so the only viable route is the deprecation model: for a period
of time, say one year, the old message AND the new message are sent to all
clients.  The older clients should discard any message they don't
recognize, in this case the new message, while the newer clients will
discard the older message for the same reason.  After
the deprecation period is over the old message code is purged leaving only
the new message and anyone who is running an un-updated client simply no
long can tell altitude differences in the minimap.

As to the format, one byte is not great, but now I at least understand why
it was chosen: maximum data density.  Currently the message uses absolute
coordinates interpreted linearly across the space in the range [0, 255] * 4
meters.  This worked when the region was only 1024m high.  Here is another
idea, trying to keep in what I think was the original spirit of the
message: switch to using dynamic scale.  Use the existing packet format,
therefore keeping the bulk of the code the same, but have the client and
the server agree that the scale value, currently set at 4 meters per
message unit, is to be computed from the size of the region.  This would
mean that old-school 1024-meter-high regions would have the calculation for
the scalar as so: 1024 / 255 = 4, resulting in the current value that
worked so well for those regions. (Yes, I know such regions no longer
exist.) Current regions would have the scalar calculated as 4096 / 255 =
16.  Future regions with even higher ceilings would just continue that
idea, resulting in the message's number being more like a percentage.  Just
make sure that this math is done for X and Y as well - not just Z.
 Otherwise we are right back here again if in the future estates can choose
to have a different region size than other estates...  (And yes it could be
done.  A LOT of work, but it could be done.)

Ricky
Cron Stardust

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.

On Fri, Jan 27, 2012 at 3:37 PM, Jonathan Welch <jhwelch at gmail.com> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20120127/ab6268a5/attachment-0001.htm 


More information about the opensource-dev mailing list