[sldev] [VIEWER] Re: New viewer released with logging of the owners of speaking objects and their location

[John Hurliman]

That would be much better, as you could send the packet to go from UUID 
-> RegionHandle and then RegionHandle ->  Name with a CAPS request.

Also to clear up the RegionHandle confusion, I like to think of it as a 
LocalID for simulators. Not a perfect analogy but it works. Each 
primitive on the grid has a UUID, and there is also a 32-bit integer 
called the LocalID that is used as a local index in the simulator that 
object is currently in. The RegionHandle is kind of like a local index 
in relation to the map, while the sim UUID is an absolute global 
identifier. The RegionHandle is also nice because the left-most four 
bytes encode the global X coordinate (multiply this by 256 and you have 
a global position of the simulator in meters) and the right-most four 
bytes encode the Y (again multiply by 256 to get a Y offset in meters). 
Use a shift to get the X coord and a mask to get the Y. So if you have 
the region handle of a simulator and a vector describing an offset like 
<25,175,50> you can convert that to an absolute global position which is 
used for things like auto-pilot. The X and Y could probably be encoded 
as shorts so a RegionHandle would only be 32 bits instead of 64 but the 
way it is set up now is near infinitely scalable and plays better with 
CPU alignment, and it is "Just The Way Things Are"*.

* That's mostly the answer I got when I asked why simulators don't just 
use prim UUIDs as local keys as well instead of creating this LocalID 
notion.

John Hurliman

Harold Brown wrote:
> That mapapi file will be going away in the future.
>  
> The replacement uses CAPS servers to do name to co-ordinate and 
> co-ordinate to name lookups
>
>  
> On 8/31/07, *John Hurliman* <jhurliman at wsu.edu 
> <mailto:jhurliman at wsu.edu>> wrote:
>
>     Dale Glass wrote:
>     > Here's the current plan (slightly updated):
>     >
>     > Viewer will ship with region_names.xml, which contains the info.
>     This will
>     > include the complete list of sims seen on the map. This
>     currently includes
>     > region name, key and handle. Entry will be included even if the
>     key couldn't
>     > be obtained.
>     >
>     > Viewer uses this for doing lookups. If it's an entry with a key,
>     no DB hits
>     > are needed. If it's an entry with no key (eg, region was down at
>     the time),
>     > then it will do a RegionHandleRequest and check if the handle
>     can be found in
>     > the file. This will be displayed as an uncertain result, as the
>     handle might
>     > have changed.
>     >
>     > Usage of the world map will also update the cache, which should
>     compensate.
>     >
>     > If that still doesn't work, it'll do a MapBlockRequest for the
>     whole grid, and
>     > use that to update all the listed handles. This will be limited
>     to one time
>     > per run.
>     >
>     > This, I think, is about as low of an impact I can manage to do
>     without some
>     > help from LL.
>     >
>     > A RegionNameRequest would save me the trouble of implementing
>     all this, as
>     > well as the DB impact. The file shipped with the viewer could be
>     kept, so the
>     > very rare cache miss (I'd expect more than 99% hits) would
>     result in a lookup
>     > of a single sim, instead of a huge MapBlockRequest.
>     >
>
>     It is either that, or grab http://secondlife.com/apps/mapapi/ and
>     parse
>     the second to last line to get an up to date, complete database of
>     handle to name mappings (and vice versa) that removes the need for all
>     of the other steps. In an ideal world the Lindens would implement
>     every
>     new packet we think of, but I've requested at least a half dozen over
>     the last year and have slowly become fond of finding ways to make
>     things
>     work without changing the grid backend.
>
>     John Hurliman
>     _______________________________________________
>     Click here to unsubscribe or manage your list subscription:
>     /index.html
>
>