Difference between revisions of "Talk:N2K"
Kira Komarov (talk | contribs) |
|||
Line 22: | Line 22: | ||
Kira Komarov 08:47, 23 November 2011 (PST) | Kira Komarov 08:47, 23 November 2011 (PST) | ||
===SL Search API limits and More=== | |||
Note that keys of people who choose to not list their avatars in search are not available via the vwrsearch API. You may want to add a fallback of some sort, or update your recommendation that for any critical system the operation of one's own caching database with multiple sources may be the safest option. | |||
There is also the risk of W3C blacklisting SL IP ranges if using their service becomes overly popular, in which case it's again safer to run the same functionality on one's own server. This incurs costs, of course, which makes that route viable only for commercial applications. | |||
[[User:Augren Ferguson|Augren Ferguson]] 00:51, 6 January 2012 (PST) |
Revision as of 00:51, 6 January 2012
Needs "Resident" as a last name for newer names?
Thanks so much. This is a great help.
However, the only way I could get it to work for my newer alts (that is, ones with only one name) was to change it to <lsl> default {
link_message(integer sender_num, integer num, string str, key id) { lReqNum = sender_num; if(llGetListLength(llParseString2List(str,[" "],[""]))==1){//test for legacy name or new one str+=" Resident";//if it's a new name } // llOwnerSay(str); kReq = str; state kn2k; }
} </lsl> Innula Zenovka 08:50, 22 November 2011 (PST)
No problem. Yes, very true. "new members" *do* have second names. It's just that they are all "Resident". In fact, if you pass the _full name_ to the script (including the "Resident" last name), it would work out of the box. Added a note, ty.
Kira Komarov 08:47, 23 November 2011 (PST)
SL Search API limits and More
Note that keys of people who choose to not list their avatars in search are not available via the vwrsearch API. You may want to add a fallback of some sort, or update your recommendation that for any critical system the operation of one's own caching database with multiple sources may be the safest option.
There is also the risk of W3C blacklisting SL IP ranges if using their service becomes overly popular, in which case it's again safer to run the same functionality on one's own server. This incurs costs, of course, which makes that route viable only for commercial applications.
Augren Ferguson 00:51, 6 January 2012 (PST)