Talk:Display Names/LSL
I have a Name2Key database to deliver gifts and to link registred users on my website to their SL account. The Name2Key Database does a namesearch lookup with a bot, if the name could not be found in the database. Will the namesearch lookup find the display names or the real names ? And whats when there are multiple people are using the same display name ?
- With bots we are talking more viewer code than scripting. It will depend on how your bot works and how it does its searches. I would not be surprised if it required some updating to find the correct resident. - Kelly Linden 15:31, 19 August 2010 (UTC)
The "N" and the "n" used for name in functions
Hi Kelly,
considering function names llGetDisplayName and llGetUsername (same for lRequestxxxx) you'll see a difference for Name and name ; is it a mistake when you have written this article or the real names of the functions?
If they are the real function names, that will generate compile errors surely because we are humans :))
Yours truly
Garmin
Garmin Kawaguichi 10:39, 20 August 2010 (UTC)
- That is because it's a username (one word) and a display name (two words), I think. A similar difference is in the llSensor constants: AGENT_BY_DISPLAY_NAME and AGENT_BY_USERNAME. Getting compile errors due to typos I already get a lot, I expect some more with these yeah :p DarthBunny Petrov 14:12, 20 August 2010 (UTC)
- The english language subtlety, I understand that! Merci Garmin Kawaguichi 21:07, 20 August 2010 (UTC)
- This is correct. "username" is one word, and "display name" is two. Kelly Linden 23:12, 20 August 2010 (UTC)
The dataserver functions
I'm curious about why the dataserver requests to get the username and display name weren't added to llRequestAgentData (with for example new constants DATA_USERNAME and DATA_DISPLAY_NAME). Is it easier to add new functions? Or do separate functions just make more sense from a language design point of view or something? DarthBunny Petrov 14:12, 20 August 2010 (UTC)
- This is something we have not been uniform on in the past. Simple single action functions are a bit easier both to use and for us to implement, so we kind of prefer them. There is no really strong reason that I am aware of right now that we chose this way this time though. - Kelly Linden 23:14, 20 August 2010 (UTC)
- It pairs a llGet* function with an llRequest* function; it's the new uniformity. Don't have to remember you need to use llRequestAgentData and the DATA_* flag that goes with it. A small part of me morns the lack of DATA_* flags. I wish llRequestInventoryData would work for more then just landmarks... -- Strife (talk|contribs) 20:12, 23 September 2010 (UTC)
So what about the Custom Name Program?
http://wiki.secondlife.com/wiki/Custom_Name_Program
Will this still be available? (not that it was really "available" before, our request a while ago was rejected on the grounds that we had no RL presence for our SL business, so we didn't count)
- I do not know the plans for the custom name program, and it does not relate to the LSL FAQ which this page is for. I'd try either the main FAQ or the Blog post. - Kelly Linden 05:13, 26 August 2010 (UTC)
llDetectedType
LSL Linking
I've started organizing the new functions and information. I've focused everything around Category:LSL_Avatar/Name. -- Strife (talk|contribs) 21:47, 23 September 2010 (UTC)
X-SecondLife-Owner-Display-Name and similar?
You've covered the behaviour for the existing X-SecondLife-Owner-Name sent with llHTTPRequest(), but I'm curious to know if we'll ever see headers such as:
| HTTP Header | Contents |
|---|---|
| X-SecondLife-Owner-Display-Name | The display name of the owner |
| X-SecondLife-Owner-Username | The username of the owner |
—The preceding unsigned comment was added on 19:30, 8 October 2010 by Haravikk Mistral
- They probably won't be added until they are requested and there is a clamor for them. -- Strife (talk|contribs) 18:39, 14 October 2010 (UTC)
- I may ask at Kelly Linden's office hour, naturally all my web scripts already support these imaginary headers =)
-- Haravikk (talk|contribs) 21:50, 14 October 2010 (UTC)- I don't know. Maybe get it on the triage? It should be straight forward. - Kelly Linden 22:53, 20 October 2010 (UTC)
- I may ask at Kelly Linden's office hour, naturally all my web scripts already support these imaginary headers =)
llSensor constants
I don't understand this:
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.
Is it a typo, and does it mean there will be 3 constants, the existing AGENT and the two new ones, AGENT_BY_LEGACY_NAME and AGENT_BY_USERNAME ?
Innula Zenovka 21:13, 10 November 2010 (UTC)
- You're right, there seems to be no plan for an AGENT_BY_DISPLAY_NAME as addressed here. You'll have to either obtain a key, or filter everyone and manually check display names using llGetDisplayName(), though this seems a bit odd as a built-in filter would do it just as well, visual issues or not.
-- Haravikk (talk|contribs) 22:13, 10 November 2010 (UTC)
Default Behaviour for Sensor to Reduce Broken Scripts?
It seems that one of the main potential breakages for scripts with Display Names is going to be code like:
<lsl>llSensor("Haravikk Mistral", NULL_KEY, AGENT, 96.0, PI);</lsl>
The reason being that my visible name may be "Haravikk" and thus that would be what I type in. I think therefore that it may make sense for the default AGENT type to actually include all possible names, i.e - if I have a display name set then it will try this first, if that fails (or I didn't have one), then it'll try my full-name. This way the only existing scripts that we would break would be those that manually check the result of llKey2Name() against some source. This way AGENT_BY_LEGACY_NAME will actually be a useful separate case as well since it won't have this extra behaviour.
I suppose this goes hand-in-hand with the lack of an AGENT_BY_DISPLAY_NAME constant, I'm not sure I understand why such a flag is being omitted. I mean yeah it'll fail on more complex display-names, but it at least gives us the option of trying? One other alternative to consider might be an llLooksLike(string anyUTF, string compareTo) function would allow comparison of a known string against arbitrary UTF, with known visual issues accounted for such as odd characters etc.
-- Haravikk (talk|contribs) 15:58, 21 November 2010 (UTC)
- AGENT with a name returns results for a unique avatar. Existing content does depend on that, breaking the uniqueness will be a very bad idea. --Cerise Sorbet 22:28, 21 November 2010 (UTC)
- I'm not certain that it'd be an issue, as if the script only expects one result, then it won't iterate through the full range of
num_detectedin the sensor event, or otherwise will perform an additional check within the event, so will behave normally either way.
-- Haravikk (talk|contribs) 22:43, 21 November 2010 (UTC)
- I'm not certain that it'd be an issue, as if the script only expects one result, then it won't iterate through the full range of
- I am certain that it is a problem. A name filter with AGENT will now detect one and only one avatar and this has nothing to do with num_detected, it is consistent across sensor events. To change it to a non-unique string will break content. --Cerise Resident 00:32, 22 November 2010 (UTC)
- The chances of breaking content with such a change are minuscule compared with the breakages that will definitely occur with the currently proposed behaviour; the chances of collision with an entirely arbitrary name space are tiny. And it does have everything to do with
num_detectedas either the code in the sensor() event only bothers with the first item, or if it process the full number (perhaps because it has other sensor calls) then it should already have additional checks to prevent more than the expected number of results. I mean, the possibility of name-changing being implemented has been around for years (nearly as long as SL really), so it's been the case for sometime now that an avatar's name may not be reliable.
-- Haravikk (talk|contribs) 10:44, 22 November 2010 (UTC)
- The chances of breaking content with such a change are minuscule compared with the breakages that will definitely occur with the currently proposed behaviour; the chances of collision with an entirely arbitrary name space are tiny. And it does have everything to do with
- We need a BIG caveat for this. Maybe something in the description box (function footnote). If it's being discussed in the talk page, it probably needs proper documentation. The exact form of this doc will have to felt out.
- In other news, we have collapsible sections now, we can expand the documentation without worrying so much about information visibility. We need to decide how and where we will use Collapsible Sections in the documentation after all they have the potential to transform everything. The time has come to rethink the layout and redesign it where necessary. -- Strife (talk|contribs) 23:28, 21 November 2010 (UTC)