A proposal on how the map tile fetching could be implemented, I mentioned it during SUG meeting, here's a more detailed version.

First, a UUID has a version number:

6304242a-10c3-4b3c-a03a-cdc3e7ca12f0

in the 3rd group in this case, there are other versions too, but none of them use 0. We can take advantage of it. If we set UUID version to , we know that llGenerateKey() or any other UUID generation functions, will never return a UUID with in that spot.

Then, we can change the start bytes of the UUID to some fixed value, let's say - this will be our "This is a map tile" marker. In the future a similar UUID with starting value could be used for other features, like painted terrain or something, but I digress.

Then, we still have bytes leftover, so, the other bytes could be used to encode the map tile XY position.

So when llGetRegionWorldMapTile(x, y) is called, it returns the special UUID for those specific map coordinates.

Then, when that UUID is applied as a texture, the viewer sees the and the prefix and it knows "Oh, this is a special texture" and instead of fetching it from the CDN, it works similar to BoM, and fetches the texture from the Map Tile Asset Service, or wherever the tiles are stored. Also this way it would know that it is a special texture and that it should cache it for too long, as it could change in the future, once it encounters that UUID later, it just grabs a new map tile, just like BoM does.

Older viewers, that don't support map tiles, would just get "texture not found" from the CDN.

Since XY is encoded into the UUID, the special map tile UUID never changes for any map tile, but underlying texture can change, since the viewer would fetch it from a different source, which would always return the latest tile.

did you not realize we already had this before web on a prim and LL KILLED IT for web on a prim maps

Please keep it flexible for type of tile, e.g. terrain and object maps that exist. As well as open for future enhancements later down the road (for when we get infrastructure and other details highlighted like roads)

If at all possible, I'd love if it could zoom down to the level of centering a parcel on the map, if you provide such a parameter. =) Perhaps it can be done by having the function not return a UUID, but a list -with- the UUID and parameters needed for zooming in on a given parcel.

It would be good if it followed the current map texture API format so maybe its a string of the map texture UUID :

This adds the full range of zoom levels that the in-world map already uses, and also it would be really compatible for updating stuff people already did with MOAP in the hacky and unfun way :D

Speaking as someone that keeps having to update products due to external servers changing, this really should be a native thing in SL and not rely on third parties. Especially because the data is already on the servers- there's no reason not to expose it to LSL.

It would be nice to have the ability to get the tile uuid by grid coordinate - ie so you don't have to look up the name of the neighboring region to display its map tile, which is an additional api call.

Need to be able to get the texture by grid coordinate instead of just by the string name.

See also https://feedback.secondlife.com/scripting-features/p/llgetregionworldmaptile which is marked