Improvements to mapping and upgrade to SLurl.com

That's not a SLURL, but a secondlife:// URL. You need to tell Firefox how to handle the secondlife protocol. Check out http://www.linuxforums.org/forum/gaming-games-multimedia-entertainment/104105-how-firefox-calls-secondlife-slurls.html (and yes, this works for Windows, too, but you might need to change some paths as appropriate for your platform).

Shouldn't be hard, since the Pacific coast is on the Alaska current (COLD water, not the nearly bath-temperature oceans the Atlantic seaboard gets), not to mention the dirty diapers, broken bottles and exposed needles that seem to litter every beach remotely near population in California.

I'll second that. Even in places that are supposed to look like tropical ocean paradises like Seal Cove or Sunweaver Cove end up with a more calm Sauvie Island/Columbia River-on-a-midsummer's-day look to them at the coastlines.

I'd be curious what http://validator.w3.org/ has to say before drawing conclusions as to whether it's optimized for Firefox or if it's just IE being broken.

I'm almost certain Argent's on the right track and I have the right fix (setting firefox to call SL when it sees a secondlife: protocol URL). That should take care of it.

I'm afraid I don't agree. LL has been footing the bill, but it's an imaginary expense. (If you really are charging yourself 10L per upload, I would have to laugh)

This system could be continued in a modified form from how it's done now, which would not only reduce the overhead and perceived cost, but maintain a higher level of functionality than it currently has.

Many sims never change from month to month, and thus, neither do their tiles. It seems to me you could have your mapping process track which tiles are new, and which tiles are now defunct (you may already do this). Then delete old map textures which are no longer needed, and upload new ones that should now exist. The best part of this is, you don't have to do it with the same frequency as the new mapping system. A reduced frequency would be perfectly acceptable for the type of systems that use it.

As well, over time all tiles should be refreshed as they reach a certain shelf life, maybe after several months. This would keep the in-world texture map tiles relatively up to date.



An alternative is to give us real, honest-to-god HTML on a prim. That would work too.

Until you can show a webpage on a prim, this wouldn't help at all.

As a user of the subnova tile UUID service, no, I don't agree. I think the tiles need to be updated until availability of true html-on-prim, not merely as a media type.

In fact, that might be a good choice of project to take on next, with a built-in economic incentive to complete it.

So long as HTML on a prim is limited to pages hosted by Linden Labs, so it can't be used to implement web-bugs...

Now that would be just silly. Sites could (should) easily be able to detect it is the SL client (eg "User-Agent: SecondLife" so they can block access if they so choose. Honestly, I have been waiting 3 years for html-on-prim

There's a reason most email programs these days pop up a button saying "this message contains images to download from the web, click here to view them", and it's got nothing to do with bandwidth issues.

There has been at least one required update that was required because someone found a remote exploit for SL that could have been used by anyone who knew your IP address and when you were in SL. There are people actively using parcel media streams to build up databases of accounts and IP addresses to cross-reference them and identify alts. Letting people put web bugs on prims would have a devastating effect on privacy and security in SL.

Second Life lacking an effective way of putting maps on prims is a serious flaw.
I agree completely with Darien Caldwell, adding the maps as assets is an imaginary expense, and something that could be worked on to be made more effective.

HTML on a prim would be priceless. Linden Lab should eighter implement that, or (to compensate for this particular issue) at least add new functionality to LSL (key llRequestMap(string region) anyone?).

Now, I am not sure how the asset server works in its dark inner reaches, but wouldnt it be possible to re-use the same asset keys, so that the map texture for a SIM allways has the same key, even though the texture changes (i.e. just replace map.jpeg, dont replace the link pointing to map.jpeg)
Seeing as a SIM can handle 15000 prims as it is, I'm sure the asset server could handle one more key per sim.

Basing the key on a hash of the actual texture (or even a hash of a reduced precision version of the texture, so small changes don't force an update) would give you similar kinds of savings, without having to create a new class of modifiable assets.

Hmm true, I hadn't thought of that, but surely it could be togglable.

Or proxying for the truely parinoid.

Well hold on. UUIDs have a very precise specification that defines how they are generated and what they mean. It doesn't sound like a good idea to start screwing around with that.

Indeed, that sounds like a bigger change than what I suggested.

What I suggested the first time this came up is that HTML textures on an object would appear as a dummy texture until you right-clicked them, inspected the URL, and approved access, similar to the way many pop-up and ad-blockers work now.

Linden Labs does not follow that specification. A UUID in SL is simply a 128 bit random number.

This isn't a concern if they do it the proper way. The page is rendered on the server to a texture, and then sent to the viewer. Any such 'bug' would get the server's IP, not yours.

Of course this would prevent having interactive flash and such, but if you're worried about someone having your IP, i'm sure you would be even more worried about someone running something like flash or activeX which could do much more harm.

No, I wouldn't want flash on a prim, that's for sure.

ActiveX on a prim? Crikey, you might as well mainline smack through dirty needles.

Just update the image and leave the UUID alone, as it should've been to begin with. Being able to display map images via scripts is extraordinary useful.

Was thinking about that too but how would an object update the image when the map changes, if the UUID for a regions map never changed?

I guess whatever generates the maps (this isn't done on the sim itself any more?) would have to poke the asset server then that would percolate out to the sim texture caches and user caches so anybody who had an old version would know to re-download it.. Sounds like a fair amount of work!

/me wonders if there's any other use cases for such a thing. It'd almost be like a new asset type..

As I understand it, the client downloads textures as it encounters them. So the map would be updated client-side when you load it.

But if the texture is in the clients cache, it won't re-download it - that's what the cache is for! I believe the sims also have caches and clients connected to that sim ask the sim for stuff so all the clients aren't beating up the asset servers - the sim only has to get the image from the asset server if it doesn't already have it.

So... If they change the contents of the image back on the asset server, only people who don't have that UUID in their cache and are on a sim that doesn't have that UUID in its cache will get the new image.

LL may already have some mechanism to do this - I have no idea if it exists already or not. If they don't it might be a lot of work to add it.


Philip, can you (or anybody) please expand a little on what this means? Is this like the cost to add a new key/UUID to the database(s) or the cost of eating some storage space to keep the image or maybe the cost of just dropping 20-30k new images in there (regardless of if they overwrite old images as suggested above or create new ones) every time the map updates? Or maybe something else?

Hello everybody. Thanks for your feedback on the map system so far. I've got one more small update: I'm going to change the URL format for the map image tiles on Amazon S3 based on feedback that the 0 padding in the URL "subdirectories" is both limiting and silly. Tiles will be uploaded to S3 with new filenames starting early next week, probably Tuesday.

Old format:
http://map.secondlife.com/1/00997/01002/map-1-997-1002-objects.jpg

New format:
http://map.secondlife.com/map-1-997-1002-objects.jpg

This will make it easier to generate these URLs from programming languages that don't have native calls for sprintf(string, "%05d", grid_x), like Javascript and LSL. It also means we can keep the format for when the grid is > 99,999 regions wide.

Also, starting next week, the map tiles in the existing viewer will start to switch to the new appearance as is used on slurl.com. They will also download faster, as the new tiles are 16 KB versus about 60 KB for the old ones. (I switched us from OpenJPEG to Kakadu for our JPEG2000 library on the server side and eliminated an unused alpha channel -- the image quality is the same.) Finally, they will update more frequently, as Philip mentioned before. We're targeting having the whole map refresh about every 2 days.

James
[email]james@lindenlab.com[/email]