Difference between revisions of "Display Names/LSL"

From Second Life Wiki
Jump to navigation Jump to search
Line 1: Line 1:
This page addresses '''Frequently Asked Questions about Display Names LSL calls''' not covered on the [[Display Names|general Display Names FAQ]].
This page addresses '''Frequently Asked Questions about Display Names LSL calls''' not covered on the [[Display Names|general Display Names FAQ]].
The following info comes from [[User:Kelly_Linden|Kelly Linden]] as a compilation of his answers on the [https://lists.secondlife.com/pipermail/opensource-dev/2010-August/thread.html opensource-dev] and [https://lists.secondlife.com/pipermail/secondlifescripters/ secondlifescripters] mailing lists.


{{TOC}}
{{TOC}}
Line 5: Line 7:
== How will llKey2Name work? ==
== 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".
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? ==
== How will the llSensor work? ==


The name field in llSensor will filter results on the "full name". For existing residents this will be what it has always used, for example "Kelly Linden". For new residents it will be their username with a last name of Resident, for example "joe1234 Resident".
The name field in llSensor will filter results on the "full name". For existing Residents this will be what it has always used, for example "Kelly Linden". For new Residents it will be their username with a last name of Resident, for example "joe1234 Resident".


== How will llDetectedName work in sensor, collision and touch events? ==
== 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".
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? ==
== How will llRequestAgentData and DATA_NAME work? ==


llRequestAgentData(id,DATA_NAME) will trigger a dataserver event with the residents "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".
llRequestAgentData(id,DATA_NAME) will trigger a dataserver event with the Residents "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? ==
== 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.
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? ==
== 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.  
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? ==
== 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).
There will be two new functions: string llGetDisplayName(key id) and key llRequestDisplayName(key id).
Line 37: Line 39:
== How will key llRequestDisplayName(key id) work? ==
== 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, and scripts may report the old display name during this time.
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, and scripts may report the old display name during this time.


== Will llGetDisplayName and llRequestDisplayName always return the same result? ==
== Will llGetDisplayName and llRequestDisplayName always return the same result? ==
Line 43: Line 45:
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.
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? ==
== 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)
There will be two new functions: string llGetUsername(key id) and key llRequestUsername(key id)
Line 53: Line 55:
== How will key llRequestUsername(key id) work? ==
== 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.
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? ==
== How will I get a Resident's display name in a sensor or collision event? ==


This should work well: llGetDisplayName(llDetectedKey(0))
This should work well: llGetDisplayName(llDetectedKey(0))
Line 67: Line 69:
For example, my jukebox lets me store a notecard in it with the names of who can change the songs. Will it break?
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 note card will continue to match against the result of llDetectedName when I touch the jukebox.. For new residents you will need to use their "full name" in the note card which is their username with a last name of Resident, such as "joe1234 Resident". 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.
For all existing Residents this will continue to work as it has - "Kelly Linden" in a note card will continue to match against the result of llDetectedName when I touch the jukebox.. For new Residents you will need to use their "full name" in the note card which is their username with a last name of Resident, such as "joe1234 Resident". 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? ==
== 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.
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? ==
== What if I'm only checking the first name? ==

Revision as of 11:33, 18 August 2010

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 compilation 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?

The name field in llSensor will filter results on the "full name". For existing Residents this will be what it has always used, for example "Kelly Linden". For new Residents it will be their username with a last name of Resident, for example "joe1234 Resident".

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 Residents "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, and scripts may report the old display name during this time.

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, and scripts may report the old display name during this time.

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 note card will continue to match against the result of llDetectedName when I touch the jukebox.. For new Residents you will need to use their "full name" in the note card which is their username with a last name of Resident, such as "joe1234 Resident". 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.