Display Names/LSL

Template:Needs Translation/KB/de Template:Needs Translation/KB/es Template:Needs Translation/KB/el Template:Needs Translation/KB/fr Template:Needs Translation/KB/he Template:Needs Translation/KB/it Template:Needs Translation/KB/ko Template:Needs Translation/KB/nl Template:Needs Translation/KB/hu Template:Needs Translation/KB/no Template:Needs Translation/KB/da Template:Needs Translation/KB/sv Template:Needs Translation/KB/tr Template:Needs Translation/KB/pl Template:Needs Translation/KB/pt Template:Needs Translation/KB/ru Template:Needs Translation/KB/th Template:Needs Translation/KB/uk Template:Needs Translation/KB/zh-Hans Template:Needs Translation/KB/zh-Hant

/KB

add versioning

This page addresses Frequently Asked Questions about Display Names LSL calls not covered on the general Display Names FAQ.

The following info comes from Kelly Linden as a result of his answers on the opensource-dev and secondlifescripters mailing lists.

How will llKey2Name work?

llKey2Name will return the "full name". For existing Residents this will be what it has always returned, for example "Kelly Linden". For new Residents it will be their username with a last name of "Resident", for example "joe1234 Resident".

How will the llSensor work?

There will be 3 new constants for use in llSensor - AGENT_BY_LEGACY_NAME, AGENT_BY_USERNAME. The existing AGENT flag is equivalent to AGENT_BY_LEGACY_NAME. These will allow you to use a sensor to find residents by either their username or legacy name - "joe1234"/"kelly.linden", "joe1234 Resident"/"Kelly Linden". If you OR them together and use both, the sensor will return all matches.

What about an AGENT_BY_DISPLAY_NAME flag for llSensor?

This is actually a little bit of a tough problem. Display names use UTF-8 and Unicode and this makes this particularly tricky. It is quite possible for a name that looks the same to be represented at the bytecode level in many ways, sometimes with obscure characters and sometimes just because of how the character was entered. Due to these difficulties we are not looking to add this feature at this time, however it is possible we will revisit it in the future.

How will llDetectedName work in sensor, collision and touch events?

llDetectedName will return the "full name". For existing Residents this will be what it has always returned, for example "Kelly Linden". For new Residents it will be their username with a last name of Resident, for example "joe1234 Resident".

How will llRequestAgentData and DATA_NAME work?

llRequestAgentData(id,DATA_NAME) will trigger a dataserver event with the Resident's "full name". For existing Residents this will be what it has always returned, for example "Kelly Linden". This will not change. For new Residents it will be their username with a last name of "Resident", for example "joe1234 Resident".

How will llListen and the listen event work?

The name field on llListen will filter chat against the "full name", for example "Kelly Linden" for existing Residents and "joe1234 Resident" for new Residents. The name given in the listen event will also be the "full name" — again like "Kelly Linden" for existing Residents and "joe1234 Resident" for new Residents.

What will be in the X-SecondLife-Owner-Name header of outgoing http requests?

This will be the owner's "full name". For example, "Kelly Linden" for existing Residents and "joe1234 Resident" for new Residents.

How will a script get the Display Name of a Resident?

There will be two new functions: string llGetDisplayName(key id) and key llRequestDisplayName(key id).

How will string llGetDisplayName(key id) work?

It will return the display name of the agent with key "id" if they are in the same region.

Note: It may take up to 72 hours for a display name change to take effect. During this time scripts may report the old display name and viewers may see the old display name.

How will key llRequestDisplayName(key id) work?

It will trigger a dataserver event, similar to llRequestAgentData, with the Display Name of the Resident with key id. The Resident does not need to be in the same region.

Note: It may take up to 72 hours for a display name change to take effect. During this time scripts may report the old display name and viewers may see the old display name.

Will llGetDisplayName and llRequestDisplayName always return the same result?

It is not guaranteed that they will both return the same result within the 72-hour window after a name change. Specifically, it is possible that llGetDisplayName may return the new display name earlier than llRequestDisplayName will.

How will a script get the username of a Resident?

There will be two new functions: string llGetUsername(key id) and key llRequestUsername(key id)

How will string llGetUsername(key id) work?

It will return the username of the agent with key "id" if they are in the same region.

How will key llRequestUsername(key id) work?

It will trigger a dataserver event, similar to llRequestAgentData, with the username of the Resident with key id. The Resident does not need to be in the same region.

How will I get a Resident's display name in a sensor or collision event?

This should work well: llGetDisplayName(llDetectedKey(0))

Will any of my existing scripts crash because of the new names?

No, they should not.

What if I am storing lists of avatar names to compare against names from existing functions?

For example, my jukebox lets me store a notecard in it with the names of who can change the songs. Will it break?

For all existing Residents this will continue to work as it has — "Kelly Linden" in a notecard will continue to match against the result of llDetectedName when you touch the jukebox. For new Residents, you will need to use their "full name" in the notecard which is their username with a last name of "Resident", such as "joe1234 Resident". Note that capitalization still matters; if the avatar signed up as JOE1234, his legacy name will be "JOE1234 Resident", not slammed to lowercase. If you are able to, it might be a good idea to update the script to work with both "full names" and usernames. It would NOT be a good idea to tie any security measures to display names.

What if I have an object that asks a Resident to type their name and then compares that with a sensor or other existing function?

This will probably break. It is a difficult case. A part of what Display Names does is fundamentally change what people think of when you ask them what their name is. Since you are asking them for their name it is unlikely they will think to enter their "full name", especially for new Residents who would have no reason to think they needed to add Resident to their name.

What if I'm only checking the first name?

If the user of your script thinks to enter their username when asked for their name then this will continue to work.

How could I fix my object that asks for their name?

You could use llGetDisplayName which will be the default name above their head, and a likely response to "What is your name?". It may also be possible in some cases to check against all three names.

More LSL-related questions?

Add them to the discussion page, or send them to kelly@lindenlab.com or secondlifescripters@lists.lindenlab.com (the secondlifescripters mailing list).