Secondlife 15th anniversary and CEO's letter

[Phil Deakins]

Yes. llName2Key() would solve all the problems for existing scripts that are coming with name changes. It's the ability to get a key from a name that's needed. If we get that, then adding an avatar to a security system, and other such things, by typing its name in, will work just fine once the scripts have been updated.

It's beyond my comprehension why LL would choose to create an API for the job instead of llName2Key() when llName2Key() is what's needed. They are probably thinking of producing an API that includes more functionality than just name2key, and that's fine, but add llName2Key() to LSL as well.

Edited March 26, 2018 by Phil Deakins

[Qie Niangao]

I suppose there are untold ways the Lab could screw this up, but I'm not much worried about what they'll end up doing with scripts, even though we don't know yet what precisely that will be.

Incidentally, the third-party database for name-to-key is pretty complete, although new residents can escape indexing for a while if they're very good at hermit role-play. And anyway at present, a security script can get along without any name-to-key at all, even if they use names to specify which avatars are of interest, because the inverse function, llKey2Name(), works fine for avatars in the region at the time its called, so it can readily check if any keys it encounters match the names for which it's supposed to be checking, and for efficiency can build up a little cache of keys it encounters often.

I'll pretty much bet that llKey2Name() will continue to fetch-up the legacy name, which is the same name it has returned since before there were display names, and that name changes will never affect those legacy names. If they do, then it would be time to worry because a whole lot of content will break.

(As to the "API" instead of a function called llName2Key() -- such a function would be an "API"... but they may want to avoid forcing a script to wait while they search some identity database, much as they implemented an asynchronous llRequestDisplayName() for identities outside the region, and a llGetDisplayName() for identities that could be found in the region without a database search.)

[greek Wingtips]

Can someone post the URL link to the CEO letter

[Phil Deakins]

The URL is in the second post of this thread.

[Phil Deakins]

@Qie Niangao

Allegory Malaprop decribed why 3rd party databases are unreliable and, imo, there is no good reason why a scripter should write scripts that rely on non-LL systems being kept up to date, and accurate, to work properly. It's something that I won't do.

Perhaps, by "API" LL meant what you described, so why not call it a function, or set of functions, incorporated into LSL? That, I'd be happy with. I hadn't actually thought of an API as merely a set of functions in a programming language, so perhaps I've misjudged what they meant.

[Phil Deakins]

28 minutes ago, Qie Niangao said:

And anyway at present, a security script can get along without any name-to-key at all, even if they use names to specify which avatars are of interest, because the inverse function, llKey2Name(), works fine for avatars in the region at the time its called, so it can readily check if any keys it encounters match the names for which it's supposed to be checking, and for efficiency can build up a little cache of keys it encounters often.

Yes, of course. The keywords there are "at present". The present isn't the problem

[Qie Niangao]

29 minutes ago, Phil Deakins said:

Allegory Malaprop decribed why 3rd party databases are unreliable and, imo, there is no good reason why a scripter should write scripts that rely on non-LL systems being kept up to date, and accurate, to work properly.

I certainly don't disagree with that, but this is hardly the only occasion we've had to rely on third parties when the Lab has failed or refused to expand the "surface" of the language interface to the simulator. Group-invite bots are an even kludgier example of that.

Also, regarding the "API" beyond LSL functions, the post following the one linked explains that they're also planning a http-accessible link for use by external programs. That's fine and all, but to me it seems a bit ass-backwards to provide a relatively inconsequential convenience to external programs while continuing to starve in-world scripts of necessary functionality.

[Allegory Malaprop]

55 minutes ago, Qie Niangao said:

I'll pretty much bet that llKey2Name() will continue to fetch-up the legacy name, which is the same name it has returned since before there were display names, and that name changes will never affect those legacy names. If they do, then it would be time to worry because a whole lot of content will break.

So, you're suggesting that they will add a fifth avatar id type?  UUID, Firstname Lastname, firstname.lastname, DisplayName, and Newname Newname?  That would prevent script breakage- but considering they've been advocating already switching to using data to identify OTHER than Firstname Lastname even though the tools to get the UUID do not even officially exist yet and it significantly more robust all around in what you can currently do than with firstname.lastname, I have not gotten that impression.

(I don't use Name2Key for any "security" that involves people ever being present.  I need to send things to people not present on the same sim, who I have never met, and have only been given names of, on a semi regular basis- so I use the hacks, and it tells me when it fails and I need to fix the significantly smaller number by hand.  It is a very small number, but it's also all around not something I really trust at all.)

[Phil Deakins]

Just a quickie about my confusion with LL's use of "API".

To me, an API has always been an extra that you download for a particular purpose. APIs are extras to programming languages. They are not part of the standard programming languages. llName2Key() would become part of the standard LSL language. Each function, or group of functions may be an API at their end but not at mine. That accounts for my misunderstanding over what I consider to be a misuse of "API" - misuse because the API is at their end and not mine

Now I'm off out for a little while.

Edited March 26, 2018 by Phil Deakins

[Callum Meriman]

It could just be that the term API is being used in a different manner to what we would expect. Maybe 1 or 2 new functions will be added to LSL provide an API for us.

key llName2Key(string first [, string last]);
list llKey2NameHistory(key uuid);

What else do we need, I wonder?

[Qie Niangao]

55 minutes ago, Allegory Malaprop said:

So, you're suggesting that they will add a fifth avatar id type?  UUID, Firstname Lastname, firstname.lastname, DisplayName, and Newname Newname? 

Yes, that is what I expect, but you're right, they haven't said anything to support that expectation.

Right now we're focusing on what happens with scripts, but there's a host of other complications. Take, for example, this very forum we're using now. What's supposed to happen to existing posts when an avatar takes on a new name? If somebody references my current name in the text of a post, will that still be recognizable if my forums username updates to my new choice of name? How's all that gonna work?

[Phil Deakins]

The simplest solution to that, Qie is to simply ban you from the forum - all names

I had a thought after I'd turned the computer off. Maybe they'll include the LSL additions in a high level Premium account, so that you have to pay for them by upping your Premium level, which would be more in keeping with what I think of as an API

[Allegory Malaprop]

10 hours ago, Qie Niangao said:

Right now we're focusing on what happens with scripts, but there's a host of other complications. Take, for example, this very forum we're using now. What's supposed to happen to existing posts when an avatar takes on a new name? If somebody references my current name in the text of a post, will that still be recognizable if my forums username updates to my new choice of name? How's all that gonna work?

Scripting is my LEAST concern over the name change.  It's going to break things for people, but no one was using names in scripts because they WANTED to, they've never been a good choice.  I brought it up because it's just another thing that will break, and it's just another way in which people will be inconvenienced- another way end users, who don't even know all the stuff going on behind the scenes, are going to have problems.  (And because they have outright told people not to use names in scripting anymore, but to use UUIDs instead, while official necessary functions do not currently, and have never existed- people haven't been not doing it because they are lazy or bad coders.)

Names have been human readable unique persistent ID- in other words, I see your name, I know who you are.  UUIDs are machine ID, nobody will remember that, use that, identify that, we aren't wired that way.  I can barely remember a phone number- UUIDs are longer, have more variables, and less reason to enter in manually over and over and over and over until it gets ground into your memory.

As I mentioned before- I make things.  I sell things.  I have years and years of records with history of what I've sold, to who, provided by LL themselves.  Entirely by name and not UUID.  THAT is my number 1 primary "I will have to go through at least one extremely inconvenient way of fixing this" problem.  "This will still cause me headaches for forever" problem.  I will need to fix years of transaction records into a format that lets me actually access any relevant data, that I straight up need to access on a regular basis.

Additionally, human readable unique ID (names, the entire reason they have always used names) means I can see things.  I can identify what is actually going on in my transaction records significantly easier at a glance, instead of having to compare long string of nonsense code to long string of nonsense code.

Edited March 26, 2018 by Allegory Malaprop
whoops forgot a "not"

[Penny Patton]

13 hours ago, Qie Niangao said:

I suppose there are untold ways the Lab could screw this up

I feel that way about everything LL is promising in this letter but on the other hand I'm just happy that LL is showing genuine interest in addressing issues that have been problems/features people have wanted since SL's inception. Problems/features LL has in the past dismissed as not worth their time. It really makes me feel like there's been a change of attitude behind the scenes (maybe new people in charge of SL development replacing those who were moved to Sansar? Some of these improvements have undoubtedly been in development for a while if LL is announcing them) and gives me a glimmer of hope that SL might actually have a brighter future than I would have expected until now.

It all really depends on how LL follows through in delivering these SL improvements and goes forward from there. Even if they mess up some of these, I'm guessing we'll all get something that makes our SL experience at least a little better. I'm already enjoying the increased tier and that's far more than I expected to get. There's some less glamorous improvements coming that I know of which aren't included in this announcement but will undoubtedly lead to a better SL experience as well.

[animats]

With all this name changing, we're going to need an LSL function which takes a user name and returns the avatar key. Security orbs, access lists, leader boards, etc. now all need to be organized by key, and any that currently have names stored need to run those names through a lookup and get keys.

Probably an async dataserver request.

[Allegory Malaprop]

13 minutes ago, Penny Patton said:

...Even if they mess up some of these, I'm guessing we'll all get something that makes our SL experience at least a little better. I'm already enjoying the increased tier and that's far more than I expected to get. There's some less glamorous improvements coming that I know of which aren't included in this announcement but will undoubtedly lead to a better SL experience as well.

The land impact and tier bonuses we've already been getting have been welcome, and lovely.  Baked on mesh is amazing and incredible and makes me so happy I can't even articulate.  Appliers and layers are an awful messy resource intensive hack.  They aren't particularly user friendly, and they are horribly creator unfriendly.  A lot of the other stuff is nice (we're going to hope in execution as well as theory!), but that one is a thing of absolute beauty that will improve experiences all over.

[Penny Patton]

1 hour ago, Allegory Malaprop said:

The land impact and tier bonuses we've already been getting have been welcome, and lovely.  Baked on mesh is amazing and incredible and makes me so happy I can't even articulate.  Appliers and layers are an awful messy resource intensive hack.  They aren't particularly user friendly, and they are horribly creator unfriendly.  A lot of the other stuff is nice (we're going to hope in execution as well as theory!), but that one is a thing of absolute beauty that will improve experiences all over.

Unfortunately, "Baked on Mesh" is one thing I'm convinced they've already screwed up. Appliers and onion skin avatars aren't going anywhere. It will be fine for skins, tattoos and makeup, but layer clothing will still be applier based, requiring the onion skin body design. Since most body creators are a paranoid, superstitious lot who don't understand how basic SL functions work, they continue to release their products no-mod, which means we'll all still suffer the performance hit from most SL users wearing the equivalent of 3-4 high-poly bodies simultaneously even as fewer and fewer people use layer based clothing.

All because baked on mesh won't support materials.

Still, more tier and parcel windlight controls are both difficult to screw up. Gridwide experiences should be great even if they fail to be as good as some of us hope they'll be. We're also getting improved camera controls and tools to help us manage our VRAM use while filtering out framerate killing, lag inducing, VRAM intensive avatars. That last feature should begin to push content creators towards being smarter about optimizing texture use which will eventually mean better performance all around, even if most people have no idea what VRAM is or how most current content is obscenely wasteful with it.

[Canoro Philipp]

I cried with the Return of Last Names, it was one of the things that hurt me the most to lose, we even collaborated with the lab to have them back, only to be denied, the return of Last Names is like having an old friend back, something that I thought it would never return, thank you so much Ebbe for bring it back, it is so meaningful, Last Names was one of the cornerstones of Second Life, it is going to be so worth it.

thank you Linden Lab for bringing them back, thank you.

[Theresa Tennyson]

7 hours ago, Penny Patton said:

Unfortunately, "Baked on Mesh" is one thing I'm convinced they've already screwed up. Appliers and onion skin avatars aren't going anywhere. It will be fine for skins, tattoos and makeup, but layer clothing will still be applier based, requiring the onion skin body design. Since most body creators are a paranoid, superstitious lot who don't understand how basic SL functions work, they continue to release their products no-mod, which means we'll all still suffer the performance hit from most SL users wearing the equivalent of 3-4 high-poly bodies simultaneously even as fewer and fewer people use layer based clothing.

All because baked on mesh won't support materials.

 

I'm still waiting for you to give us a workable plan to bake normal maps and make it look like the clothing is over the skin. Go 'head...

[Penny Patton]

2 hours ago, Theresa Tennyson said:

I'm still waiting for you to give us a workable plan to bake normal maps and make it look like the clothing is over the skin. Go 'head...

There are two options I can see off the top of my head, neither are perfect but either is  "good enough" especially as few layer clothing appliers include normal maps anyway so you'd primarily want to mask out the body's normal map where clothing covers it:

1. Do it exactly like diffuse textures. - Yeah, normal/spec maps use their alpha channel to store specular data but again that's not really necessary for layer based clothing as we commonly see it implemented in SL. So instead use that channel as an alpha mask specifically for baking purposes. Outside of the baking process the alpha channel or material maps would be treated exactly as they are now. If no material map is present a blank map is used which refers to the diffuse alpha to determine where the material map beneath shows through. Cons - you lose the specular data stored in the alpha channels for layered clothing material maps.  Pro - You can have skintight clothing that uses the skin's normal map but the clothing's specular.

2. Do it like diffuse textures EXCEPT refer to the corresponding diffuse texture's alpha map to determine where normal maps crossfade or are cut off. - Con - You won't be able to have material layers below clothing show through even for skintight clothing. Pro - You retain the ability to add additional specular information via the material map's alpha channel.

I prefer method one. In either case some way to link diffuse and material maps would be required. This can be accomplished by adding material map options to the layer based clothing UI. 

Done, and I haven't even gotten coffee yet.

ETA:

A con to either of these approaches is I'm not sure how an emissive option could be implemented. If there is no way to do it that's certainly a loss, but still better than not supporting materials at all as the amount of layer clothing that currently uses emissive masks is negligible.

Also, smart body makers could include a clothing layer shell that could be worn separate from the main body and LL could figure out a way to allow two baked layers per avatar, one for the skin textures and one for the clothing shell.This method would make it so neglecting materials, while still not great, would at least not be so crippling to the benefits of the feature as it currently stands. One extra layer is certainly less of a resource drain than 3-4 extra layers.

Edited March 27, 2018 by Penny Patton

[Qie Niangao]

9 minutes ago, Penny Patton said:

1. Do it exactly like diffuse textures. - Yeah, normal/spec maps use their alpha channel to store specular data but again that's not really necessary for layer based clothing as we commonly see it implemented in SL.

I'm not sure that will continue to hold true, though. The use for that specular exponent data is to apply glossiness specifically to parts of a surface. Think of a figure skater's skintight sequined satin outfit that's variously shiny all over, but highly glossy only at the sequins. (That said, this option was the first thing that came to my mind, too. And push come to shove, one could bake a high-gloss sequins layer on top of the satin and get much the same effect.)

I very much agree that without any way of baking normal or specular maps, the whole bakes-on-mesh thing will have limited utility. In fact, it makes me wonder if it's actually worth doing at all, and whether the effort might have been better spent removing from the rendering pipeline all mesh surfaces bearing the default full-alpha diffusemap. That wouldn't achieve the ideal of much simpler models that didn't need to store/download/cache that geometry at all, but it would sure reduce the rendering cost of those "onionskin" avatar layers -- and even help rendering unattached mesh.

[Penny Patton]

1 hour ago, Qie Niangao said:

I'm not sure that will continue to hold true, though. The use for that specular exponent data is to apply glossiness specifically to parts of a surface. Think of a figure skater's skintight sequined satin outfit that's variously shiny all over, but highly glossy only at the sequins. (That said, this option was the first thing that came to my mind, too. And push come to shove, one could bake a high-gloss sequins layer on top of the satin and get much the same effect.)

You're not wrong,and there's a lot more I'd like to say, but I think it would be better to save it for another thread devoted specifically to this topic. There's so much to unpack and discuss from Ebbe's announcement that I don't want to derail the thread any further. 

There's more information that wasn't even included in this announcement. According to Lindens at the viewer dev office hours, the enhanced windlight features are supposed to include scriptable windlight features! How cool is that? I've wanted scriptable environmental controls like that since before Windlight was even a thing!

[Theresa Tennyson]

4 hours ago, Penny Patton said:

There are two options I can see off the top of my head, neither are perfect but either is  "good enough" especially as few layer clothing appliers include normal maps anyway so you'd primarily want to mask out the body's normal map where clothing covers it:

1. Do it exactly like diffuse textures. - Yeah, normal/spec maps use their alpha channel to store specular data but again that's not really necessary for layer based clothing as we commonly see it implemented in SL. So instead use that channel as an alpha mask specifically for baking purposes. Outside of the baking process the alpha channel or material maps would be treated exactly as they are now. If no material map is present a blank map is used which refers to the diffuse alpha to determine where the material map beneath shows through. Cons - you lose the specular data stored in the alpha channels for layered clothing material maps.  Pro - You can have skintight clothing that uses the skin's normal map but the clothing's specular.

2. Do it like diffuse textures EXCEPT refer to the corresponding diffuse texture's alpha map to determine where normal maps crossfade or are cut off. - Con - You won't be able to have material layers below clothing show through even for skintight clothing. Pro - You retain the ability to add additional specular information via the material map's alpha channel.

I prefer method one. In either case some way to link diffuse and material maps would be required. This can be accomplished by adding material map options to the layer based clothing UI. 

Done, and I haven't even gotten coffee yet.

ETA:

A con to either of these approaches is I'm not sure how an emissive option could be implemented. If there is no way to do it that's certainly a loss, but still better than not supporting materials at all as the amount of layer clothing that currently uses emissive masks is negligible.

Also, smart body makers could include a clothing layer shell that could be worn separate from the main body and LL could figure out a way to allow two baked layers per avatar, one for the skin textures and one for the clothing shell.This method would make it so neglecting materials, while still not great, would at least not be so crippling to the benefits of the feature as it currently stands. One extra layer is certainly less of a resource drain than 3-4 extra layers.

 

4 hours ago, Penny Patton said:

There are two options I can see off the top of my head, neither are perfect but either is  "good enough" especially as few layer clothing appliers include normal maps anyway so you'd primarily want to mask out the body's normal map where clothing covers it:

1. Do it exactly like diffuse textures. - Yeah, normal/spec maps use their alpha channel to store specular data but again that's not really necessary for layer based clothing as we commonly see it implemented in SL. So instead use that channel as an alpha mask specifically for baking purposes. Outside of the baking process the alpha channel or material maps would be treated exactly as they are now. If no material map is present a blank map is used which refers to the diffuse alpha to determine where the material map beneath shows through. Cons - you lose the specular data stored in the alpha channels for layered clothing material maps.  Pro - You can have skintight clothing that uses the skin's normal map but the clothing's specular.

2. Do it like diffuse textures EXCEPT refer to the corresponding diffuse texture's alpha map to determine where normal maps crossfade or are cut off. - Con - You won't be able to have material layers below clothing show through even for skintight clothing. Pro - You retain the ability to add additional specular information via the material map's alpha channel.

I prefer method one. In either case some way to link diffuse and material maps would be required. This can be accomplished by adding material map options to the layer based clothing UI. 

Done, and I haven't even gotten coffee yet.

ETA:

A con to either of these approaches is I'm not sure how an emissive option could be implemented. If there is no way to do it that's certainly a loss, but still better than not supporting materials at all as the amount of layer clothing that currently uses emissive masks is negligible.

Also, smart body makers could include a clothing layer shell that could be worn separate from the main body and LL could figure out a way to allow two baked layers per avatar, one for the skin textures and one for the clothing shell.This method would make it so neglecting materials, while still not great, would at least not be so crippling to the benefits of the feature as it currently stands. One extra layer is certainly less of a resource drain than 3-4 extra layers.

Reply here, last page:

 

[Qie Niangao]

On 26/03/2018 at 6:11 AM, Qie Niangao said:

I'll pretty much bet that llKey2Name() will continue to fetch-up the legacy name, which is the same name it has returned since before there were display names, and that name changes will never affect those legacy names. If they do, then it would be time to worry because a whole lot of content will break.

And I would lose that bet. To wit:

Quote

[12:11] Qie Niangao: So... these new changeable names that are coming in the 15th birthday bundle: If I change my name, will llDetectedName() return that new name instead of my old one? Or is this another layer of identity?
[12:12] Simon Linden: It's going to be mass confusing, Qie
[12:12] Rex Cronon: u can change your existing name?
[12:12] Simon Linden: but your new name should replace the old one ... it's not like Display Names
[12:12] Joe Magarac (animats): We are going to need an LSL function for name to key.
[12:12] Minuet Voir: Not yet Rex, but something new towards the end of th eyear.
[12:12] Qie Niangao: I'm just looking forward to all the broken security orbs, so I can do Bad Stuff.
[12:13] Oz Linden: llDetectedName should return the new name, but it may take some time for it to change everywhere due to caches
[12:13] Loading... (whirly.fizzle): Have you decided on a cost for username change yet?
[12:13] Qie Niangao: (I'm actually surprised it will work that way)
[12:13] Oz Linden: even if we had (which we havn't), we wouldn't tell :-)
[12:14] Loading... (whirly.fizzle): Pfffbt
[12:14] Minuet Voir giggles
[12:14] Rex Cronon: if people can change their name to linden...
[12:14] Simon Linden: that would be bad, Rex
[12:14] Minuet Voir: Oz "I'm not telling you" Linden
[12:15] Minuet Voir: Sexy Linden
[12:15] Rex Cronon: so u can have more than one person with same name?
[12:15] Loading... (whirly.fizzle): Sexy is blocked in a UN now...
[12:16] Oz Linden: no, you can't have more than one person with the same name
[12:16] Oz Linden: any name will always and forever map to the same agent id, and the agent id will map only to the current name

(relevant bits of the Sim User Group meeting, emphasis mine)

[schism333]

Do we have to change our name?