Talk:Display Names/LSL - Revision history

Strife Onizuka: /* Default Behaviour for Sensor to Reduce Broken Scripts? */

2010-11-22T20:11:34Z

Default Behaviour for Sensor to Reduce Broken Scripts?

← Older revision		Revision as of 13:11, 22 November 2010
Line 93:		Line 93:

	:::: 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 <code>num_detected</code> as 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.<br/>-- '''[[User:Haravikk_Mistral\|Haravikk]]''' <sup><small>([[User_talk:Haravikk_Mistral\|talk]]\|[[Special:Contributions/Haravikk_Mistral\|contribs]])</small></sup> 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 <code>num_detected</code> as 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.<br/>-- '''[[User:Haravikk_Mistral\|Haravikk]]''' <sup><small>([[User_talk:Haravikk_Mistral\|talk]]\|[[Special:Contributions/Haravikk_Mistral\|contribs]])</small></sup> 10:44, 22 November 2010 (UTC)

			::::: Using hard coded names has never been a good idea, and when searching for a user specified avatar, it's always been a good idea to make the search fuzzy. The problem here isn't that there are breaking changes to the language, the problem is user ignorance, they do not understanding how to use the older scripts. With these new features we are left to clean up the mess. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 20:11, 22 November 2010 (UTC)

	: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.		: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 {{HoverText\|information visibility\|The concept that the important information needs to easily accessible; this creates the problem that accessibility wars with depth of explanation & organization, optional information hiding is the solution}}. 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. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 23:28, 21 November 2010 (UTC)		:In other news, we have collapsible sections now, we can expand the documentation without worrying so much about {{HoverText\|information visibility\|The concept that the important information needs to easily accessible; this creates the problem that accessibility wars with depth of explanation & organization, optional information hiding is the solution}}. 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. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 23:28, 21 November 2010 (UTC)

Haravikk Mistral: /* Default Behaviour for Sensor to Reduce Broken Scripts? */

2010-11-22T10:44:21Z

Default Behaviour for Sensor to Reduce Broken Scripts?

← Older revision		Revision as of 03:44, 22 November 2010
Line 91:		Line 91:

	::: 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. --[[User:Cerise Resident\|Cerise Resident]] 00:32, 22 November 2010 (UTC)		::: 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. --[[User:Cerise Resident\|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 <code>num_detected</code> as 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.<br/>-- '''[[User:Haravikk_Mistral\|Haravikk]]''' <sup><small>([[User_talk:Haravikk_Mistral\|talk]]\|[[Special:Contributions/Haravikk_Mistral\|contribs]])</small></sup> 10:44, 22 November 2010 (UTC)

	: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.		: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 {{HoverText\|information visibility\|The concept that the important information needs to easily accessible; this creates the problem that accessibility wars with depth of explanation & organization, optional information hiding is the solution}}. 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. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 23:28, 21 November 2010 (UTC)		:In other news, we have collapsible sections now, we can expand the documentation without worrying so much about {{HoverText\|information visibility\|The concept that the important information needs to easily accessible; this creates the problem that accessibility wars with depth of explanation & organization, optional information hiding is the solution}}. 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. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 23:28, 21 November 2010 (UTC)

Cerise Resident: /* Default Behaviour for Sensor to Reduce Broken Scripts? */

2010-11-22T00:32:04Z

Default Behaviour for Sensor to Reduce Broken Scripts?

← Older revision		Revision as of 17:32, 21 November 2010
Line 89:		Line 89:

	::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 <code>num_detected</code> in the [[sensor]] event, or otherwise will perform an additional check within the event, so will behave normally either way.<br/>-- '''[[User:Haravikk_Mistral\|Haravikk]]''' <sup><small>([[User_talk:Haravikk_Mistral\|talk]]\|[[Special:Contributions/Haravikk_Mistral\|contribs]])</small></sup> 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 <code>num_detected</code> in the [[sensor]] event, or otherwise will perform an additional check within the event, so will behave normally either way.<br/>-- '''[[User:Haravikk_Mistral\|Haravikk]]''' <sup><small>([[User_talk:Haravikk_Mistral\|talk]]\|[[Special:Contributions/Haravikk_Mistral\|contribs]])</small></sup> 22:43, 21 November 2010 (UTC)

			::: 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. --[[User:Cerise Resident\|Cerise Resident]] 00:32, 22 November 2010 (UTC)

	: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.		: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 {{HoverText\|information visibility\|The concept that the important information needs to easily accessible; this creates the problem that accessibility wars with depth of explanation & organization, optional information hiding is the solution}}. 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. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 23:28, 21 November 2010 (UTC)		:In other news, we have collapsible sections now, we can expand the documentation without worrying so much about {{HoverText\|information visibility\|The concept that the important information needs to easily accessible; this creates the problem that accessibility wars with depth of explanation & organization, optional information hiding is the solution}}. 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. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 23:28, 21 November 2010 (UTC)

Strife Onizuka: /* Default Behaviour for Sensor to Reduce Broken Scripts? */

2010-11-21T23:37:15Z

Default Behaviour for Sensor to Reduce Broken Scripts?

← Older revision		Revision as of 16:37, 21 November 2010
Line 92:		Line 92:
	: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.		: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 {{HoverText\|information visibility\|The concept that the important information needs to easily accessible; this creates the problem that accessibility wars with depth of explanation, information hiding is the solution}}. We need to decide how and where we will use Collapsible Sections in the documentation~~. They~~ have the potential to transform everything. The time has come to ~~redesign~~ the layout. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 23:28, 21 November 2010 (UTC)		:In other news, we have collapsible sections now, we can expand the documentation without worrying so much about {{HoverText\|information visibility\|The concept that the important information needs to easily accessible; this creates the problem that accessibility wars with depth of explanation & organization, optional information hiding is the solution}}. 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. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 23:28, 21 November 2010 (UTC)

Strife Onizuka: /* Default Behaviour for Sensor to Reduce Broken Scripts? */

2010-11-21T23:30:08Z

Default Behaviour for Sensor to Reduce Broken Scripts?

← Older revision		Revision as of 16:30, 21 November 2010
Line 92:		Line 92:
	: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.		: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 {{HoverText\|information visibility\|The concept that the important information needs to easily accessible; this creates the problem that accessibility wars with depth of explanation, information hiding is the solution}}. We need to decide how Collapsible Sections ~~will effect~~ the documentation. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 23:28, 21 November 2010 (UTC)		:In other news, we have collapsible sections now, we can expand the documentation without worrying so much about {{HoverText\|information visibility\|The concept that the important information needs to easily accessible; this creates the problem that accessibility wars with depth of explanation, information hiding is the solution}}. We need to decide how and where we will use Collapsible Sections in the documentation. They have the potential to transform everything. The time has come to redesign the layout. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 23:28, 21 November 2010 (UTC)

Strife Onizuka: /* Default Behaviour for Sensor to Reduce Broken Scripts? */

2010-11-21T23:28:51Z

Default Behaviour for Sensor to Reduce Broken Scripts?

← Older revision		Revision as of 16:28, 21 November 2010
Line 89:		Line 89:

	::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 <code>num_detected</code> in the [[sensor]] event, or otherwise will perform an additional check within the event, so will behave normally either way.<br/>-- '''[[User:Haravikk_Mistral\|Haravikk]]''' <sup><small>([[User_talk:Haravikk_Mistral\|talk]]\|[[Special:Contributions/Haravikk_Mistral\|contribs]])</small></sup> 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 <code>num_detected</code> in the [[sensor]] event, or otherwise will perform an additional check within the event, so will behave normally either way.<br/>-- '''[[User:Haravikk_Mistral\|Haravikk]]''' <sup><small>([[User_talk:Haravikk_Mistral\|talk]]\|[[Special:Contributions/Haravikk_Mistral\|contribs]])</small></sup> 22:43, 21 November 2010 (UTC)

			: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 {{HoverText\|information visibility\|The concept that the important information needs to easily accessible; this creates the problem that accessibility wars with depth of explanation, information hiding is the solution}}. We need to decide how Collapsible Sections will effect the documentation. -- '''[[User:Strife_Onizuka\|Strife]]''' <sup><small>([[User talk:Strife_Onizuka\|talk]]\|[[Special:Contributions/Strife_Onizuka\|contribs]])</small></sup> 23:28, 21 November 2010 (UTC)

Haravikk Mistral: /* Default Behaviour for Sensor to Reduce Broken Scripts? */

2010-11-21T22:44:00Z

Default Behaviour for Sensor to Reduce Broken Scripts?

← Older revision		Revision as of 15:44, 21 November 2010
Line 86:		Line 86:
	I suppose this goes hand-in-hand with the lack of an <code>AGENT_BY_DISPLAY_NAME</code> 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 <code>llLooksLike(string anyUTF, string compareTo)</code> function would allow comparison of a known string against arbitrary UTF, with known visual issues accounted for such as odd characters etc.<br/>-- '''[[User:Haravikk_Mistral\|Haravikk]]''' <sup><small>([[User_talk:Haravikk_Mistral\|talk]]\|[[Special:Contributions/Haravikk_Mistral\|contribs]])</small></sup> 15:58, 21 November 2010 (UTC)		I suppose this goes hand-in-hand with the lack of an <code>AGENT_BY_DISPLAY_NAME</code> 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 <code>llLooksLike(string anyUTF, string compareTo)</code> function would allow comparison of a known string against arbitrary UTF, with known visual issues accounted for such as odd characters etc.<br/>-- '''[[User:Haravikk_Mistral\|Haravikk]]''' <sup><small>([[User_talk:Haravikk_Mistral\|talk]]\|[[Special:Contributions/Haravikk_Mistral\|contribs]])</small></sup> 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. --[[User:Cerise Sorbet\|Cerise Sorbet]] 22:28, 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. --[[User:Cerise Sorbet\|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 <code>num_detected</code> in the [[sensor]] event, or otherwise will perform an additional check within the event, so will behave normally either way.<br/>-- '''[[User:Haravikk_Mistral\|Haravikk]]''' <sup><small>([[User_talk:Haravikk_Mistral\|talk]]\|[[Special:Contributions/Haravikk_Mistral\|contribs]])</small></sup> 22:43, 21 November 2010 (UTC)

Cerise Sorbet: /* Default Behaviour for Sensor to Reduce Broken Scripts? */

2010-11-21T22:28:08Z

Default Behaviour for Sensor to Reduce Broken Scripts?

← Older revision		Revision as of 15:28, 21 November 2010
Line 85:		Line 85:
	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 <code>AGENT</code> 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 <code>AGENT_BY_LEGACY_NAME</code> will actually be a useful separate case as well since it won't have this extra behaviour.		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 <code>AGENT</code> 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 <code>AGENT_BY_LEGACY_NAME</code> 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 <code>AGENT_BY_DISPLAY_NAME</code> 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 <code>llLooksLike(string anyUTF, string compareTo)</code> function would allow comparison of a known string against arbitrary UTF, with known visual issues accounted for such as odd characters etc.<br/>-- '''[[User:Haravikk_Mistral\|Haravikk]]''' <sup><small>([[User_talk:Haravikk_Mistral\|talk]]\|[[Special:Contributions/Haravikk_Mistral\|contribs]])</small></sup> 15:58, 21 November 2010 (UTC)		I suppose this goes hand-in-hand with the lack of an <code>AGENT_BY_DISPLAY_NAME</code> 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 <code>llLooksLike(string anyUTF, string compareTo)</code> function would allow comparison of a known string against arbitrary UTF, with known visual issues accounted for such as odd characters etc.<br/>-- '''[[User:Haravikk_Mistral\|Haravikk]]''' <sup><small>([[User_talk:Haravikk_Mistral\|talk]]\|[[Special:Contributions/Haravikk_Mistral\|contribs]])</small></sup> 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. --[[User:Cerise Sorbet\|Cerise Sorbet]] 22:28, 21 November 2010 (UTC)

Haravikk Mistral: /* Default Behaviour for Sensor to Reduce Broken Scripts? */ new section

2010-11-21T15:58:40Z

Default Behaviour for Sensor to Reduce Broken Scripts?: new section

← Older revision		Revision as of 08:58, 21 November 2010
Line 78:		Line 78:

	:You're right, there seems to be no plan for an AGENT_BY_DISPLAY_NAME as addressed [[Display Names/LSL#What_about_an_AGENT_BY_DISPLAY_NAME_flag_for_llSensor.3F\|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.<br/>-- '''[[User:Haravikk_Mistral\|Haravikk]]''' <sup><small>([[User_talk:Haravikk_Mistral\|talk]]\|[[Special:Contributions/Haravikk_Mistral\|contribs]])</small></sup> 22:13, 10 November 2010 (UTC)		:You're right, there seems to be no plan for an AGENT_BY_DISPLAY_NAME as addressed [[Display Names/LSL#What_about_an_AGENT_BY_DISPLAY_NAME_flag_for_llSensor.3F\|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.<br/>-- '''[[User:Haravikk_Mistral\|Haravikk]]''' <sup><small>([[User_talk:Haravikk_Mistral\|talk]]\|[[Special:Contributions/Haravikk_Mistral\|contribs]])</small></sup> 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 <code>AGENT</code> 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 <code>AGENT_BY_LEGACY_NAME</code> 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 <code>AGENT_BY_DISPLAY_NAME</code> 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 <code>llLooksLike(string anyUTF, string compareTo)</code> function would allow comparison of a known string against arbitrary UTF, with known visual issues accounted for such as odd characters etc.<br/>-- '''[[User:Haravikk_Mistral\|Haravikk]]''' <sup><small>([[User_talk:Haravikk_Mistral\|talk]]\|[[Special:Contributions/Haravikk_Mistral\|contribs]])</small></sup> 15:58, 21 November 2010 (UTC)

Haravikk Mistral: /* llSensor constants */

2010-11-10T22:13:26Z

llSensor constants

← Older revision		Revision as of 15:13, 10 November 2010
Line 77:		Line 77:
	[[User:Innula Zenovka\|Innula Zenovka]] 21:13, 10 November 2010 (UTC)		[[User:Innula Zenovka\|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 [LSL#What_about_an_AGENT_BY_DISPLAY_NAME_flag_for_llSensor\|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.<br/>-- '''[[User:Haravikk_Mistral\|Haravikk]]''' <sup><small>([[User_talk:Haravikk_Mistral\|talk]]\|[[Special:Contributions/Haravikk_Mistral\|contribs]])</small></sup> 22:11, 10 November 2010 (UTC)		:You're right, there seems to be no plan for an AGENT_BY_DISPLAY_NAME as addressed [[Display Names/LSL#What_about_an_AGENT_BY_DISPLAY_NAME_flag_for_llSensor.3F\|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.<br/>-- '''[[User:Haravikk_Mistral\|Haravikk]]''' <sup><small>([[User_talk:Haravikk_Mistral\|talk]]\|[[Special:Contributions/Haravikk_Mistral\|contribs]])</small></sup> 22:13, 10 November 2010 (UTC)

← Older revision		Revision as of 15:44, 21 November 2010
Line 86:		Line 86:
	I suppose this goes hand-in-hand with the lack of an <code>AGENT_BY_DISPLAY_NAME</code> 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 <code>llLooksLike(string anyUTF, string compareTo)</code> function would allow comparison of a known string against arbitrary UTF, with known visual issues accounted for such as odd characters etc.<br/>-- '''[[User:Haravikk_Mistral\|Haravikk]]''' <sup><small>([[User_talk:Haravikk_Mistral\|talk]]\|[[Special:Contributions/Haravikk_Mistral\|contribs]])</small></sup> 15:58, 21 November 2010 (UTC)		I suppose this goes hand-in-hand with the lack of an <code>AGENT_BY_DISPLAY_NAME</code> 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 <code>llLooksLike(string anyUTF, string compareTo)</code> function would allow comparison of a known string against arbitrary UTF, with known visual issues accounted for such as odd characters etc.<br/>-- '''[[User:Haravikk_Mistral\|Haravikk]]''' <sup><small>([[User_talk:Haravikk_Mistral\|talk]]\|[[Special:Contributions/Haravikk_Mistral\|contribs]])</small></sup> 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. --[[User:Cerise Sorbet\|Cerise Sorbet]] 22:28, 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. --[[User:Cerise Sorbet\|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 <code>num_detected</code> in the [[sensor]] event, or otherwise will perform an additional check within the event, so will behave normally either way.<br/>-- '''[[User:Haravikk_Mistral\|Haravikk]]''' <sup><small>([[User_talk:Haravikk_Mistral\|talk]]\|[[Special:Contributions/Haravikk_Mistral\|contribs]])</small></sup> 22:43, 21 November 2010 (UTC)